Date: Tue, 03 Oct 2000 00:29:09 +0100 From: Brian Somers <brian@Awfulhak.org> To: Julian Elischer <julian@elischer.org> Cc: Patrick Bihan-Faou <patrick@mindstep.com>, freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: natd and userland ppp Message-ID: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> In-Reply-To: Message from Julian Elischer <julian@elischer.org> of "Wed, 27 Sep 2000 10:26:16 PDT." <Pine.BSF.4.10.10009271015390.15101-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It seems also that some features (such as automatic holes in the firewall
> > and dynamic rules) are a bit tricky to get working properly with aliasing in
> > ppp. Now I probably missed some tricks on that side, so don't flame me
> > because of that last comment, educate me!
>
>
> I'm not an expert on PPP's filtering rules.. I'll let Brian answer that..
The firewall punching stuff is done internally in libalias, so
there's no code duplication there.
I think there's probably room for some sort of ascii interface to
libalias though, including (at least) the natd configuration file
parser. That way ppp could allow ``nat config /etc/natd.conf'' and
could have a generally more compatible (with natd) interface.
> > Well actually, with the "dynamic" option in natd, synchronizing to ppp is
> > really painless (or at least it looks like it is working properly). Thanks
> > to the magic of the routing socket. So this is hardly an argument.
>
>
> well, yes it works..
> I'm not totally sure though if you can do everything quite the same.
One of the more impressive things it can't do is the ``iface-alias''
stuff. This is where ppp keeps the old IP number as an interface
alias, natting already-bound local sockets. This makes the
first-connection problem go away (see the FAQ).
> > > Mpd can use netgraph to do all ppp processing in the kernel to reduce
> > > latency even further, but it doesn't have NAT. You could however combine
> > > it with ipfilter's in-kernel NAT to get an all-kernel solution.
> > > (we need to make a netgraph NAT module but we haven't done it yet.)
> >
> > A netgraph nat module seems to be the way to go... As soon as I have some
> > spare time (wishfull thinking :) I'll look into that.
>
>
> yes I actually was considering using the NAT code from ipfilter
> to do the job..
> the difficulty is deciding exactly wherre and how to slot a NAT module
> in..
>
> if it were attached to an interface, then it would have to know about
> both IP and the MAC levels which would break layering. If it's attached to
> the IP stack (where ipfw presently gets packets for NAT from) then
> it loses some of the niceness of attaching it to an interface.
>
> Maybe it's not really a job for netgraph but a job for an IPFW
> keyword/Module. (then in that case we should look at ipfilter
> again as it isn't going away..)
> Personally I'd like a way of attaching a netgraph node between IP and the
> various interfaces. (I think this could be achieved by
> using the netgraph interface node as a frontend to the actual interfaces
> and not assigning IP addresses to the real interfaces you wanted to
> do NAT on, but instead assign those addresses to teh ng interfaces..
>
> (hmmmm maybe..)
ppp does the libalias stuff at the top of it's stack. From
physical.c:
void
physical_SetupStack(struct physical *p, const char *who, int how)
{
link_EmptyStack(&p->link);
if (how == PHYSICAL_FORCE_SYNC || how == PHYSICAL_FORCE_SYNCNOACF ||
(how == PHYSICAL_NOFORCE && physical_IsSync(p)))
link_Stack(&p->link, &synclayer);
else {
link_Stack(&p->link, &asynclayer);
link_Stack(&p->link, &hdlclayer);
}
if (how != PHYSICAL_FORCE_SYNCNOACF)
link_Stack(&p->link, &acflayer);
link_Stack(&p->link, &protolayer);
link_Stack(&p->link, &lqrlayer);
link_Stack(&p->link, &ccplayer);
link_Stack(&p->link, &vjlayer);
#ifndef NONAT
link_Stack(&p->link, &natlayer);
#endif
.......
The NAT has to happen there because of all the compression and other
mucking about.
Eventually (I say after having done nothing about this in the last
year), I would like to convert each of the above layers into a module
that will compile either as a lump of userland code or as some sort of
netgraph kld plugin.... the idea being that ppp can decide at run
time whether it'll use kernel or userland functionality, getting the
same results either way.
The approach would be that if the user doesn't specify what
they want, they probably want everything in the kernel. If
everything can't be implemented in the kernel, then as much as
possible should be implemented outside of the kernel. Some day, I'll
get some time to do this stuff....
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010022329.e92NT9n37409>