[pve-devel] pve-firewall : masquerade results (+veth vlan tag bug)
Alexandre DERUMIER
aderumier at odiso.com
Fri May 2 09:24:31 CEST 2014
Hi, I have done tests with masquerade, using new model.
First, I would like to say that I have reproduce my corosync cluster hang (kernel 3.10 and kernel 2.6.32), with this setup
pm0.94--->pm0-->vmbr0<---eth0
host ip is on pm0.94.
All is working fine, until
#modprobe nf_conntrack_ipv4
Then, something bad happen, I some corosync packets don't go from pm0.94->pm0.
I suspect from fragmentation problem and vlan tags
#lsmod|grep nf
nf_conntrack_ipv4 14862 2
nf_defrag_ipv4 12729 1 nf_conntrack_ipv4
I have tried to disable offloading (tso,gro,gso) on pm0 and pm0.94, but it doesn't help
I have done some tests with corosync inside guest vms. (I'm using it with pacemaker, for some web server ha-cluster services).
and I can also reproduce the problem
So, I think that vlan tagging on veth is broken somewhere for now.
I think it's better to keep the current vmbrXvY model for 3.10 kernel too
eth0------->vmbr0
eth0.94---->vmbr0v94<-----tapXiY (non firewalled tap)
<--linkXiY----->linkXiYp--->fwbrXiY---->tapXiY (firewalled tap)
Now, about masquerade, we don't need pm0 interface anymore
a simple:
iptables -t raw -A PREROUTING -i fwbr110i0 -j CT --zone 1 (kernel 3.10 only of course)
is enough, to enable nat on a firewalled tap
(user just need to define like before "iptables -t nat -A POSTROUTING -s X.X.X.X/24 -o vmbr0 -j MASQUERADE", like before)
I think it seem to be the best setup, don't break current model for non firewall vms,
and just add a new fwbr bridge for firewalled taps
What do you think about it ?
More information about the pve-devel
mailing list