OpenVPN, NAT and overlapping subnets
-
Hi Jim, thanks for your reply, sorry for not being very clear - I will try to explain a bit better:
The only problem I have is Site A and Site B can only ping each other using the masqueraded IP addresses.
So in my VM setup:
Site A is on 172.16.20.0/24 which is then NAT'ed to 192.168.20.0/24
Site B is on 172.16.30.0/24 which is then NAT'ed to 192.168.30.0/24HQ can successfully ping:
192.168.20.1 which translates back to Site A's LAN interface on 172.16.20.1
192.168.30.1 which translates back to Site B's LAN interface of 172.16.30.1Site A can ping Site B on 192.168.30.1
Site B can ping Site A on 192.168.20.1What I want is for Site A to be able to ping Site B's LAN interface on the original 172.16.30.1 address and not the NAT'ed 192.168.30.1 address.
Site B should also be able to ping Site A's LAN interface on the original address of 172.16.20.1Thank you.
-
What did your NAT rules look like?
You should be able to put exclusions on outbound NAT rules, at the top, such as " <do not="" nat="">from A to B". Since the rules are processed top-down, it should hit that and then just send the traffic without NAT.
Though 1:1 NAT may override that, on 2.0 you can set destination networks on the 1:1 NAT rules as well which should let you exclude the traffic from a-b from it.</do>
-
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 :)