1:1 NAT with IPSec
-
Hi,
I have two offices connected with IPSec, so that LAN from Office0 has access to LAN from Office1 and vice versa.
The WAN interface in Office0 is configured with a static public IP with netmask /28 - I own the whole segment. I have a bunch of public IPs from that segment already defined as Virtual IPs and I have a 1:1 NAT rule for each one of them that points to a server that is also in
Office 0 LAN
. This works without any issues.Now, I want to make a 1:1 NAT in
Office0
but instead of mapping to a server inOffice0 LAN
, I want to map to a server inOffice1 LAN
. In other words: On pfSense in Office0, in the "Internal IP" field in the 1:1 NAT configuration, I would like to specify an IP that is fromOffice1 LAN
. I tried and it does not work.Is this possible? Any idea how can this be implement?
Thank you!
-
@pvn Be sure the target server is actually responding. 1:1 NAT does not care which interface it is set to use on the inside.
The usual NAT troubleshooting will apply:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat.html
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-1-1.html
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html
-
@derelict Yes, the target server is responding. I can ping it from Office0 LAN.
I have configured an additional IPSec P2 entry that allows me to route traffic between Office0 WAN /28 public network and Office1 LAN. Now, I can ping the target server from Office0 WAN network via the IPSec tunnel.
When I ping the Virtual IP (in Office0 WAN) that maps to the target server (in Office1 LAN) from Internet, I get something like this on pfSense Office0 (using tcpdump):
ICMP sender's public IP --> Virtual IP Office0 WAN
ICMP sender's public IP --> IP of the target server in Office1 LANAnd this is where it stops. I guess it stops because the ping is coming from the machine that actually sends the ping and not from the Virtual IP as I initially thought it would happen. I am still at a loss.
-
@pvn 1:1 NAT does not translate source addresses on out _> in connections. It translates the destination address. it translates the source address for In -> Out connections.
You probably want to post both the NAT translation that works and doesn't work along with the pertinent firewall rules passing the traffic.
-
@derelict In summary:
This works:
Internet -> Office0 Virtual IP -> server in Office0 LAN
This does not work:
Internet -> Office0 Virtual IP -> server in Office1 LANI don't think this is a firewall issue but rather NAT/routing issue. Might be wrong though.
On both pfSense servers all traffic is allowed in the IPSec firewall tab (any to any).
In Office0 on WAN interface all traffic from any to Office0 Virtual IP is allowed
In Office0 on WAN interface all traffic from any to the target server (in Office1 LAN) is allowed -
@pvn NAT doesn't route anything. There has to be a reason it is not working. You are probably going to have to post more information such as screen shots of what you have actually configured.
-
@derelict adding some screenshots. Let me know if I missed something.
-
So 10.0.0.0/16 and 10.1.0.0/16 are both the Remote networks for different IPsec tunnels?
The tunnels would have to be configured to send traffic to arbitrary addresses (0.0.0.0/0) back though the tunnel for reply traffic to work correctly.
Your WAN rules need to pass traffic to 10.1.1.237 and 10.0.0.175, not the outside VIPs since NAT happens before firewall rules are checked.
-
@derelict said in 1:1 NAT with IPSec:
So 10.0.0.0/16 and 10.1.0.0/16 are both the Remote networks for different IPsec tunnels?
No.
10.0.0.0/16 is the local Office0 LAN network.
10.1.0.0/16 is the local Office1 LAN network.
Both are connected via single IPSec tunnel.
10.0.0.175 is local to Office0
10.1.1.237 is local to Office1 which means it is remote to Office0.The tunnels would have to be configured to send traffic to arbitrary addresses (0.0.0.0/0) back though the tunnel for reply traffic to work correctly.
I don't understand that. Could you please elaborate?
Your WAN rules need to pass traffic to 10.1.1.237 and 10.0.0.175, not the outside VIPs since NAT happens before firewall rules are checked.
I see. Thanks! -
@pvn So what does IPsec have to do with anything?
-
@derelict Office0 reaches 10.1.1.237 which is in Office1 LAN via the IPSec tunnel.
-
@pvn Going to need a diagram. I can't make sense of what you are saying.
-
@derelict Hope this will bring some clarity
-
@pvn The IPsec tunnel will need a Phase 2 for all traffic:
0.0.0.0/0 <-> 10.1.0.0.16 or the reply traffic for the inbound connections will follow its routing table (go out WAN there).
OpenVPN is much more friendly to such NAT configurations.
A phase 2 for the WAN addresses does no good because the source address of the traffic is "any" " or "any address on the internet".
You could, perhaps, make a P2 like this on Office 0:
Local Network: 0.0.0.0/0
NAT Address: Any unused RFC1918 address, say 10.11.12.13/32
Remote Network: 10.1.0.0/16On Office 1:
Local Network: 10.1.0.0/16
Remote Network: 10.11.12.13/32That should work. The caveat would be you will lose all of the source addresses at Office 1 because all connections inbound will appear to come from source 10.11.12.13.
-
@derelict Genius! I never considered 0.0.0.0/0 as a Local Network in IPSec. That was the key!
Thank you very much. I learned something new. I owe you lunch!
-
@pvn That can have odd effects on the Office 1 side since all traffic will be interesting to IPsec.
-
@derelict Yep, we discovered that the hard way. I had to remove the P2 with 0.0.0.0/0.