atom feed61 messages in org.freebsd.freebsd-questionsRe: ip masquerading
FromSent OnAttachments
Clint MarekMay 16, 1996 8:02 pm 
Doug WhiteMay 17, 1996 11:33 am 
Tony KimballMay 17, 1996 2:11 pm 
Terry LambertMay 17, 1996 2:23 pm 
Tony KimballMay 17, 1996 6:04 pm 
Archie CobbsMay 17, 1996 6:05 pm 
Terry LambertMay 17, 1996 6:13 pm 
Tony KimballMay 17, 1996 7:46 pm 
Terry LambertMay 17, 1996 10:48 pm 
Archie CobbsMay 18, 1996 1:23 am 
francis yeungMay 18, 1996 5:26 am 
Bruce A. MahMay 18, 1996 8:43 am 
Eric J. SchwertfegerMay 18, 1996 11:06 am 
Stephen HoveyMay 18, 1996 11:59 am 
Archie CobbsMay 18, 1996 1:05 pm 
Terry LambertMay 18, 1996 3:15 pm 
Clint MarekMay 18, 1996 10:09 pm 
Michael SmithMay 18, 1996 10:36 pm 
Tony KimballMay 19, 1996 12:50 am 
Carl MakinMay 19, 1996 5:01 am 
Pedro A M VazquezMay 19, 1996 6:01 am 
Michael SmithMay 19, 1996 7:40 am 
Charlie ROOTMay 19, 1996 4:37 pm 
Michael SmithMay 19, 1996 7:07 pm 
Garrett WollmanMay 20, 1996 7:40 am 
Bruce A. MahMay 20, 1996 8:37 am 
Tony KimballMay 20, 1996 11:48 am 
Jim DennisMay 20, 1996 12:47 pm 
Garrett WollmanMay 20, 1996 1:29 pm 
Tony KimballMay 20, 1996 1:36 pm 
Terry LambertMay 20, 1996 3:22 pm 
Terry LambertMay 20, 1996 3:28 pm 
Terry LambertMay 20, 1996 3:32 pm 
Gary PalmerMay 20, 1996 3:34 pm 
Archie CobbsMay 20, 1996 3:42 pm 
Terry LambertMay 20, 1996 3:45 pm 
Terry LambertMay 20, 1996 3:56 pm 
Terry LambertMay 20, 1996 4:15 pm 
Tony KimballMay 20, 1996 4:54 pm 
Tony KimballMay 20, 1996 5:09 pm 
Bruce A. MahMay 20, 1996 5:10 pm 
Bruce A. MahMay 20, 1996 5:23 pm 
Tony KimballMay 20, 1996 5:25 pm 
Michael SmithMay 20, 1996 6:38 pm 
Terry LambertMay 20, 1996 6:47 pm 
Jim DennisMay 20, 1996 8:13 pm 
Tony KimballMay 20, 1996 8:24 pm 
Jim DennisMay 20, 1996 9:14 pm 
Terry LambertMay 20, 1996 9:30 pm 
Terry LambertMay 20, 1996 9:34 pm 
Tony KimballMay 20, 1996 10:02 pm 
Bruce A. MahMay 20, 1996 10:12 pm 
Bruce A. MahMay 20, 1996 10:44 pm 
Tony KimballMay 20, 1996 10:47 pm 
M.R.MurphyMay 21, 1996 5:59 am 
Carl MakinMay 21, 1996 6:46 am 
Terry LambertMay 21, 1996 10:40 am 
Terry LambertMay 21, 1996 10:45 am 
Scott BlachowiczMay 22, 1996 9:28 am 
Pedro A M VazquezMay 22, 1996 11:13 am 
Bill FennerMay 22, 1996 11:45 am 
Subject:Re: ip masquerading
From:Archie Cobbs (arc@whistle.com)
Date:May 18, 1996 1:23:58 am
List:org.freebsd.freebsd-questions

Actually, it requires a "socks" layer in the TCP/IP code you put in your toaster.

It's not like you can ROM GPL'ed Linux code anyway, which is the only place masquerading is implemented.

Sorry, but my toaster is not going to fulfill host requirements. In order to conform to rfcs, I need something to provide masquerade for my toaster, otherwise I will never be able to turn of the stupid thing when I'm in Bangkok, and the flaming pop-tarts will burn down my house.

Well, feel free to write "masquerading" instead of a socks tunnel; it should take you about twice as long. No skin off my nose.

You might be real pissed when you try to get it integrated into the kernel sources, though... I don't think Garrett has gone insane yet.

I've already written masquerading (I call it "address translation") as part of a revised user-land PPP daemon, and it works great... even handles FTP control stream hackery. Of course, this has nothing to do with PPP. It's only because PPP, using /dev/tun0 on one side and a serial link on the other, can act as such a filter.

I strongly agree it would be nice (and morally correct) to keep this type of hackery out of the kernel.

There's a larger question here then, which is that we need a more general mechanism for user-land "filtering" (in the most general sense) of packets as they cross an interface. BPF and /dev/tun? are both great, but you can't implement a filter with them.

Firewalling, encryption, and accounting are examples too.

Poul-Henning suggested some ideas about this a while back, but I haven't heard if he plans on developing them.

A simple idea would be to have "detour" devices where you could open /dev/filteri0 and /dev/filtero0, attach them to some interface, and have all packets (optionally before or after (de)fragmentation) passing through that interface routed up one and down the other.

Better yet, with devfs, they could even have names like /dev/if_ed1 and /dev/of_ed1 and no binding operation would be necessary. Then the picture would look roughly like this:

--> /dev/if_ed1 --> / \ network <--> interface ed1 <--> <--> kernel routing \ / <-- /dev/of_ed1 <--

When either file is not open, packets pass normally without the detour, and with normal kernel speed. When one is open, you get to play your games with them but pay a penalty in speed. In the same way that user land PPP has become more popular and widely developed than kernel land PPP, even though it is supposedly slower, I think something like this would also be a net gain both for fostering useful developments and fighting kernel bloat.

I guess you could also do this just using the existing tunnel devices with some kind of "redirect" ioctl().

Terry, what do you think of this idea? How would you design a general purpose user land filtering mechanism?

-Archie