Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Oct 2000 10:37:44 -0700
From:      Dan Yergeau <yergeau@gloworm.Stanford.EDU>
To:        freebsd-questions@freebsd.org
Subject:   Re: NAT, firewall, public and private subnets 
Message-ID:  <200010051737.KAA26172@gloworm.Stanford.EDU>
In-Reply-To: Your message of "Tue, 03 Oct 2000 01:24:53 MST." <20001003012453.S25121@149.211.6.64.reflexcom.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

Thanks for the advice and clarifications.

I ended up going with.  However, it was necessary to add
P.U.B.19[5678] aliases to the pub1 interface to get our ISP to route
packets over the DSL link to those IP's.  Consequently, in addition
to the freebsd box not being able to connect to the other public
addresses (because those packets don't get run through NAT), packets
sent from the internal private IP's to the other public IP's all go
to the freebsd box.  Although this is a little annoying, I can live
with this.

Is there something that I missed with the natd/ipfw configuration
that may give this setup a better chance of getting external packets
routed to the redirected public addresses w/o aliases on the public
interface?  Currently, firewall_type="open" (I'll get around to
tightening this eventually), and the contents of natd.conf are:

 redirect_address p.v.t.195 P.U.B.195
 redirect_address p.v.t.196 P.U.B.196
 redirect_address p.v.t.197 P.U.B.197
 redirect_address p.v.t.198 P.U.B.198

Surprisingly, this config does not cause any problems tapping into
the kerberos/AFS infrastructure at Stanford (at least not for the
machines with redirect_address entries).  I (and many others) have
had problems with other NAT'd setups (kerberos must try to open a
socket back to public address used by NAT, which wouldn't
automatically be diverted to the internal address of the machine
trying to use kerberos).


Dan


>> 2) DSL <==> pub1/freebsd/pvt0 <==> switch <==> all machines with private IP
>>     pub1 is P.U.B.194 with aliases of P.U.B.19[5678]
>>     pvt0 is p.v.t.99 (used as the gateway for the public and private
>>                       machines) 
>>     natd -n pub1 -f /etc/natd.conf
>>    
>>     /etc/natd.conf had redirect_address entries for the 4 remaining
>>     public IP's, mapping each of p.v.t.19[5678] to the equivalent
>>     P.U.B.19[5678]
>
>This sounds like the best way to go.
>
>>     The only glitch here appeared to be that the freebsd box and
>>     private IP machines couldn't get through to the public IP of the
>>     4 remaining public IP's.  I suppose that I could do an internal
>>     DNS server to remap hostnames to the private IP addresses, but
>>     that seem like a hack.  I also didn't test tapping into
>>     AFS/kerberos, which doesn't get along well with translated IP
>>     addresses.
>
>Oh, boy. This comes up _again?!_ Second reply on this
>tonight. Internal packets bound for the machine itself are accepted by
>the machine before they get processed by the external
>interface. Therefore they never get run through NAT. 
>
>However, I think this should only be a problem for the NAT machine's
>"true" public IP. IIRC, you do _not_ need to alias the external
>interface of the NAT machine to the other addresses,
>P.U.B.19[5678]. Redirects from internal machines should work fine if
>the interface is not aliased. The machine will try to route the
>packets to the outside, so they are processed on the external
>interface and redirected (and incoming traffic from the outside should
>sill work without the aliases).


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010051737.KAA26172>