Comments inline:
Tom Eastep wrote (on Wed, Jun 19, 2002 at 05:55:04AM -0700): | On Wed, 19 Jun 2002, Nachman Yaakov Ziskind wrote: | | > Tom Eastep wrote (on Tue, Jun 18, 2002 at 07:53:08PM -0700): | > | On Tue, 18 Jun 2002, Nachman Yaakov Ziskind wrote: <snip> | > | > | > All my policies are set to ACCEPT, for testing purposes. My RULES file | > | > is unmodified. So the firewall is wide open, right? | > | | > | Yes, plus you don't have to look at any helpful diagnostic messages that | > | way. | > | > I'm ignorant enough not to know if this is sarcasm. Seriiously, shouldn't I | > start with the fireall in a minimalist configuration - to make sure | > everything else works - and then build from there? Isn't it better to | > troubleshoot one piece at a time, rather than try to debug everything at | > once and just get frustrated? | | With only static NAT and MASQ, opening up the firewall as you have done is | fine. In general, I prefer to start with the firewall closed so that I | open only as much as is necessary and no more. Your logs are EXTREMELY helpful for finding the misconfiguration of your configuration. Most of us on the list can find the problem much clearer when this information is provided. Opening the firewall wide open simply hides valuable troubleshooting information on any system. Any change you make from the default setup could be an error as far as any of us know.... ;-) | > | > Problem: from my MASQ'ed boxes, I can see the whole 'NET - except for | > | > the Static NAT boxes. But I can see the Static NAT boxes from the | > | >outside. Also, the Static NAT boxes can see each other (even using the | > | > public IP addresses). | > | > | > | > | Without knowing what your configuration looks like (including IP | > | addresses, subnetting and routing), it's hard to know what's wrong. Sounds like something is definately wrong in your configuration. Posting your configuration file(s) would help us locate the error..... otherwise we're left guessing at what you *might* have done wrong. | > Inside: 10.1.1.0/24, of which the above named hosts are assigned public IP | > addresses, the rest use PAT. Outside: 216.236.142.80/240 are the public | > IP's the router is assigned a public IP on another subnet | > (64.49.72.186/30), and the default gateway is .185 on the same subnet. OK, so what GW are you using on the assigned subnet. You must have some GW on the subnet you are assigned, otherwise your router is simply spewwing garbage to the net. | > | > It is not a DNS problem, as using the public IP addresses is no better | > | > (the private IP addresses work fine). | > | > I'm stumped. How do I troubleshoot this? Ip-spoofing rules block an internal machine from using external addresses on a firewall, though the internal ip's should work fine. Drop the spoofing and you can use the external ip's, but someone from the outside can spoof an internal address and cause you a very bad week..... that's why all LEAF firewall's use ip-spoofing protection as default. >Really?? The firewall does not pass along the ICMP packets to the >destination >host? I'm wondering why this would be. It certainly lessens the value >of the >ping utility ("Ok, host x is up. Unless it's not.") Depends on how you setup the firewall/router. PacketFilter allows no ICMP packets to be routed anywhere by default. I won't guess at your ruleset. | > But the MASQ'ed machines cannot use the public IP | > addresses (they *can* address the Static NAT machines by their RFC 1918 | > addresses), although they can access other part of the Internet. I *think* | > they can ping the public IP's, although I didn't have enough time to make | > sure. That is normal with ip-spoofing protection and the external iface of firewall is responding to the pings, not the static-NAT hosts. This should be the case on any decent firewall ruleset on any OS in my IMHO. >[I have no clue what Bind 9 views is, or how to set it up. But I >suspect it >involves doing things through DNS. I further suspect it will be like >pulling >teeth with every w/s pointing to my ISP's DNS servers. I suppose I >*could* just >load a hosts file on every workstation. Ouch.] Or simply run tinydns.lrp for the internal machines with the ip of the tinydns machine listed in the dhcp server info for you clients. Set it up for local dns and add the SNAT ip's of your servers so the spoofing rules don't bork it by trying to use public ip's to use these servers on the LAN side of the firewall. It only takes roughly a half hour to get this working, rather than waste the time trying to figure out why the spoofing rules are blocking the masq'ed traffic. >and this in /etc/shorewall/rules: > >DNAT loc loc:10.1.1.254 tcp www - 216.236.142.84:10.1.1.200 Your using Static NAT, not dynamic NAT.... this won't work. >This sounds like more work than I'd like to do (right now); maybe >later. > >Actually, I have two local DNS servers, one running NT and the other >SCO Unix >(for extra credit, guess which DNS server crashes three times a day :-) > >Eventually, I'll train the clients to query the local servers, as soon >as I'm >convinced that the situation is stable. > | In either case, you would have to learn how to set up a DNS server. > >Been there, done that. Got the tee shirt. > | Network administration is more than inserting a CD and clicking a couple | of Yes/No boxes. To do it right, you actually have to learn something. | | Sorry.... > > >With six years of Unix admin under my belt, and having just programmed >a Cisco >Pix 506 (to do essentially what Bering will do, someone wants the Pix >back :-() We're not debating qualifications here, simply your configuration is wrong and we don't have the necessary information to really help you. If your internal DNS servers are crashing every 3 days, apparently something is wrong there as well. I feel for you trying to deal with a troubled network and not being able to take the time to understand the system you are configuring more completely. With the correct diagnostics we can help you get past this one, but providing that information is up to you. I can guarentee you that none of us working this list has any desire to hack your network, and if we did, someone could likely do it w/o you providing internal diagrams and configuration information. The SR link at the bottom of this post provides the normal diagnostic information we would love to have (so that we could be of more help). We're also free, that saves you a lot of money compared to many commercial firewall/routing products out there, BUT we are not obliged to blindly guess at what is wrong with configuration information that we're not obliged to see. Many people have setup similar setups with LEAF w/o any problems, or received help to get their network working. Whether you get yours working properly is totally dependant on YOU configuring it properly, and/or YOU providing enough information for us to help you do it. I'm not attempting to flame you, but rather get your system working ASAP I hope this helps, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html