OpenVPN, NAT and overlapping subnets
-
Hard to say what protocols will definitely have issues, not without knowing specifically what protocols you might be after.
A lot of things behave OK with NAT involved, especially 1:1 NAT, but others like FTP will break without a proxy/fixup/ALG/or client config.
-
Hi Jim,
I have set this up in VM and have it almost working to how I desire:
Site A and Site B clients are successfully VPN'd into HQ (server) using a new masqueraded IP range.
HQ can ping both Site A and Site B clients using the new masqueraded IP addresses.
Site A and Site B can ping each other using the masqueraded IP addresses.NAT works fine to this point.
However, the clients need to connect to each others machines using their original IP addresses. i.e. Site A needs to access Site B's Intranet server on its original IP. Do I need to publish a route for the real subnets to each client or should an additional NAT entry on the client pf boxes (translating back to the other sites masqueraded range) handle this? or do I need to do both?
Thank you.
-
I'm not sure what isn't working, can you give some examples (using your Site A, B, etc above) of what needs to happen that isn't working?
-
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 :)
