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 <[EMAIL PROTECTED]> 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 > [email protected] > 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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
