OpenVPN, NAT and overlapping subnets
-
Hi Jim,
On Site A I have the following 1:1 NAT entry
Interface - OpenVPN
External subnet IP - 192.168.20.0
Internal IP - 172.16.20.0/24and on Site B I have this under 1:1 NAT
Interface - OpenVPN
External subnet IP - 192.168.30.0
Internal IP - 172.16.30.0/24I have these routes pushed from the server at HQ to the clients:
push "route 192.168.20.0 255.255.255.0";
push "route 192.168.30.0 255.255.255.0";Should I also push routes for the real subnets i.e: ??
push "route 172.16.20.0 255.255.255.0";
push "route 172.16.30.0 255.255.255.0";Thank you
-
Pushing routes to the real subnets may not work in that case then…
You might have better luck building a direct tunnel from A to B and let them talk that way for those connections. The overlap would cause issues (and you couldn't do the same for B to C if they also had to route through HQ).
-
Unfortunately a direct tunnel from A to B is out the question - neither of them are publicly routable.
Is there any other way I can solve this?
Your advice is much appreciated.
-
You might be able to make a "direct" tunnel to the translated IP on the far side, and run the traffic over that, but I'm not sure if that would work.
If there really is no direct path from A-B other than through the HQ, I'm not sure you could push those routes without affecting C and D in the process.
-
Rather than push the routes from HQ, what if I specify them directly on the clients?
Just to be clear - I would create a new server at HQ on a new port for Site C and Site D. A+B would never need to see C+D and vice versa.
-
Yes but if HQ is one router, it's the routing table there you need to worry about.
-
Yes, it would be on the same physical hardware at HQ.
Is this a definite dead end then and shall I just give up? You are the man with the knowledge so if you tell me this is never gonna work then I trust you!
Cheers again.
-
I don't see how it would work in a meaningful way, but you're a lot closer to the topology of the network there. It wouldn't hurt to try or experiment a bit with it.
As I mentioned before you might be able to work around it by building a tunnel between A and B using the "alternate" IPs and route "directly" that way, but it seems hackish/ugly/etc. Though it may work… Sometimes a kludge is necessary. :-)
-
I'll have a play but agree, it's not a very tidy solution.
Might be a silly question but could we not NAT outbound at the client end:
So the pfSense at Site A receives a request for 172.16.30.1, it then translates that address to 192.168.30.1 and then routes it down the tunnel. HQ knows how to get to that subnet so it passes the request on to Site B…
-
You can, but that wouldn't let A talk directly to B's IPs I don't think.
-
I'm willing to give it a go if you can point me in the right direction :)
