Connecting OpenVPN Sites with Conflicting IP Subnets

[pwood999]

Hi Guys,
I have been reading through the docs on using 1:1 NAT with OpenVPN, because I need to use the same subnet on both sides.

My scenario has Static IP the CPE at one end, and the Northbound gateway at the other. Both subnets are /29 so I have limited IP range. I plan to use 1:1 NAT according to the guide as this is similar to my scenario.

My question is I'm not sure what IP to use on the PfSense LAN interfaces at each end ?

I have a client at Site-B using XX.YY.192.116 /29 and Northbound Gateway at Site-A on XX.YY.192.113 /29

IP's 192.114 & 192.115 are already in use at Site-A, os only 192.117 & 192.118 are available in that subnet. Will these work as the PfSense LAN interfaces & then 1:1 NAT to a pair of 172.16.0.0 and 172.17.0.0 at each end ?

[viragomann]

@pwood999
For sure you can configure NAT 1:1 to circumvent the overlapping.

However, not clear, what you want to do with 192.117 & 192.118 here.
Also your graphic shows completely different IP as you mentioned.

[pwood999]

@viragomann Yes, I attached the wrong diagram !! This time with the correct IP Scopes.

I'm hoping to use /29 for the 1:1 NAT at each end. Just not sure about the two LAN IP's ??

[viragomann]

@pwood999 said in Connecting OpenVPN Sites with Conflicting IP Subnets:

Just not sure about the two LAN IP's ??

Which ones?

For the site-to-site VPN with natting, you need to assign an interface to the OpenVPN instance on both site, if you didn't this already. I'll call them S2SVPN here.

Instead of 172.16.1.0/29 and 172.17.1.0/29 I'd rather use 172.16.1.112/29 at A and 172.17.1.112/29 at B, so you would have the same octet at the end.

A:
Add a NAT 1:1 rule:
interface: S2SVPN
External subnet IP: Single host > 172.16.1.112
Internal IP: LAN net or 10.3.192.112/29
Destination: any

In the OpenVPN settings:
IPv4 Remote Networks: 172.17.1.112/29

B:
Add a NAT 1:1 rule:
interface: S2SVPN
External subnet IP: Single host >172.17.1.112
Internal IP: LAN net or 10.3.192.112/29
Destination: any

In the OpenVPN settings:
IPv4 Remote Networks: 172.16.1.112/29

Now, to access 10.3.192.116 at B from A, you have to enter 172.17.1.116.
To access 10.3.192.116 at A from N, you have to enter 172.16.1.116.

It should also be possible to use the same replacement-subnet at both sites if you want, as long as you don't assign an IP out of it to a device.

[pwood999]

@viragomann OK, it's starting to become clearer. I have updated the diagram with more detail.

Note, the Client Device is pre-configured by the supplier with Def GW = 10.3.192.113. We cannot change this. The destination is actually via the Juniper VRF to another network across their corporate core.

This is all working already with the Client connected locally to the Juniper VRF. What we are trying to do is locate the Client at a temporary remote site !!

[viragomann]

@pwood999 said in Connecting OpenVPN Sites with Conflicting IP Subnets:

Note, the Client Device is pre-configured by the supplier with Def GW = 10.3.192.113

So you have to provide this gateway at B.

Which access is needed? From where to where?

[pwood999]

@viragomann The client device normally connects via 10.3.192.113 & is routed from there to an IP-Sec gateway at 10.55.108.x and all the client traffic is inside the IPsec tunnel.

[viragomann]

@pwood999
I guess, this goes across the Juniper?

So incoming traffic from the IPSec might go to 10.3.192.116 rather than to 172.17.1.116?
If this is the case, you'd had to release 10.3.192.116 at A and assign it to pfSense LAN as virtual IP. Then forward it to 172.17.1.116.

[pwood999]

@viragomann
I had another idea how to implement the VPN we need.

• Add another virtual interface & IP scope to the Juniper VRF. This connects to the Site-A LAN & accessible via the VPN Server.
  Site-B becomes a VPN Client with the original 10.3.192.113 Gateway on it's LAN interface.
  This way the Client CPE connects using its configured gateway and then via the VPN to the new virtual interface on the Juniper.
  Consequently we no longer have conflicting interfaces.

I suspect I will need some static routes on the Juniper because 10.3.192.114 and 10.3.192.115 are locally connected. Hopefully a static route towards 10.3.192.116 will force that traffic via the new virtual interface.

The PfSense HW should arrive next week, so will update once I have tried it !!

Thanks,
Pete

[pwood999]

Just to close this off, I got it working as desired using a simple Peer-Peer OpenVPN, and then added a bridge from VPN to OPT1 at both ends. Client CPE & Juniper VRF can reach each other with perfectly.

The only remaining challenge was the size of IPSEC packets from the client. Control packets were small, but Data often exceeded the payload maximum inside the OpenVPN tunnel. Eventually I used tun-mtu & fragment options to split packets >>1400 bytes across two OpenVPN UDP packets.

LAN interfaces are completely separate and only used for local access to the PfSense GUI.