[9fans] NAT implementation

[9fans] NAT implementation

[Patrick Kristiansen]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Hello 9fans.
I'm thinking of writing a NAT implementation for plan 9. I have searched the
archives and I'm not quite sure how to get started.

As I see it there could be three ways of approaching this:

1. User space implementation using ipmux
2. User space using pkt interfaces in ipifc.
3. Kernel using something like sources/dho/nfil

Do you have any advices on how to capture packets and how to send them out
again after replacing src/dst addr and port?

Are there any ways of testing NAT in a virtual machine? Right now I'm using
vmware and it would be nice to be able to test it without setting up a real
machine with two Ethernet interfaces.

-Patrick Kristiansen

[-- Attachment #2: Type: text/html, Size: 866 bytes --]

Re: [9fans] NAT implementation

[Devon H. O'Dell]

2009/4/15 Patrick Kristiansen <patrick.kasserer@gmail.com>:
> Hello 9fans.
> I'm thinking of writing a NAT implementation for plan 9. I have searched the
> archives and I'm not quite sure how to get started.

Hi Patrick,

> As I see it there could be three ways of approaching this:
> 1. User space implementation using ipmux
> 2. User space using pkt interfaces in ipifc.
> 3. Kernel using something like sources/dho/nfil

I think #2 would be an easily testable and maybe more `correct' way to
do this in Plan 9. I think doing an implementation directly in the IP
path is easier, overall, but that's where my experience lies anyway.

nfil is horribly broken. I wrote it some years ago when I was first
getting into Plan 9, Plan 9's C, and kernel stuff. Also, I wasn't
horribly experienced with C at the time either; I think last time I
looked at nfil, there were at least several memory leaks.

> Do you have any advices on how to capture packets and how to send them out
> again after replacing src/dst addr and port?

It's not quite that simple. At the simplest, when the packet goes out,
you have to keep a tab of the destination host / port and source host
/ port. When a packet comes in, you look up the source host / port in
the hash table (hashed by dest host / port). You rewrite the packet.
You have to regenerate the packet checksum after rewriting it. You
send it back out.

(If you're doing the rewriting in userland, you may be able to avoid
doing a recalculation of the checksum, as the kernel may notice it's
bad and re-write it, thinking it's trash).

> Are there any ways of testing NAT in a virtual machine? Right now I'm using
> vmware and it would be nice to be able to test it without setting up a real
> machine with two Ethernet interfaces.

Sure, configure a couple VMs with hostonly networking and set up their
IP addresses accordingly.

> -Patrick Kristiansen

--dho

Re: [9fans] NAT implementation

[Patrick Kristiansen]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

2009/4/15 Devon H. O'Dell <devon.odell@gmail.com>

>
>
> I think #2 would be an easily testable and maybe more `correct' way to
> do this in Plan 9. I think doing an implementation directly in the IP
> path is easier, overall, but that's where my experience lies anyway.
>
Thanks, I'll try that.

>
>
> > Do you have any advices on how to capture packets and how to send them
> out
> > again after replacing src/dst addr and port?
>
> It's not quite that simple. At the simplest, when the packet goes out,
> you have to keep a tab of the destination host / port and source host
> / port. When a packet comes in, you look up the source host / port in
> the hash table (hashed by dest host / port). You rewrite the packet.
> You have to regenerate the packet checksum after rewriting it. You
> send it back out.


I know it's not that simple. But for the rewriting and keeping state stuff,
I can look at the existing implementations of nat, i.e. natd for freebsd.
The thing I need now is the stuff for capturing and sending packets using
pkt interfaces.

>
> > Are there any ways of testing NAT in a virtual machine? Right now I'm
> using
> > vmware and it would be nice to be able to test it without setting up a
> real
> > machine with two Ethernet interfaces.
>
> Sure, configure a couple VMs with hostonly networking and set up their
> IP addresses accordingly.
>
Nice, thanks.

>
> > -Patrick Kristiansen
>
> --dho
>
>

[-- Attachment #2: Type: text/html, Size: 2275 bytes --]

Re: [9fans] NAT implementation

[erik quanstrom]

> Hello 9fans.
> I'm thinking of writing a NAT implementation for plan 9. I have searched the
> archives and I'm not quite sure how to get started.
>
> As I see it there could be three ways of approaching this:
>
> 1. User space implementation using ipmux
> 2. User space using pkt interfaces in ipifc.
> 3. Kernel using something like sources/dho/nfil

one could simply extend ipmux.  however, the primary
drawback to that approach is that it would break most
existing setups that use a public ip stack and a second
private ip stack.

one approach would be to provide a fakey-fakey ethernat
ethernet device which could decide where the frames go.
then the ip stacks could use the ethernat interfaces instead
of the real ones.

- erik

Re: [9fans] NAT implementation

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Wed, Apr 15, 2009 at 02:03:35PM +0200, Patrick Kristiansen wrote:
> I'm thinking of writing a NAT implementation for plan 9.

I would suggest instead that it might be easier to write an adaptor program
for non-Plan 9 hosts which made their network stacks talk to a /net.  That
is, you'd want a program which spoke TAP/TUN out one end to the host kernel
and out the other dialed and imported /net from the Plan 9 gateway.  AFAIK
TAP/TUN-like things exist on most OSes, and there's good example code in
OpenVPN (for example).

The program would have to know enough about the on-the-wire representation
of TCP/IP and UDP/IP to do connection tracking etc. (much like NAT, I
suppose) but the advantage is that it wouldn't impact the Plan 9 kernel.

--nwf;

P.S. This idea shamelessly stolen from vsrinivas, but he's mailing-list shy.

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] NAT implementation

[Anthony Sorace]

the idea is interesting, but it's a compliment, not a replacement.
there's plenty of situations where installing something on all your
hosts is either impractical or undesirable; centralizing the work in
network infrastructure is often a big win. doing what you describe
hits a different set of use cases.

Re: [9fans] NAT implementation

[Devon H. O'Dell]

2009/4/15 Anthony Sorace <anothy@gmail.com>:
> the idea is interesting, but it's a compliment, not a replacement.
> there's plenty of situations where installing something on all your
> hosts is either impractical or undesirable; centralizing the work in
> network infrastructure is often a big win. doing what you describe
> hits a different set of use cases.

This is what I meant to say, expressed in a much nicer, and less
asshole-ish fashion.

--dho

Re: [9fans] NAT implementation

[Devon H. O'Dell]

2009/4/15 Nathaniel W Filardo <nwf@cs.jhu.edu>:
> On Wed, Apr 15, 2009 at 02:03:35PM +0200, Patrick Kristiansen wrote:
>> I'm thinking of writing a NAT implementation for plan 9.
>
> I would suggest instead that it might be easier to write an adaptor program
> for non-Plan 9 hosts which made their network stacks talk to a /net.  That
> is, you'd want a program which spoke TAP/TUN out one end to the host kernel
> and out the other dialed and imported /net from the Plan 9 gateway.  AFAIK
> TAP/TUN-like things exist on most OSes, and there's good example code in
> OpenVPN (for example).

It's not simpler, requiring N implementations for heterogeneity, where
N is the number of non-Plan 9 hosts you support. Certainly Windows,
Linux, OS X, and FreeBSD would all need separate implementations. OS X
doesn't have a tap(4) device per default, and Windows needs a driver
as well. Of course some code can be shared, but I believe this will
simply lead to bloat.

If we want Plan 9 to work with other operating systems, let's make it
work with other operating systems... I don't think forcing everyone
else to conform to us is the right answer, in this case. NAT is
well-defined, well-understood, and honestly not that difficult to
implement.

> The program would have to know enough about the on-the-wire representation
> of TCP/IP and UDP/IP to do connection tracking etc. (much like NAT, I
> suppose) but the advantage is that it wouldn't impact the Plan 9 kernel.

NAT can be implemented in userland in Plan 9 as is.

> --nwf;
>
> P.S. This idea shamelessly stolen from vsrinivas, but he's mailing-list shy.

Not trying to come off as catty, I just don't think this is a
practical idea. Might be a fun project, nonetheless.

--dho

Re: [9fans] NAT implementation

[Anthony Sorace]

i think it's a *great* idea, but it doesn't give you the same things
nat does and isn't useful in the same cases. but i'd love to be able
to import my plan9 /net from my OS X box.

Re: [9fans] NAT implementation

[blstuart]

> i think it's a *great* idea, but it doesn't give you the same things
> nat does and isn't useful in the same cases. but i'd love to be able
> to import my plan9 /net from my OS X box.

It seems a pretty universal opinion that were other OSs
capable of importing a Plan9 /net, their _functioning_ that
way would be much more elegant than NAT.  On the other
hand, having to _implement_ that capability on every OS
we might have on our internal networks and keeping them
up to date as they evolve (for a suitable definition of evolve)
would be much less elegant.

Ideally, there would be one implementation of importing
that would magically work everywhere.  But in the absence
of that, the most useful solution seems to be to implement
NAT on Plan9 (or Inferno).  Machines on the local network
that can import /net will and those than can't will fall back
on NAT.

So I'd love to see an implementation of NAT on Plan9 or
Inferno.  I plan to make use of it on a gateway that lets
me get to the outside world in either mode.

BLS