NAT'ing help



  • Hi All,

    I've been beating my head against the wall now for ~2 days, so I think it's about time I get some help. Essentially, what I am trying to do is NAT everything coming in to my WAN VIP (Proxy ARP) to a specific host on my LAN interface. However, when I run a tcpdump, the host on my LAN interface still sees the original source IP of the client on the WAN, instead of the internal IP of the LAN interface. A simple diagram:

    WAN VIP (Proxy ARP, 192.168.100.245)
            |
            |
            |                      10.20.100.0/24
            |___ PFSense___DMZ-INT (LAN)______
                          |                                          |
                          |                                    Appliance (SSL VPN)
                          |_DMZ-EXT (OPT)|
                                      10.0.100.0/24

    The key things to note are:
    a) The default gateway for the appliance is 10.0.100.1 (on the DMZ-EXT interface).
    b) Services need to be access on both the internal and external interface of the appliance (80/443/22 on external, 8443 on internal).
    c) Setting up a portforward to the external interface works fine.
    d) It is not possible to route through the appliance, IE, traffic comes in on DMZ-INT, and leaves DMZ-EXT will be dropped.

    Here is what I did to setup the 1:1 NAT:
    a) Add a Proxy ARP VIP for 192.168.100.245.
    b) Add a 1:1 NAT Mapping.
        Interface -> WAN
        External Subnet -> 192.168.100.245/32
        Internal Subnet -> 10.20.100.115/32 (IP of the appliance on the DMZ-INT interface)
    c) Add a firewall rule:
        Interface -> WAN
        Protocol -> Any
        Source -> Any
        Destination -> Single Host (10.20.100.115)

    When traffic comes in on the appliance's internal interface (via DMZ-INT), I still see the source as being the client IP on the WAN subnet. Since the route to 192.168.55.31 is on the DMZ-EXT interface, the packets get dropped/reset because the traffic is leaving a different interface than what it came in on. It is not possible to route through the appliance.
    HOST115:~# tcpdump -npi eth0 -vvvs0 icmp
    tcpdump: listening on eth0
    08:51:15.259429 192.168.55.31 > 10.20.100.115: icmp: echo request (ttl 125, id 29027, len 60)
    08:51:20.758516 192.168.55.31 > 10.20.100.115: icmp: echo request (ttl 125, id 20063, len 60)
    08:51:26.258657 192.168.55.31 > 10.20.100.115: icmp: echo request (ttl 125, id 37968, len 60)

    It is my understanding that the source should actually be 10.20.100.1. Is that not the case? Is there some other way to do what I want that I'm just not aware of?



  • I have done similiar setups with an ISA server that is connected to the dmz interface of the pfSense with it's external Interface and it's internal interface connected to the lanside of the pfsense without any problems. However your problem seems to be that the appliance is sending out the replies on the wrong interface. 1:1 NAT is not to masquerade the external IP of the requesting host but to forward traffic for an external IP to an internal IP and mapping the traffic from the internal IP to the in 1:1 defined external IP.



  • So I guess there's nothing I can do then, huh? This was working fine with IPTables, I guess I'll just have to stick with that :<



  • You can use custom nat rules to make this work somehow but it's ugly. The problem ist not the pfSense but your appliance or the application (unless I completely misunderstand your setup).



  • As far as I can tell, it's not the appliance. Keep in mind, being able to route through a device (request from internal interface goes out a different/external interface) is a major security problem. Of course, the appliance itself complains about the martian sources. eth0 = internal (10.20.100.0/24) eth1 = external (10.0.100.0/24).

    HOST115:/var/log# grep 10.20.100.115 kern.log | head -5
    Jul 18 15:51:15 127.0.0.1/127.0.0.1 kern.warning martian source 10.20.100.115 from 192.168.55.31, on dev eth0
    Jul 18 15:51:20 127.0.0.1/127.0.0.1 kern.warning martian source 10.20.100.115 from 192.168.55.31, on dev eth0
    Jul 18 15:51:26 127.0.0.1/127.0.0.1 kern.warning martian source 10.20.100.115 from 192.168.55.31, on dev eth0
    Jul 18 17:05:26 127.0.0.1/127.0.0.1 kern.warning martian source 10.20.100.115 from 192.168.55.31, on dev eth0
    Jul 18 17:05:32 127.0.0.1/127.0.0.1 kern.warning martian source 10.20.100.115 from 192.168.55.31, on dev eth0

    What I need to be able to do is masquerade the requests on the VIP (192.168.100.245) to 10.20.100.1. Once that is done, the requests will be coming from 10.20.100.1, and routing works properly.



  • So, I guess my final 2 questions for the developers are:
    a) Why is 1:1 NAT called NAT, when there really is no modification of the source/destination IP's? It seems like this is merely just defining a mapping of some sort, with no translation.
    b) Is this working as designed? In other words, is it just a limitation of how pf works?



  • @kmott:

    So, I guess my final 2 questions for the developers are:
    a) Why is 1:1 NAT called NAT, when there really is no modification of the source/destination IP's? It seems like this is merely just defining a mapping of some sort, with no translation.
    b) Is this working as designed? In other words, is it just a limitation of how pf works?

    a) 1:1 NAT actually does modify IP adresses but only in one direction like any other natting solution does too. It is just a combination of portforward and advanced outbound NAT.
    b) yes, it's working as designed and this is not a limitation. I think you have a wrong understanding what 1:1 nat does.



  • @hoba:

    a) 1:1 NAT actually does modify IP adresses but only in one direction like any other natting solution does too. It is just a combination of portforward and advanced outbound NAT.
    b) yes, it's working as designed and this is not a limitation. I think you have a wrong understanding what 1:1 nat does.

    Allright, so I see the argument for a) as working correctly. Sounds like there's no other workaround for b) though. Thanks for the info hoba, it's MUCH appreciated!!


Locked