From owner-freebsd-isp Thu Feb 3 6:57: 7 2000 Delivered-To: freebsd-isp@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by builder.freebsd.org (Postfix) with ESMTP id B6DD943AB for ; Thu, 3 Feb 2000 06:56:54 -0800 (PST) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id JAA09133; Thu, 3 Feb 2000 09:56:51 -0500 (EST) Date: Thu, 3 Feb 2000 09:56:51 -0500 (EST) From: Jim Flowers To: Matthew Hagerty Cc: freebsd-isp@FreeBSD.ORG Subject: Re: IPFW with NATd In-Reply-To: <4.2.2.20000203080148.00abd8a0@mail.venux.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Insights for NATD. 1. You can have multiple rules each matching a different criteria. It's just a divert hook to the natd process. 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 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. 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. Jim Flowers #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