Typically (or at least somewhat occasionally) after a reboot of my shorewall[-lite] machine I find that I end up with conntrack table entries for unNATted connections such as:
# conntrack -L -p udp --dport 5060 -d 99.232.11.14 udp 17 59 src=10.75.22.8 dst=99.232.11.14 sport=5060 dport=5060 packets=5472 bytes=3031488 [UNREPLIED] src=99.232.11.14 dst=10.75.22.8 sport=5060 dport=5060 packets=0 bytes=0 mark=1 use=2 These are supposed to be NATted and will be so if I flush the offending entries from the conntrack table: # conntrack -D -p udp --dport 5060 -d 99.232.11.14 udp 17 52 src=10.75.22.8 dst=99.232.11.14 sport=5060 dport=5060 packets=5558 bytes=3079132 [UNREPLIED] src=99.232.11.14 dst=10.75.22.8 sport=5060 dport=5060 packets=0 bytes=0 mark=1 use=2 conntrack v1.0.0 (conntrack-tools): 1 flow entries have been deleted. # conntrack -L -p udp --dport 5060 -d 99.232.11.14 udp 17 3593 src=10.75.22.8 dst=99.232.11.14 sport=5060 dport=5060 packets=1 bytes=554 src=99.232.11.14 dst=67.193.214.242 sport=5060 dport=5060 packets=1 bytes=516 mark=257 use=2 Clearly there is some kind of a race or timing issue involved here. Perhaps it's as simple as these conntrack entries get established before shorewall has a chance to get loaded. Or maybe it's a more sinister race in shorewall's startup. My gut instinct makes me feel like it's the former though. I wonder as a matter of routine, if shorewall should flush the entire conntrack table when it loads to prevent this sort of thing. Thoughts? b.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
