IPsec Site-to-Site with NAT
-
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?
-
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.
-
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.
-
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.
-
And how do you source connections from that address?
-
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.
-
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.
-
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?
-
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.
-
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.
-
So I'd want the P2 to be like this?
-
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.
-
ICMP comes in and gets NATed, but nothing goes through the IPsec tunnel.
Time to try OpenVPN?
-
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
