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. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
On Jan 15, 2012, at 6:08 PM, Brian J. Murrell wrote:> 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. >This problem is one of the key reasons that I developed shorewall-init. But if you don''t want to install and configure that, then hack your startup scripts to pass the -p option to the ''start'' command. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
On Jan 15, 2012, at 6:27 PM, Tom Eastep wrote:>> >> I wonder as a matter of routine, if shorewall should flush the entire >> conntrack table when it loads to prevent this sort of thing. >> > > This problem is one of the key reasons that I developed shorewall-init. But if you don''t want to install and configure that, then hack your startup scripts to pass the -p option to the ''start'' command.In Shorewall 4.5.0, the /etc/default/shorewall (/etc/sysconf/shorewall) file can specify STARTOPTIONS and RESTARTOPTIONS which will be inserted after ''start'' or ''restart'' respectively when invoking /sbin/shorewall from /etc/init.d/shorewall. So you will be able to specify ''-p'' in those variables to cause this to happen all of the time. I''ll never make ''-p'' the default because a large percentage of Shorewall users don''t even know that /sbin/shorewall exists and always control Shorewall via /etc/init.d/shorewall. If that script were to flush the conntrack table by default, then these users would be continuously locking themselves out of their own firewalls. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
On 12-01-15 09:27 PM, Tom Eastep wrote:> > But if you don''t want to install and configure that, then hack your startup scripts to pass the -p option to the ''start'' command.Yeah, I''ve been trying that. The conntrack table seems to be the same before and after a [re]start -p. Witness: # conntrack -L -nv | grep 5060; shorewall-lite restart -p; conntrack -L -nv | grep 5060; ip route ls udp 17 3586 src=10.75.22.8 dst=1.2.3.4 sport=5060 dport=5060 packets=23 bytes=12972 src=1.2.3.4 dst=9.8.7.6 sport=5060 dport=5060 packets=23 bytes=9591 [ASSURED] mark=513 use=3 udp 17 3581 src=10.75.22.8 dst=2.3.4.5 sport=5060 dport=5060 packets=49 bytes=28524 src=2.3.4.5 dst=9.8.7.6 sport=5060 dport=5060 packets=75 bytes=38618 [ASSURED] mark=513 use=2 udp 17 3587 src=10.75.22.8 dst=3.4.5.6 sport=5060 dport=5060 packets=23 bytes=12972 src=3.4.5.6 dst=9.8.7.6 sport=5060 dport=5060 packets=23 bytes=9591 [ASSURED] mark=513 use=2 conntrack v1.0.0 (conntrack-tools): 145 flow entries have been shown. udp 17 3597 src=10.75.22.8 dst=10.75.23.254 sport=5060 dport=5060 packets=470 bytes=275890 [UNREPLIED] src=10.75.23.254 dst=9.8.7.6 sport=5060 dport=5060 packets=0 bytes=0 mark=1 use=2 Restarting Shorewall Lite.... Initializing... Processing /etc/shorewall/gw-new/init ... Creating any undefined ipsets... Processing /etc/shorewall/gw-new/tcclear ... Setting up Route Filtering... Setting up Martian Logging... Setting up Proxy ARP... Adding Providers... Setting up Traffic Control... Preparing iptables-restore input... Running /usr/sbin/iptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/gw-new/start ... Processing /etc/shorewall/gw-new/started ... set +x done. udp 17 3576 src=10.75.22.8 dst=1.2.3.4 sport=5060 dport=5060 packets=23 bytes=12972 src=1.2.3.4 dst=9.8.7.6 sport=5060 dport=5060 packets=23 bytes=9591 [ASSURED] mark=513 use=2 udp 17 3571 src=10.75.22.8 dst=2.3.4.5 sport=5060 dport=5060 packets=49 bytes=28524 src=2.3.4.5 dst=9.8.7.6 sport=5060 dport=5060 packets=75 bytes=38618 [ASSURED] mark=513 use=2 udp 17 3578 src=10.75.22.8 dst=3.4.5.6 sport=5060 dport=5060 packets=23 bytes=12972 src=3.4.5.6 dst=9.8.7.6 sport=5060 dport=5060 packets=23 bytes=9591 [ASSURED] mark=513 use=2 conntrack v1.0.0 (conntrack-tools): 131 flow entries have been shown. udp 17 3599 src=10.75.22.8 dst=10.75.23.254 sport=5060 dport=5060 packets=473 bytes=277651 [UNREPLIED] src=10.75.23.254 dst=9.8.7.6 sport=5060 dport=5060 packets=0 bytes=0 mark=1 use=2 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 8.2.7.3 dev pppoe-wan1 proto kernel scope link src 9.8.7.6 10.8.0.0/24 via 10.8.0.2 dev tun0 10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.196 10.75.23.0/24 via 10.8.0.2 dev tun0 192.168.123.0/24 via 10.75.22.1 dev br-lan proto zebra metric 20 6.5.4.0/20 dev eth0.2 proto kernel scope link src 6.5.3.242 default via 6.5.4.1 dev eth0.2 I hope the obfuscation has not made it too difficult to understand, but these days of prevalent cracking and social engineering, one cannot be too careful I fear. In any case, I think the main point to take away is that before and after shorewall is restarted with -p the conntrack table is the same with entries being natted from the interface which is not even the default gateway. I would expect that after the restart either the entries would be completely gone, or if a connection had snuck through between the shorewall restarting (and flushing the table) and the second conntrack -L that the source IP would show the default route''s IP, not the backup route''s. Looking further into the shorewall-lite script on this machine I can see that setting a "-p" option sets a "g_purge=Yes" but nowhere else in that script is g_purge referenced. How exactly is "-p" supposed to result in a flushing of the conntrack table? This is shorewall-lite 4.4.12.2 FWIW. Cheers, b. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 01/23/2012 05:53 AM, Brian J. Murrell wrote:> > > Looking further into the shorewall-lite script on this machine I can see > that setting a "-p" option sets a "g_purge=Yes" but nowhere else in that > script is g_purge referenced. > > How exactly is "-p" supposed to result in a flushing of the conntrack > table? This is shorewall-lite 4.4.12.2 FWIW.I pushed a fix for that to GIT recently. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d