[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: NAT/connection tracking improvement?
From:       Paul Rusty Russell <Paul.Russell () rustcorp ! com ! au>
Date:       1999-11-09 22:34:33
[Download RAW message or body]

In message <Pine.LNX.4.10.9911072054370.796-100000@polymorph.helixsystems.com> 
you write:
> One thing I've noticed looking through the archives of this list is that
> many users are having to set the policy on the FORWARD chain to ACCEPT
> merely to allow masquerading, a step which was not necessary in 2.2. I

Hi Rolf!  Good to hear from you...

> don't like this at all. OK, I could block SYN packets from the outside,
> but that is relatively inelegant and seems incomplete.

I agree: I should emphasize more clearly the state extension (which is
what you want here).  I put an example in the latest version of one of
the HOWTOs.

> The other issue is bidirectional forwarding, aka dual mapping, mbfw (my
> implementation for 2.2; see http://ns1.helixsystems.com/~masq/ for

[snip]...

> Unfortunately, the return path for packets does not go through the
> firewall and the connection is not established.

My recommendation is to explicitly map the source as well as the
destination for such internal situations (I haven't fixed the ICMP
redirect problem for this case, so beware that), so the reply will go
back through the NAT box.  (Rusty sends off mail to netdev...).

> Other, less serious, problems:
> 
> 1. Unless the manpage is wrong (and I'm too lazy to look at yet another
> part of the code), it seems that ipnatctl only takes single ports for its
> tcp protocol mapping, and not ranges of ports (port:port). This is less
> than useful. I want port ranges.

Yep.  It's theoretically possible to have a bitmask on the port, but
ranges are out for the moment.  I'm meeting with Marc Boucher this
weekend in Montreal to discuss packet selection issues...

> 2. Has any consideration been given to the LooseUDP mechanism in 2.2
> intended for UDP games? I don't see this in netfilter's NAT.

I support Dan Kegel's draft on NAT for UDP gaming, but loose UDP is a
not a hot idea for generic NAT.

It would be fairly easy to add this (of course) as a new `loose'
mapping type, which also inserts a rule to catch (and through-map)
packets going to that IP/port.

Rusty.
--
Hacking time.

[prev in list] [next in list] [prev in thread] [next in thread]