Date: Thu, 03 Feb 2000 12:10:37 -0500 From: Matthew Hagerty <matthew@venux.net> To: Jim Flowers <jflowers@ezo.net> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: IPFW with NATd Message-ID: <4.2.2.20000203120447.00a26240@mail.venux.net> In-Reply-To: <Pine.BSI.3.91.1000203093006.7573A-100000@lily.ezo.net> References: <4.2.2.20000203080148.00abd8a0@mail.venux.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the quick response! I do have a few questions though, please see below. At 09:56 AM 2/3/00 -0500, Jim Flowers wrote: >Insights for NATD. > >1. You can have multiple rules each matching a different criteria. It's > just a divert hook to the natd process. Once a packet goes to natd and comes back, can I still qualify the packet based on the original IP address or is it completely gone at this point? >2. You can set up criteria to bypass natd by placing rules that > terminate the ipfw pass ahead of the divert rule. for example: > > 10 allow ip from any to any.that.you.dont.want.to.divert via in.ifc in > >3. ipfw only makes one pass if net.inet.ip.fw.one_pass is set in sysctl How many passes does ipfw normally make? >4. You can run multiple natd with different interfaces such as: > > 100 divert 8668 ip from any to any via wi0 > 101 divert 8669 ip from any to any via ed0 > > You also need multiple natd processes, one at -p 8668 and one at -p > 8669. Each can have its own set of rules (-redirect_port, etc.). > This is useful for having external addresses (via a skip nomad > connection, for example) act as part of the local network for > purposes of wandering around a VPN. Don't quite understand this one. >5. Natd processes should be started AFTER any process that modifies the > interface MTU or there will be difficulties. > >6. Use natd -v to see what is really happening. I'll certainly give this one a try! Thanks, Matthew >Jim Flowers <jflowers@ezo.net> >#4 ISP on C|NET, #1 in Ohio > >On Thu, 3 Feb 2000, Matthew Hagerty wrote: > > This (I was hoping) would allow me to make rules based on certain internal > > hosts, i.e. my internal DNS host needs to talk to my external fake DNS on > > the bastion host, but no other internal host should be allowed to query > the > > external DNS (bastion) host directly, unless a rule is written > specifically > > for it. > > > > I did actually get this to work with the DNS example, my fake DNS on the > > external network could communicate with the internal DNS and > > vice-versa. But when I tried to add a rule to allow the rest of the > > internal hosts to surf, etc. it broke. The only error I got was a "can't > > send packet back" error on the terminal. > > > > Any insight on this would be greatly appreciated. > > > > Thanks, > > Matthew Hagerty To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000203120447.00a26240>