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

Reply via email to