Hi All, Out of 20 sites, I have a single site that isn''t respecting admin zone rules. I have a set of IPs assigned to the admin zone which are IPs that we want to be able to ssh or http into the box from. I have no admin rules, simply one admin policy which ACCEPTs all to the fw zone. However, whenever we try to connect to the box from one of the IPs in the admin zone, the packet is dropped by the net2all policy. The admin<->fw policies are above the net<->any policy in the policies file. I habe no rules that involve the admin zone, just the single policy. When I start Shorewall I can see that it ''loads'' the admin zone IPs, so that seems to be OK. The trouble seems to be that the packets aren''t triggering the ''from admin zone'' policy and are therefore falling through to the net to any DROP policy. If I just create a plain old net -> fw policy, then we can connect without issue so the services themselves are set up OK. This is especially perplexing as the same configuration works in 19/20 sites. Anyone have any ideas how to troubleshoot this thing? Thanks Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi Jon, On 12/20/06, Jon <me@jonwatson.ca> wrote:> When I start Shorewall I can see that it ''loads'' the admin zone IPs, so > that seems to be OK. The trouble seems to be that the packets aren''t > triggering the ''from admin zone'' policy and are therefore falling > through to the net to any DROP policy.If you have Log, set on net->any, you can see if these packet trigger that rule: Like so: net all DROP $LOG The log can be setup via ulogd to be any file (in debian /var/log/ulogd/syslogemu )> Anyone have any ideas how to troubleshoot this thing?You can also log the specific connection alone, and see if you can figure out things. shorewall dump > shdump The file has a list of the connections/iptables rules and most of the things needed to debug this problem. Do ensure that you do it immediately before and after trying to establish a connection from the ''affected'' system. Also, do look at the trouble-shooting instructions on shorewall.net http://shorewall.net/troubleshoot.htm and the problem reporting guidelines. http://shorewall.net/support.htm Also, add a specific rule for this IP alone, again with LOG, and see if that helps. Ipsets may also be a possible solution - and might make your setup easier/cleaner. Tom''s out of power and his network connection is down, so I hope your problem is not too hard for the rest of us to solve. Prasanna. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hey Prassana, Thanks for the quick reply. It seems to me that most of these troubleshooting steps would be more useful if I didn''t know what the problem was. I''ve already investigated the logs, etc, and I can see exactly where the problem lies - my default admin zone policy isn''t firing on any of the IPs that are part of the admin zone. I''ve dumped the logs and watched them in real time as I try to connect, and it''s always the same - the packet is dropped under the very last policy, the net2all policy. The question that''s killing me is: why? Thanks! J Prasanna Krishnamoorthy wrote:> Hi Jon, > > On 12/20/06, Jon <me@jonwatson.ca> wrote: >> When I start Shorewall I can see that it ''loads'' the admin zone IPs, so >> that seems to be OK. The trouble seems to be that the packets aren''t >> triggering the ''from admin zone'' policy and are therefore falling >> through to the net to any DROP policy. > If you have Log, set on net->any, you can see if these packet trigger that rule: > Like so: > net all DROP $LOG > The log can be setup via ulogd to be any file (in debian > /var/log/ulogd/syslogemu ) > >> Anyone have any ideas how to troubleshoot this thing? > You can also log the specific connection alone, and see if you can > figure out things. > > shorewall dump > shdump > The file has a list of the connections/iptables rules and most of the > things needed to debug this problem. Do ensure that you do it > immediately before and after trying to establish a connection from the > ''affected'' system. > > Also, do look at the trouble-shooting instructions on shorewall.net > http://shorewall.net/troubleshoot.htm > and the problem reporting guidelines. > http://shorewall.net/support.htm > > Also, add a specific rule for this IP alone, again with LOG, and see > if that helps. Ipsets may also be a possible solution - and might make > your setup easier/cleaner. > > Tom''s out of power and his network connection is down, so I hope your > problem is not too hard for the rest of us to solve. > > Prasanna. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 12/20/06, Jon <me@jonwatson.ca> wrote:> troubleshooting steps would be more useful if I didn''t know what the > problem was.Jon, you may think you know what the problem is, but you may missing something because you''re deep into the problem. Try to go through the steps given on the site methodically, and you may find something you''ve missed, simply because you''re convinced the problem is elsewhere. Also, troubleshooting steps are *NOT* to identify the problem. They are to identify the cause of the problem - deciding that you know what the problem is is different from deciding you know what the cause is. The latter, if premature, will not help you solve the problem :-).> I''ve already investigated the logs, etc, and I can see > exactly where the problem lies - my default admin zone policy isn''t > firing on any of the IPs that are part of the admin zone.If you''ve already investigated the shorewall dump output, you should see the exact iptables rules, and be able to see why that rule is not being triggered? There''s a count of the number of times a rule is triggered too. Also, it''s quite possible that the admin zone itself is specified incorrectly, so that line of the config file may also help us help you.> I''ve dumped the logs and watched them in real time as I try to connect, > and it''s always the same - the packet is dropped under the very last > policy, the net2all policy.Can you do the following and check again? If you can post the (zipped)output of shorewall dump and let us know which source has the problem, perhaps we can help you more.> > You can also log the specific connection alone, and see if you can > > figure out things. > > > > shorewall dump > shdump > > The file has a list of the connections/iptables rules and most of the > > things needed to debug this problem. Do ensure that you do it > > immediately before and after trying to establish a connection from the > > ''affected'' system. > > > > Also, do look at the trouble-shooting instructions on shorewall.net > > http://shorewall.net/troubleshoot.htm > > and the problem reporting guidelines. > > http://shorewall.net/support.htm > > > > Also, add a specific rule for this IP alone, again with LOG, and see > > if that helps. Ipsets may also be a possible solution - and might make > > your setup easier/cleaner.Prasanna. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
That''s good advice. I''ll do some more work and post some snippets. Thanks! J Sent from the road... +1.403.770.2837 -----Original Message----- From: "Prasanna Krishnamoorthy" <prasanna79@gmail.com> Date: Wednesday, Dec 20, 2006 11:12 am Subject: Re: [Shorewall-users] Admin Zone Policy Problem On 12/20/06, Jon <me@jonwatson.ca> wrote:> troubleshooting steps would be more useful if I didn''t know what the > problem was. >Jon, you may think you know what the problem is, but you may missing >something because you''re deep into the problem. T------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
So...turns out that I didn''t understand the problem. I moved a interfaces file from a working machine to this one and I didn''t notice that the NICs on the new machine were in the "reverse" order: eth1 was LAN and eth0 was WAN as opposed to the opposite configuration. All sorts of weirdness came from that :) J Prasanna Krishnamoorthy wrote:> On 12/20/06, Jon <me@jonwatson.ca> wrote: >> troubleshooting steps would be more useful if I didn''t know what the >> problem was. > Jon, you may think you know what the problem is, but you may missing > something because you''re deep into the problem. Try to go through the > steps given on the site methodically, and you may find something > you''ve missed, simply because you''re convinced the problem is > elsewhere. > > Also, troubleshooting steps are *NOT* to identify the problem. They > are to identify the cause of the problem - deciding that you know what > the problem is is different from deciding you know what the cause is. > The latter, if premature, will not help you solve the problem :-). > >> I''ve already investigated the logs, etc, and I can see >> exactly where the problem lies - my default admin zone policy isn''t >> firing on any of the IPs that are part of the admin zone. > If you''ve already investigated the shorewall dump output, you should > see the exact iptables rules, and be able to see why that rule is not > being triggered? There''s a count of the number of times a rule is > triggered too. > > Also, it''s quite possible that the admin zone itself is specified > incorrectly, so that line of the config file may also help us help > you. > >> I''ve dumped the logs and watched them in real time as I try to connect, >> and it''s always the same - the packet is dropped under the very last >> policy, the net2all policy. > Can you do the following and check again? If you can post the > (zipped)output of shorewall dump and let us know which source has the > problem, perhaps we can help you more. > >>> You can also log the specific connection alone, and see if you can >>> figure out things. >>> >>> shorewall dump > shdump >>> The file has a list of the connections/iptables rules and most of the >>> things needed to debug this problem. Do ensure that you do it >>> immediately before and after trying to establish a connection from the >>> ''affected'' system. >>> >>> Also, do look at the trouble-shooting instructions on shorewall.net >>> http://shorewall.net/troubleshoot.htm >>> and the problem reporting guidelines. >>> http://shorewall.net/support.htm >>> >>> Also, add a specific rule for this IP alone, again with LOG, and see >>> if that helps. Ipsets may also be a possible solution - and might make >>> your setup easier/cleaner. > > Prasanna. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Key fingerprint: BDE0 DE52 B8C0 0CDF 7653 E5A2 D861 7877 0D3B 813E http://www.jonwatson.ca +1.403.770.2837 "Trying to learn to hack on a DOS or Windows machine or under MacOS is like trying to learn to dance while wearing a body cast" - ESR ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV