Date: Thu, 3 Feb 2000 09:56:51 -0500 (EST) From: Jim Flowers <jflowers@ezo.net> To: Matthew Hagerty <matthew@venux.net> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: IPFW with NATd Message-ID: <Pine.BSI.3.91.1000203093006.7573A-100000@lily.ezo.net> In-Reply-To: <4.2.2.20000203080148.00abd8a0@mail.venux.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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?Pine.BSI.3.91.1000203093006.7573A-100000>