From owner-freebsd-net Mon Oct 2 16:36:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 624B837B502 for ; Mon, 2 Oct 2000 16:36:40 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e92NUda76955; Tue, 3 Oct 2000 00:30:39 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.0) with ESMTP id e92NT9n37409; Tue, 3 Oct 2000 00:29:09 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: natd and userland ppp In-Reply-To: Message from Julian Elischer of "Wed, 27 Sep 2000 10:26:16 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 00:29:09 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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 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