Subject: Re: nat configuration
To: Brian Somers <brian@Awfulhak.org>
From: Andrew Brown <firstname.lastname@example.org>
Date: 01/21/2001 22:40:50
>> >> >Hmmm.... I just tried it, and now it works! I thought it didn't used to.
>> >> >Either I misremembered, or it's been fixed.
>> >> um...what works? a more current nat can mux pings?
>> >Yes. My 1.5 NAT box seems to be multiplexing pings. I had one box ping
>> >ftp.netbsd.org, and another ping cvs.netbsd.org, and they both worked. My
>> >nat config looks like yours, except that I have my hard IP in there
>> >instead of 0.0.0.0, and I am using the outgoing ethernet card. :-)
>> make it more interesting, just to amuse me? ping the same outside
>> address ( i usually use 18.104.22.168) from two machines inside the nat
>> and lemme know if it works.
>Yes, it works. libalias (used by user-ppp) recognises icmp traffic,
>and nat's the sequence number and IP.
no...what i meant was (a) using the nat built into netbsd-current, (b)
ping one destination from (c) more than one machine behind the nat.
that, i believe, is what doesn't work (at least, not for me). that is
what works using the userspace ppp implementation.
>> >> >All my machines are running 1.5.
>> >> all my machines are running current with less than a two month lag
>> >> behind today.
>> >I hope it didn't get fixed then broken.
>> me too.
>It still works (and will continue to).
using the in-kernel nat, or the userspace one? i know the userspace
>> >> >If it really works with userland ppp (which I thought was a downgrade from
>> >> >1.5's ppp) but not kernel ppp, then there's a ppp bug.
>> >> the userspace ppp is, afaik, a *completely* separate and distinct
>> >> implementation of ppp. all it requires of the kernel is a serial
>> >> interface (with a modem) and a tunnel interface (for packets to go
>> >> through). it's not a downgrade...perhaps a "sidegrade".
>> >I thought they were based on the same ppp project. The reason for the ppp
>> >package was that it's set to version 2.3.11, which is newer than the ppp
>> >in 1.4. But 1.5 and current are using ppp 2.4, which is newer, thus an
>> >overall downgrade.
>> they might have some common roots, if you dig far enough back (like
>> netbsd and freebsd), but the userspace one and the kernel space one
>> are very different.
>user-ppp was originally written by IIJ and was picked up by me and
>almost entirely re-written (multi-link support made this necessary)
are there any common roots with the kernel one, or is it a completely
clean-room re-implementation? i expect that it's completely
>> some examples: the userspace one doesn't use
>> chat...it does it all itself;
>Although it can use an external chat program too (see the man page).
can...can't. doesn't have to.
>> the userspace one does nat all by
>> itself, it doesn't rely on the kernel;
>Using libalias. libalias does a whole bunch of things, including
>non-passive ftp, irc, cuseeme, transparent proxying, pptp, NetBIOS
>and realaudio (smedia).
it's a separate implementation.
>> the userspace one also claims
>> to support mppp, which i've not tried,
>Yep, works nicely with i4b :-)
good to know. :)
>> whereas pppd says that only
>> works under linux. that might sounds a bit slanted, but those were
>> the first things i thought of.
>The only downside with user-ppp is the overhead of passing everything
>out then back into the kernel. This is being addressed (albeit
>slowly) by making user-ppp use netgraph(4) if it's available.
...which, on a fast enough machine, with not too much traffic, ought
not to matter that much. but still...
>> >> the nat (called aliasing) in the userspace ppp is what actually
>> >> handles the multiple outbound pings. i imagine it's fiddling with the
>> >> icmp echo request identifier and using it as it uses the local port
>> >> number rewriting for udp and tcp.
>> >Does it work with that aliasing off?
>> not for me, no, since none of my inside machines addresses are routed
>> back to me properly. that's something i've been meaning to deal with,
>> but haven't yet.
>It'll work with ipnat turned off, but not with user-ppp's -nat (or
>``nat enable yes'') disabled.
of course. i'm beginning to suspect that some people are confusing
what i'm saying.
>> on a side note, i just thougfht about it a tiny bit more and
>> remembered that my nat rules rewrite traffic over ppp0, not tun0,
>> which is what the userspace ppp uses. so, no conflict.
>They shouldn't get in eachother's way.
nope. not at all, unless programmed to. i *could* have the kernel
nat things that go in and out of the tunnel device *before* the
userspace ppp gets it, but that would be wasteful. the userspace
ppp's nat (aka aliasing) is better than ipnat in the kernel.
>I've been intending to make a ppp package for NetBSD, and now see
>that there already is one :-) Now that sup.NetBSD.org exports
>pkgsrc, I'll look into keeping things more ``available'' :-)
yeah...those package guys are really good.
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."