>To: tech-net@NetBSD.org
>Subject: ipnat.conf problem
>Date: Thu, 11 Nov 2004 14:57:10 +0100

>A problem with ipnat.conf on any NetBSD version.

>This setup completely screw FTP (it seems active FTP will work a bit
>while passive FTP won't work at all):
>map pppoe0 192.168.x.0/24 -> 0/32 proxy port ftp ftp/tcp
>map pppoe0 192.168.x.0/24 -> 0/32 portmap tcp/udp 40000:60000
>map pppoe0 192.168.x.0/24 -> 0/32

>This is the correct setup:
>map pppoe0 192.168.x.0/24 -> 0/32 portmap tcp/udp 40000:60000
>map pppoe0 192.168.x.0/24 -> 0/32 proxy port ftp ftp/tcp
>map pppoe0 192.168.x.0/24 -> 0/32

>The importance of rule ordering does not seem to be documented, and it
>is not trivial to guess why the second setup is right and the first is
>wrong. I personnaly can't understand what makes the first setup wrong.

>Can someone explain me why ordering is important here? Why isn't this
>documented? Could it be fixed so that ordering wouldn't matter?

That's interesting?!!? What you say above is exactly at odds with what
the ipf how-to says.

From the ipf how-to:
http://www.obfuscation.org/ipf/ipf-howto.pdf

	From section 4.8: "For example; FTP. We can make our firewall pay attention
	to the packets going across it and when it notices that it’s dealing
	with an Active FTP session, it can write itself some temporary
	rules, much like what happens with keep state, so that the FTP data
	connection works. To do this, we use a rule like so:

	  map tun0 192.168.1.0/24 -> 20.20.20.1/32 proxy port ftp ftp/tcp

	You must always remember to place this proxy rule before any portmap rules,
	otherwise when portmap comes along and matches the packet and rewrites
	it before the proxy gets a chance to work on it.
	Remember that ipnat rules are first-match."

Just for completeness ipf (of which ipnat is a part) has a homepage with
a rich set of links and a devoted email list at:
http://coombs.anu.edu.au/~avalon/

You might try asking your question of the ipf mailing list if no one here knows.

Thanks,
gene