IPsec Site-to-Site with NAT



  • Hello! I am trying to use 8 public IP addresses as the IPs for some hosts on my network using 1:1 NAT. The IPs are IP aliases on a VPS running pfSense, and the hosts are on a Unifi USG-Pro-4. The traffic flow should be Public IP>pfSense>IPsec>USG>LAN>Host. If the P2 is setup as Routed VTI, everything works nearly flawlessly except for traffic incoming from the public IPs isn't getting NATted, so the host on the USG network doesn't know how to get the traffic back out over the IPsec tunnel. If I try to setup the IPsec as an IPv4 tunnel policy based routing, I get the tunnel up, but no traffic ever passes. The firewall on each side is set to Allow Any/Any for testing.

    Basically, is there a way to NAT traffic before it enters an IPsec tunnel when using IPsec vti, and if not, where can I begin troubleshooting my current Policy Based IPsec tunnel?


  • Global Moderator

    can you show NAT configuration



  • Here is a copy/paste of my last email going off to Ubnt support as they have been trying to help on this as well.

    I am unable to ping from the pfSense side to the host on the USG over the tunnel, but the host is able to ping the tunnel ip. The nat ip was changed to 172.21.69.1. The windows server (and thus the USG) can reach the ip 172.21.69.1 without issue, and the IPsec tunnel shows the imp packets going out and back in correctly.

    Screen Shot 2019-08-22 at 2.12.59 PM.png
    Screen Shot 2019-08-22 at 2.13.47 PM.png

    However, when pinging the public ip 54.39.14.0 which has 1:1 nat to 172.21.0.23, traffic never even leaves the IPsec tunnel, and the packet count never changes.
    Screen Shot 2019-08-22 at 2.15.08 PM.png
    Screen Shot 2019-08-22 at 2.15.31 PM.png

    Additionally, here is the P2 as configured on the pfSense side.
    Screen Shot 2019-08-22 at 2.21.45 PM.png



  • Basically I have no clue what I should be doing with NAT in this situation, I have a 1:1 setup to forward incoming traffic on 54.39.14.0 to the host at 172.21.0.23, but have no clue what else I need to do with nat. I'm assuming the issue is related to nat because no packets ever leave the pfSense router over the IPsec network.


  • LAYER 8 Netgate

    The problem in that situation is generally that the far side will not route traffic back to arbitrary source addresses over the tunnel.

    You could outbound NAT on the IPsec tunnel there but that does not work with pfSense IPsec VTIs.

    OpenVPN would probably work for you if the USG has something equivalent to reply-to.



  • In this case my USG side is setup to route traffic back to the pfSense at the 172.21.69.1. I'm trying to do policy based routing because I had read NAT doesn't work with IPsec VTI on pfSense. I have no clue how to go about setting up the outbound NAT correctly, I've tried and failed repeatedly. Wouldn't the outbound NAT be needed to translate traffic coming in on 54.39.14.0 to something that hosts on the USG side would be able to send traffic back to?


  • LAYER 8 Netgate

    Outbound NAT does not work on IPsec VTI interfaces.

    OpenVPN works.



  • Ahh. I was under the impression that it would work if using an IPv4 tunnel rather than the VTI tunnel.


  • LAYER 8 Netgate

    You can many-to-one NAT or 1:1 NAT if you like on a policy-based tunnel. Just add the NAT address/network to the phase 2 entry.

    the other side will be configured with the NAT addresses as the remote network in the traffic selector.



  • It's setup that way, it's a policy based tunnel but no source NAT is actually occuring, nor is any traffic flowing over the tunnel.


  • LAYER 8 Netgate

    What is Address 54.39.14.0? That is a network address not a host address in almost all cases.



  • Its an IP provided by the hosting provider the pfSense box is running on, to be setup as a virtual/failover ip. They just assigned 8 ips rather than a routed block.


  • LAYER 8 Netgate

    And how do you source connections from that address?



  • Screen Shot 2019-08-25 at 1.03.38 PM.png

    They are just setup as Virtual IPs on the WAN interface. Browsing to one that hasn't been setup yet with 1:1 nat takes you to the pfSense login page (https://54.39.70.254/), and those addresses reply to ICMP requests, so I know that part is good.


  • LAYER 8 Netgate

    Well whatever is set up on WAN has nothing to do with the IPsec NAT.

    That configures what happens to the NAT in the tunnel itself.

    When the other side connects to 172.21.69.1 what do you want to happen?

    Specifically, what connecting to what is not working?



  • I want to be able to connect to say, 54.39.70.254 in a web browser, and have it show content from 172.21.0.11. From my understanding, I'd need source NAT for the incoming traffic, and a 1:1 NAT for traffic for External IP>Internal Host IP.


  • LAYER 8 Netgate

    @jf5264835

    jf5264835 less than a minute ago

    I want to be able to connect to say, 54.39.70.254 in a web browser,

    Connect to that from where?


  • LAYER 8 Netgate

    If you are talking about connections coming into WAN then out over the IPsec to a server across the tunnel then that is not the correct method.

    You would need to set the source on the phase 2 to Network 0.0.0.0/0 with a NAT to Address 54.39.14.0 to make that traffic interesting to IPsec. The WAN external 1:1 address in that case would be 54.39.70.254, not 54.39.70.0.



  • Anywhere. Public IP address, so basically anywhere,anytime.


  • LAYER 8 Netgate

    When a connection attempt comes into WAN, the 1:1 NAT translates the destination address. When the connection goes out the IPsec tunnel the NAT there translates the source address.



  • Screen Shot 2019-08-25 at 1.23.29 PM.png

    So I'd want the P2 to be like this?


  • LAYER 8 Netgate

    It has to be to have a hope of the traffic being put into IPsec at all.

    OpenVPN is much more flexible in this regard, but IPsec might be able to be coerced to work.



  • Screen Shot 2019-08-25 at 1.57.13 PM.png

    ICMP comes in and gets NATed, but nothing goes through the IPsec tunnel.
    Screen Shot 2019-08-25 at 1.59.35 PM.png

    Time to try OpenVPN?


  • LAYER 8 Netgate

    That does not look like the traffic is being picked up by the traffic selectors after the NAT happens. It looks like it is just going back out the WAN.

    I was expecting you to be pinging .254 from the outside, not .0



  • I was using the .254 as an example, been primarily trying things with just the .0.


  • LAYER 8 Netgate

    What is the output of swanctl --list-sas ??



  • con1000: #156, ESTABLISHED, IKEv1, 07efff97c8376e52_i* 1270ead44af08916_r
      local  '167.114.185.196' @ 167.114.185.196[4500]
      remote '76.31.172.16' @ 76.31.172.16[4500]
      AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
      established 38s ago, reauth in 27959s
      con1000: #70, reqid 6, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
        installed 38s ago, rekeying in 2759s, expires in 3562s
        in  c91e225c,      0 bytes,     0 packets,    38s ago
        out ca6a137a,      0 bytes,     0 packets
        local  54.39.14.0/32|/0
        remote 172.21.0.0/24|/0
    


  • Well, doesn't matter now, I got it properly working using OpenVPN, took all of an hour including coffee time, vs IPsec which has been weeks in the making. Thank you for steering me into the light @Derelict


Log in to reply