OpenVPN, NAT and overlapping subnets
-
Hi all,
We have multiple client sites connecting into our HQ all with conflicting subnets.
At the moment, we use a 'paid for' firewall that allows us to do 1:1 NAT over IPSec to get around this. This allows us to present them as unique subnets to our main firewall at HQ.
I have been looking into the possibility of using OpenVPN. Could it cater for the following hub and spoke scenario:
HQ trusted network 10.11.12.0/24
Site A - 192.168.1.0/24
Site B - 192.168.2.0/24
Site C - 192.168.1.0/24 (conflicts with A)
Site D - 192.168.2.0/24 (conflicts with B)Site A needs to be able to route to Site B via HQ and vice versa.
Site C needs to be able to route to Site D via HQ and vice versa.Site A cannot access any other network apart from Site B
Site C cannot access any other network apart from Site DHQ must have access to all subnets.
Is this possible at all?
Thank you :)
-
That should work fine. You can do 1:1 NAT in both directions, so that each side will appear to be on a non-conflicting subnet. You can NAT any of the usual ways with OpenVPN. At most you may have to assign the OpenVPN instances as OPT interfaces but in some cases that may not be needed.
-
Thanks Jim, i've been reading the pfSense book on this very chapter (this is an excellent book by the way). I would only need to NAT at the remote client end and not at HQ since this is on a unique subnet.
I did notice a caveat regarding problems with NAT and some protocols. Would I still experience problems with CIFS if i'm NAT'ing in one direction only as outlined in my scenario? What other protocols might I have problems with?
Thanks again :)
-
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 :)
