[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is dual NAT possible ?




I have a question regarding rather well known problem where machines on the network behind the firewall try to access a web server located on the same LAN using its translated address. The firewall provides NAT using rdr rule, so machines on the Internet can access this web server. Users on the same LAN may want to connect to it using translated address (may be because administrator did not want to set up split DNS). The problem is that rdr rule does not change the source address in the packet, so the web sever replies directly to the client on the same LAN. The client sees TCP ACK coming from the server's real IP and does not recognize it, since it sent TCP SYN to a translated IP. The connection can not be established.


It seems the problem can be solved by adding yet another NAT rule to the firewall, this time a "nat" rule to translate source IP. Something like this:


rdr proto tcp from any to $ext_address port 80 -> $web_server port 80 nat on ep1 proto tcp from $int_lan/24 to $web_server -> $ep1_addr


"ep1" is an interface connected to internal LAN.


The idea is that PF would perform translation twice on the same packet. First time it would translate destination; this would happen for packets coming from the Internet _and_ for packets coming from internal LAN. Once destination address of the packet has changed, it would match the second rule (if it comes from internal LAN) which should translate its source address.

I expected this to work; looking at the nice PF flow chart at http://mniam.net/pf/pf.png I thought it should. My understanding is that PF runs packets through the rule set twice - once when it enters the firewall and another time when it exits it.

Unfortunately the combination of these two NAT does not work for me. Tcpdump shows that the "nat" rule never works.

What I am doing wrong ?

P.S. I know that setting up split DNS solves the problem. Let's say I have a case where it can't be done.

thanks
Vadim