status report on netfilter 0.1.17 and 2.3.40

Rusty Russell rusty@linuxcare.com.au
Mon, 07 Feb 2000 14:07:55 +1100


In message <004e01bf7113$3995d020$0201a8c0@odie> you write:
> hey rusty ,
> 
> first of all thanks for your answer , i have a clearer view of things now.
> 
> 
> ok 4 questions :
> 
> 1. wouldnt your solution likely screw up a couple of applications ?

Not as much as not passing the packets at all, and no worse than
masquerading (at least we *try* to map packets straight through
first).

> 2. this is starting to sound an awfull lot like masquerading .. too many
> things to keep track of. no ?

Full NAT (NAPT) is ugly.  There is no 100% clean way of doing it.  I
have an architecture which is the closest I know of, however.

> 3.Personally fast nat i find works well ( with some minor piss-offs ), and
> the only big big issue i have with it is the darn active ftp. How was this
> resolved in fast nat compared to here ..
> Fast nat aways happens before fw rules simply because it fits in the routing
> table not the fw rules.
> could a concept used with fast nat be applied somewhat to your ipnatctl and
> keep all the extra functionality of ipnatctl ?

Fast NAT rocks.  But its lack of functionality is exactly why it's so
fast.  Look at the code: it's about 50 lines.  Alexey doesn't need to
track connections or do multiple packet mangles or any of that crap.

For full NAPT (ie. port translation as well) things get... uglier.
That means slower.  But far more powerful for those corner cases
(stateful packet filtering, active FTP, etc).

> 4. is the 0.90 branch going to be any different and how? actually what is
> the 0.90 branch ... i missed that one.

It's what's going to be 1.0.  It uses iptables to control NAT as
well.  Generalizing that has taken way longer than I'd anticipated,
but is having some good side effects.

Hope that helps,
Rusty.
--
Hacking time.