IPFilter RDR rules [was: IPFilter issue in -current]

[Geoff Adams <gadams+netbsd%avernus.com@localhost>]

On 8 Jan 2013, at 4:52 AM, Darren Reed <darrenr%netbsd.org@localhost> wrote:

> Lets try with better rules to start with and replace the map rule with these
> two map rules:
> 
> map wm0 192.168.10.0/24 -> 0/32 portmap 10001-49151 tcp/udp
> map wm0 192.168.10.0/24 -> 0/32

Whoops. I skipped an important rule. That should have been:

map wm0 192.168.10.0/24 -> 0/32 portmap tcp/udp 40000:60000
map wm0 192.168.10.0/24 -> 0/32

rdr wm0 7.8.9.10/32 port 56789 -> 192.168.10.11 port 56789 tcp/udp

That first line is why the port numbers are being rewritten, of course. (Is the 
difference in the syntax you show above significant? What I have is what I've 
seen in online docs.)

So, with the rdr rule written that way (or with it moved to be first in the 
ipnat.conf file) I get lots of rdr failures of the kind I described before: 
Incoming connections half-match existing NAT table entries, and are dropped, 
leaving the incoming connection broken. If I change the rdr rule to this:

rdr wm0 0/32 port 56789 -> 192.168.10.11 port 56789 tcp/udp

Then the rdr failures go away, but it also doesn't work. (No RDR entries are 
ever created in the NAT table, and no incoming connections succeed.)

I suspect the correct solution is to this:

# Handle most NAT clients
map wm0 192.168.10.0/24 -> 0/32 portmap tcp/udp 40000:60000
map wm0 192.168.10.0/24 -> 0/32

# Open connections both ways for internal host 192.168.10.11:56789
rdr wm0 7.8.9.10/32 port 56789 -> 192.168.10.11 port 56789 tcp/udp
map wm0 from 192.168.10.11/32 port = 56789 to any -> 0/32 portmap tcp/udp 56789

This seems to work, and it's basically what I described yesterday. (The order 
of that last rule isn't important, because it has a /32 netmask.) It seems 
non-obvious, though. I wonder how people who haven't been mucking around in the 
internals of the kernel would discover that there's even a problem without that 
last line. Is this technique documented somewhere, and I've just missed it?

Perhaps the way RDR processing works could be tweaked, since it seems like 
there may be a lot of cases in which an RDR rule ends up with an obscurely, 
slightly broken NAT router.

Cheers,
- Geoff