Kernel NAT issues

Nathan Aherne nathan at reddog.com.au
Tue Oct 13 02:31:06 UTC 2015


I sent through a question to this list a little while ago and have been trying to get IPFW NAT working since then. I have had some success but not the success I need, everything is working correctly except NAT rules for my particular use case. 

I have read every Google result on the first 50 pages when searching for “IPFW NAT” or “IPFW kernel NAT”. I would really appreciate it if someone could help me out.

My use case is as follows:

1. I need to use hairpin NAT - I am using Jails behind a http proxy and some jails need to be able to communicate with each other but only over the WAN IP. This is why I have not use PF.
2. Some jails need to be able to communicate with each other on the private interface (lo1)
3. IPFW is configured as default deny
4. Each jail has a list of allowed ports for incoming and outgoing connections, these are set on the jails private IP (10.0.0.0/16)
5. I am using a stateful firewall.

At the moment I am testing my IPFW ruleset using “host google.com <http://google.com/>” I can see the traffic leave the Jail, get natted, the response come back from 8.8.8.8 and the traffic is then denied. It seems like the state is not being checked or my rules are in the wrong place. I feel that I should be able to fix this but I am obviously misunderstanding is how NAT works. 

I was under the assumption that traffic flowed like this:

1. Traffic comes from Jail 10.0.0.1 on lo1 interface, if traffic is for public IP, the traffic is natted, it goes out the WAN interface, comes back, is natted and switched to lo1 interface, state is checked and it passes as returning traffic.

2. Traffic comes from Jail 10.0.0.1 on lo1 interface, if traffic is for private IP, the traffic is not natted, it stays on the lo1 interface and goes directly to the 10.0.0.2 Jail.

I know I could answer my last question if “I read the code” and I have tried but am not getting it. Is my understanding of IPFW kernel NAT correct?

Regards,

Nathan



More information about the freebsd-ipfw mailing list