Date: Sun, 7 Jul 2002 19:26:53 -0500 From: Redmond Militante <r-militante@northwestern.edu> To: Corey Snow <corey@snowpoint.com> Cc: freebsd-questions@FreeBSD.org Subject: Re: stuck on ipfw/natd config Message-ID: <20020707192653.A363@darkpossum> In-Reply-To: <3D2742F0.18763.65B7745@localhost>; from corey@snowpoint.com on Sat, Jul 06, 2002 at 07:20:16PM -0700 References: <3D27157D.31618.5A9F2A0@localhost>; <20020706183641.C493@darkpossum> <3D2742F0.18763.65B7745@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
--mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello again=20 i've spent the past 48 hrs reinstalling/trying different internet howto's a= nd still no dice.=20 for the record, the first machine has 2 nics, the xl0 is hooked up to a t10= 0 line in the wall, the 2nd is hooked up to a netgear en104tp hublet. the = second machine is hooked up to the hublet. i was thinking that it may be h= ardware related but i've tried having the hublet set to both 'normal' and '= uplink', and stil no dice. i've also tried hooking up the ethernet cable s= traight from xl1 (internal nic on the gateway machine) to the nic on the we= bserver. nothing. i can't retreive any webpages off this machine from a t= hird computer. i also can't bring up any webpages on the webserver when it= 's hooked up to the gateway... On Sat, Jul 06, 2002 at 07:20:16PM -0700, Corey Snow expatiated with great = perspicuity: > On 6 Jul 2002, at 18:36, Redmond Militante wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > hi >=20 > Hey there again. :) >=20 > > well, i want to stick the webserver behind the nat, and still be able t= o serve up pages to the outside world, as well as sit at the machine and su= rf the internet on it, as usual. i want machines outside the internal netw= ork to be able to view webpages that resolve to the webserver's url &/or=20 > proper ip address. so yeah, i want the nat to be invisible to the outsid= e world regardless or which direction the traffic's going to flow... sorry = i didn't make myself clear. > >=20 >=20 > OK, that's a pretty standard configuration. However, you're possibly=20 > confusing NAT with ipfw. They're related and work together, but they=20 > have to be handled seperately. >=20 > For a firewall of type "OPEN" with natd running, you should probably=20 > have a set of firewall rules that look like this (replace <extif>=20 > with your external interface: >=20 > #standard stuff, allow loopback and suchlike > add allow ip from any to any via lo0 > add deny ip from any to 127.0.0.0/8 > add deny ip from 127.0.0.0/8 to any i've checked and these are enabled >=20 > #Divert all traffic to natd >=20 > add divert natd ip from any to any via <extif> > add allow ip from any to any so are these. mine is 'add divert natd ip from any to any via xl0 (externa= l nic on the gateway) >=20 > Now, this minimal set of firewall rules will allow any system behind=20 > your natd firewall to any system reachable via your external=20 > interface. Usually, the external interface is the one that has a=20 > "public" IP address, one that you get from your ISP. >=20 > However, this doesn't get your webserver responding to requests,=20 > because the natd daemon is intended primarily to alllow a group of=20 > systems with non-routable (private or RFC1918) addresses to share a=20 > single public IP. Basically, if a connection is made by a system=20 > behind the firewall, the firewall knows which system made it and can=20 > send the packets coming back in response to that request to the=20 > original requestor, properly translated, of course. But requests=20 > coming from the outside to the public IP of the firewall are dropped=20 > if the firewall doesn't know what to do with them- unless you tell=20 > it, there's no way for it to know what system to deliver incoming=20 > requests to. >=20 > [WARNING! DANGER, WILL ROBINSON! This is a pretty unsecure=20 > configuration. Any machine behind the firewall can go outbound using=20 > the firewall with no restriction, and there is a possibility (not=20 > high, but there) that someone could figure out how to go back=20 > through, because the firewall is of type "OPEN". After you get=20 > everything working to your satisfaction and are more comfortable with=20 > firewall rulesets and natd, I'd recommend changing your firewall type=20 > and/or locking down your rules a bit more.] >=20 > If you want the public IP address to also be able to provide access=20 > to your web server, you'll need to add the following to the=20 > natd_flags section of /etc/rc.conf or pass it on the commandline used=20 > to start the natd daemon, if you're starting it from=20 > /usr/local/etc/rc.d: >=20 > natd_flags=3D"-redirect_address 192.168.0.3:80 1.2.3.4:80" >=20 i then added this line to my /etc/rc.conf - so now the line reads natd_flags=3D"-redirect_address x.x.x.x:80 1.2.3.4:80" x.x.x.x=3Dip of my webserver machine 1.2.3.4 is the ip of xl0 (the dhcp add= ress assigned by my isp) one other thing - we're in a university environment. there are other gatew= ays and routers on the network. i don't know if that has any bearing on wh= at i'm trying to do since i'm only trying to provide ipfw/nat for a small g= roup of machines on my local subnet... another thing i noticed - as soon as i /sbin/ipfw/-f flush /sbin/ipfw add divert natd all from any to any via xl0 (external nic) /sbin/ipfw add pass all from any to any then add the -redirect_address flag to natd_flags in /etc/rc.conf, then reb= oot, the gateway (and any machines hooked up to it) take forever to boot. = the bootup process seems to behalted during the initiation of the sendmail = daemon. i don't know if this has any direct bearing to what i'm trying to = accomplish, thought i'd mention it though. > Or from the commandline: >=20 > #natd -redirect_address 192.168.0.3:80 1.2.3.4:80 when i try to run this from the command line, it tells me the interface is = already in use, i assume it's because natd is initiated automatically by /e= tc/rc.conf >=20 > This assumes that the IP address of the web server is 19.168.0.3 and=20 > that your public interface uses IP address 1.2.3.4. I believe this=20 > should work, or a variation thereof. I've never actually used the=20 > address redirection feature myself, but I know many have=20 > successfully. You may also be able to achieve your goal with the - > redirect_port option. >=20 >=20 > >=20 > > >=20 > > > At any rate, you won't get any traffic through your NAT box unless=20 > > > you have some firewall rules set up. See the FreeBSD handbook,=20 > > > section Advanced Networking for info on setting up NAT and dealing=20 > > > with ipfw. > > >=20 > >=20 > > i had firewall_type=3D"open" in my /etc/rc.conf. wouldn't that at leas= t allow me to serve up webpages at this point, albeit while not having any = firewall rules in place? > > =20 >=20 > See above- you have to have a firewall that allows the traffic, but=20 > you also have to tell natd how to send traffic back and forth. anyways, kind sirs, any words of advice would be greatly appreciated thanks again redmond >=20 > Regards, >=20 > Corey Snow >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9KNxKFNjun16SvHYRAgy/AKCctuXyUIH1dyxT/1qJ09Ii+afjOACgnG7J dCLbkKadP5xsLRjr5YqAGzU=3D =3Dd4Xx -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9KNxMFNjun16SvHYRAtMOAJ9Rnczt5PnM4ckgWnmkC/uadi2PngCeJywL 4o4lLZyQeqgj+sYZNQ5lJC4= =jEzJ -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- 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?20020707192653.A363>