Re: [OpenWrt-Devel] [RFC] firewall: NAT masquerading race condition
Hi, I noticed the selective conntrack flushing in fw3; looking into the code it only gets active when there's a difference between the cached IP in the __addr list and the current IP addresses in use. In this case the selective conntrack flushing is done for the old_addr. In the error case nf_conntrack displays the following entry : ipv4 2 icmp 1 9 src=192.168.1.10 dst=192.30.252.131 type=8 code=0 id=8323 packets=6 bytes=504 [UNREPLIED] src=192.30.252.131 dst=192.168.1.10 type=0 code=0 id2 Looking into the netfilter_conntrack_flush patch only the connections will be flushed which match the passed address; as fw3 is passing an old cached address when there's a difference the above printed icmp connection will not be flushed as there's no match or is my assumption wrong ? Thx, Hans On Wed, Feb 11, 2015 at 8:30 PM, Jo-Philipp Wich j...@openwrt.org wrote: Hi, theoretically the selective conntrack flushing of fw3 should take care of that. Can you investigate why it is not the case for you? ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] firewall: NAT masquerading race condition
Hi, theoretically the selective conntrack flushing of fw3 should take care of that. Can you investigate why it is not the case for you? ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] firewall: NAT masquerading race condition
A NAT masquerading race condition is observed in a setup where continous ping traffic is launched from a device on the lan towards a device on the internet. The WAN interface has masquerading enabled, the default firewall forward policy is reject and is regularly brought down/up. Initially everything is fine; ping packets leave the WAN interface with as source IP the WAN IP but after the WAN interface has been toggled a number of times the ping packets leave the WAN with as source IP the LAN IP. The situation nevers recovers on subsequent WAN interface toggles as the connection with the wrong NAT state is kept alive due to the pings generated by the LAN device; with tcp/udp traffic the situation will mostly recover as applications will switch the source port when the initial connection fails. The problem is related to the loading order of the iptable rules in the different tables; current order used by the firewall package is filter/nat/mangle/raw. Meaning there's a small window in which ping packets are not rejected by the filter forward hook while the masquerade rule in the nat table is not present. Reversing the load order in the firewall package (thus raw/mangle/nat/filter) solves the issue. However this is not a rock solid solution as the problem will persist if the default firewall forward policy is accept. Any suggestions/ideas how the problem can be solved for all cases ? Thx, Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
