[UNRESOLVABLE] ]IpSec and 1:1 NAT with different subnet size

Quirinius · Nov 7, 2016, 8:52 PM

For days I am completely stuck with the following situation:


local-pfSense                                   Amazon remote-IPsec
**192.168.77.0/24**   <=== IPsec (main mode) ===>   **192.168.0.0/10**

Of course there is the need to add 1:1-NAT in IPsec-Phase-2


_Mode:_                   Tunnel IPv4
_Local Network:_          LAN subnet
_NAT/BINAT translation_   Network       172.19.0.0/16
_Remote Network:_         Network       192.168.0.0/16

Is this correct so far?

Facts:

Tunnel is up
SPDs

| Source | Destination | Direction |
| 192.168.0.0/16 | 172.19.0.0/16 | |
| 192.168.77.0/24 | 192.168.0.0/16 | >Outbound |

The last one seems a little bit weird to me…
No traffic through tunnel
Firewall is open for ICMP - no block log entries
No Additional Routing, Gateway, NAT configured (except to for WAN)

Observations:

remote@192.168.1.12$ ping 172.19.77.1
pfSense Packet Capture on ipSec-Interface

IP 192.168.1.12 > 172.19.77.1: ICMP echo request,
IP 192.168.1.12 > 172.19.77.1: ICMP echo request,

No other traffic; no responses;
local@192.168.77.33$ ping 172.19.1.12
pfSense Packet Capture on LAN-Interface

IP 192.168.77.33 > 172.19.1.12: ICMP echo request,
IP 192.168.77.33 > 172.19.1.12: ICMP echo request,

No other traffic; no responses;
Finally pfSense Packet Capture on WAN-Interface: (seems legit to me)

IP 192.168.1.12 > 172.19.77.1: ICMP echo request,
IP 192.168.1.12 > 172.19.77.1: ICMP echo request,

But also no responses.

Please help me to solve the knot in the brain. Any ideas? Missunderstanding by me about NATing?

Quirinius · Nov 13, 2016, 11:04 AM

I recognized that the scenario desribed above is NOT possible without changing the Network on at least one side.

Reason: 1:1 NAT is necessary on both sides, but not available on Amazon side for hardware-VPN

As described here:
https://wiki.openwrt.org/doc/howto/vpn.ipsec.overlappingsubnets

Real Life Example

So what is it all about. Let us start with a picture and some explanations. What do we have?

ACME company with internal subnet 10.1.2.0/24 has an existing tunnel to another company with subnet 192.168.2.0/24. The firewall therefore will route all packets with destination 192.168.2.1-192.168.2.254 into the existing tunnel.
Our OpenWrt user at home has already a IPsec VPN connection too. The OpenWrt firewall protects his network 192.168.2.64/26 and routes all traffic to 10.1.0.0-10.1.3.254 towards the established tunnel to another company.
When establishing a new tunnel between home and ACME without address translation we would run into routing conflicts. E.g. if we want to reach the server 10.1.2.55 from home it could either be a machine in the ACME network or in the others company network.

What to do? Both firewall adminstrators have to choose IP address ranges for the new tunnel that do not overlap with the existing infrastructure. In our case:

The ACME administrator chooses to "hide" the remote home network behind the subnet 192.168.3.0/26. So when someone from ACME company wants to reach the newly conected home network he has to take on of those addresses instead of the real ones in range 192.168.2.64/26
The same applies for the home user. He does not want to reach the ACME network with its real IP addresses but changes the target range to 10.1.4.0/24.
That means each of both sides determines the remote part of the tunnel subnets.
Let us look at the packet flow and see where address translation has to occur. Let us assume we want to reach ACME mailserver on address 10.1.2.55 from our laptop with address 192.168.2.77.

We cannot use the mailservers real address but have to choose 10.1.4.55 instead. You can see that the lower part of the IP will match the original address while the higher is taken from the translated subnet.
The laptop sends a packet with header 192.168.2.77→10.1.4.55.
The OpenWrt firewall has to translate the source address into one that can safely pass the tunnel. Again it will only translate the higher digits. The header will become 192.168.3.11→10.1.4.55. If not sure why 2.77 is converted to 3.11 you just have to check the last bits of the home netmask …11000000. Only the last 6 bits will be retained.
The packet is sent into the tunnel.
When it reaches the ACME firewall it will be translated again. This time the destination address will be mapped over to the real addresses. The header will be changed to 192.168.3.11→10.1.2.55
The answer packet of the mailserver will travel this chain backwards.

And and Amazon:
https://aws.amazon.com/de/vpc/faqs/?nc1=h_ls

Q. How do I connect a VPC to my corporate datacenter?

Establishing a hardware VPN connection between your existing network and Amazon VPC allows you to interact with Amazon EC2 instances within a VPC as if they were within your existing network. AWS does not perform network address translation (NAT) on Amazon EC2 instances within a VPC accessed via a hardware VPN connection.