[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