All of lore.kernel.org
 help / color / mirror / Atom feed
* bridge call iptables being forced
@ 2015-11-19  1:46 Juan Rossi
  2015-11-20  0:59 ` Steven Haigh
  0 siblings, 1 reply; 2+ messages in thread
From: Juan Rossi @ 2015-11-19  1:46 UTC (permalink / raw)
  To: Xen-devel; +Cc: RimuHosting

Hi

I am sending this due the change of behaviour in some parts, and perhaps 
it needs some code amendments, unsure if the devel list is the best 
place, fell free to point me to the right place for this. Let me know if 
I should load a bug instead.

Per the documentation 
http://wiki.xenproject.org/wiki/Network_Configuration_Examples_(Xen_4.1%2B) 
it is suggested to use:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

We use that setup currently, but we are experiencing the following side 
effects:

1. We manage the firewall in dom0 ourselves, and there seems not to be a 
parameter for the hotplug scripts to avoid the insertion of random rules 
in iptables, or proper checks that will ensure populated iptables rules 
are valid in the case they are needed. Why one will want FORWARD rules 
to be populated that are not required for the above bridge settings?

2. After the change in the kernel:
http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54334 


There is no module loaded br_netfilter by default now, so the settings 
for net.bridge.bridge-nf-call-* do not exist and cannot be setup at 
/etc/sysctl.conf at boot time.

The vif-bridge hotplug script calls (via  handle_iptable() 
frob_iptable() in vif-common.sh ) the for insertion of iptables rules in 
the FORWARD chain with module physdev, that calls for the module load 
br_netfilter, when br_netfilter is loaded has as defaults 
net.bridge.bridge-nf-call-*=1. So we end up using iptables over a bridge 
when we do not want it.

So, to solve this I come up with the following solutions:

A. blacklist modules br_netfilter and xt_physdev, but perhaps not great 
if there is some other uses for them

B. load br_netfilter at boot and set the right parameters 
net.bridge.bridge-nf-call-* = 0 as it should and continue to ignore the 
iptables populated rules.

C. Add some proper code changes to handle the rules insertions, unsure 
if something like this is ok or if it is in the right place. I do not 
know much about the other setups, like nat and routed.

I see there is not much around ip6tables either.

###############################

diff --git a/tools/hotplug/Linux/vif-bridge b/tools/hotplug/Linux/vif-bridge
index 3d72ca4..7fc6650 100644
--- a/tools/hotplug/Linux/vif-bridge
+++ b/tools/hotplug/Linux/vif-bridge
@@ -93,7 +93,16 @@ case "$command" in
          ;;
  esac

-handle_iptable
+brcalliptables=$(sysctl -n net.bridge.bridge-nf-call-iptables 2>/dev/null)
+brcalliptables=${brcalliptables:-0}
+
+brcallip6tables=$(sysctl -n net.bridge.bridge-nf-call-ip6tables 
2>/dev/null)
+brcallip6tables=${brcallip6tables:-0}
+
+if [ "$brcalliptables" -eq "1" -a "$brcallip6tables" -eq "1" ];
+then
+       handle_iptable
+fi

  call_hooks vif post


###############################

Thanks in advance


Regards.

Juan.-
http://ri.mu - Startups start here. Hosting; DNS; monitoring; backups; 
email; web programming

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: bridge call iptables being forced
  2015-11-19  1:46 bridge call iptables being forced Juan Rossi
@ 2015-11-20  0:59 ` Steven Haigh
  0 siblings, 0 replies; 2+ messages in thread
From: Steven Haigh @ 2015-11-20  0:59 UTC (permalink / raw)
  To: juan; +Cc: RimuHosting, Xen-devel

On 2015-11-19 12:46, Juan Rossi wrote:
> Hi
> 
> I am sending this due the change of behaviour in some parts, and
> perhaps it needs some code amendments, unsure if the devel list is the
> best place, fell free to point me to the right place for this. Let me
> know if I should load a bug instead.

I'm tracking this at:
         http://xen.crc.id.au/bugs/view.php?id=62

<snip>
> diff --git a/tools/hotplug/Linux/vif-bridge 
> b/tools/hotplug/Linux/vif-bridge
> index 3d72ca4..7fc6650 100644
> --- a/tools/hotplug/Linux/vif-bridge
> +++ b/tools/hotplug/Linux/vif-bridge
> @@ -93,7 +93,16 @@ case "$command" in
>          ;;
>  esac
> 
> -handle_iptable
> +brcalliptables=$(sysctl -n net.bridge.bridge-nf-call-iptables 
> 2>/dev/null)
> +brcalliptables=${brcalliptables:-0}
> +
> +brcallip6tables=$(sysctl -n net.bridge.bridge-nf-call-ip6tables 
> 2>/dev/null)
> +brcallip6tables=${brcallip6tables:-0}
> +
> +if [ "$brcalliptables" -eq "1" -a "$brcallip6tables" -eq "1" ];
> +then
> +       handle_iptable
> +fi
> 
>  call_hooks vif post

I'm not a fan of this as it will also enable the call to 
handle_iptable() if people create their own firewall rules - ie these 
will be true - hence the rule will get loaded anyway.

My comment on the bug report is included below to hopefully get further 
input from people:
Thinking about this further - as it is a change in behaviour for a point 
release, I believe we should do the following:

1) Create a new option in /etc/xen/xl.conf - and default it to False.
2) Name an option "autocreate_firewall_files"
3) Evaluate autocreate_firewall_rules in vif-common.sh function 
handle_iptable()

I suggest something like the following psuedo code:
if [ $autocreate_firewall_rules == 0 ]; then
         return
fi

Happy to start debate on the correct way of handling this :)

Hopefully this can lead to some further debate.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-11-20  0:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-19  1:46 bridge call iptables being forced Juan Rossi
2015-11-20  0:59 ` Steven Haigh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.