* 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.