1

I only have basic experience with VPNs (mostly OpenVPN) and mostly theoric, but now I want to set up something more complex and I am evaluating the possible issues that I may face. I will try to represent the hypothetic situation via examples. Let's assume OpenVPN for this setup.

I have one main server that will run the OpenVPN client and different remote locations that will have different OpenVPN servers. I will open different tunnels at the same time from the main server to these remote locations. Let's say I will have ten different tunnels open at the same time.

Each of the tunnels will have a local IP assigned for the client, for example:

10.0.0.2/24 (tunnel A)

10.0.1.2/24 (tunnel B)

10.0.2.2/24 (tunnel C)

...

So, for instance, OpenVPN server in tunnel A would be 10.0.0.1/24. If I want to access some resource inside tunnel A's LAN - for instance, an Apache running on 172.16.0.50, I would just input the IP in my VPN client's computer and I would hit the web server (assuming all the routes are ok).

My main concerns lays in having different tunnels at the same time and multiple services running under the same local IP. Taking the above example:

Tunnel A: server 10.0.0.1/24, client 10.0.0.2/24, Apache 172.16.0.50

Tunnel B: server 10.0.1.1/24, client 10.0.1.2/24, Apache 172.16.0.50

In this particular example, we have two Apache instances running in different networks but sharing the same local IP, therefore when client inputs 172.16.0.50 while the two tunnels are active, I guess it will fail.

I am not sure if my guess is right but I bet this is not so atypical situation. Can someone explain what would need to be done in this situation?

EDIT: My apologies if I was not clear enough - let me simplify the issue breaking it down in simple steps:

  • Two VPN servers (VPN1 & VPN2) and one VPN client
  • VPN1 and VPN2 share the same LAN IPs for their internal services: 172.16.0.0/24
  • Both VPN1 and VPN2 have an Apache running under 172.16.0.50
  • VPN client connects to both VPN servers (VPN1 & VPN2)
  • Issue -> Both have the same LAN numeration (172.16.0.0/24) and also Apache is running under the exact same IP
  • Question -> Is there a way to sort this out besides changing the LAN (and therefore Apache's IP) in one of the VPN servers?
  • A less hypothetical question with an actual problem would be much better. – Deer Hunter Aug 26 '14 at 9:33
  • @DeerHunter the example above could very well be a real situation and an actual problem. Please let me know if there is something specific in my question that is not clear. – Palomies Aug 26 '14 at 9:51
  • "Some resource inside tunnel A's LAN - for instance, an Apache running on 172.16.0.50". What do you mean by "tunnel A's LAN"? What exactly is tunnel A and its subnet? "tunnel A's LAN" usually means the 10.0.0.0/24 subnet, and 172.16.0.50 is in another subnet. – Tero Kilkanen Aug 26 '14 at 10:29
  • @TeroKilkanen 10.0.0.0/24 would be the subnet used for the tunnel between the VPN client and server (i.e. 10.0.0.1 would be the server and 10.0.0.2 would be assigned to the client). Apache's instance, running under 172.16.0.50 would be in a different subnet indeed, but reachable from VPN's server since it would be its LAN. Am I missing something here? – Palomies Aug 26 '14 at 10:40
  • 1
    Yes, you're missing a whole bunch of configuration information. You have told us nothing about the networks that are routed through the tunnels, which is much more relevant to this question than the details of the networks in operation in the tunnels. A network disgram might be helpful! – MadHatter Aug 26 '14 at 10:48
1

No, there is no convincing and trouble-free way of doing this.

At layer 3, once both tunnels are up, the client has absolutely no way of distinguishing 172.16.0.50-via-tunnel-1 from 172.16.0.50-via-tunnel-2; IP just doesn't support that kind of decision-making (modulo source routing, which will be very painful and be badly-supported).

There are some filthy hacks you could use: you could have NAT on the client overlay two different RFC1918 ranges on top of the two similar networks, and use policy-based routing to make traffic

But then you'll have to rewrite everything that makes reference to addresses from the overlapping range based on which tunnel it comes through.

Honestly, it will be less painful to re-IP one of the two destination networks. That will have the handy fringe benefit of your being able to link the two networks directly - and if it's business-desirable for a single client to contact both networks, it's only a matter of time before it's business-desirable to directly-interconnect them.

Edit: under the current setup, the same problem affects that situation: for any given address in the overlapping range, the client has no way of knowing which tunnel it should be routed down. You could address this by only giving routes to 172.16.0.50 via tunnel 1, and 172.16.0.51 via tunnel 2. However, this won't scale very well, unless all the interesting hosts in one LAN are in 172.16.0.0/25, and all those in the other are in 172.16.0.128/25. In that case re-IPing shouldn't be more painful that changing the netmask everywhere.

  • Thank you for your answer. What would happen if we still have the same tunnels and LANs but Apache runs in 172.16.0.50 at VPN1 and in 172.16.0.51 at VPN2? – Palomies Aug 27 '14 at 6:36
0

If it is OK that the traffic is routed through VPN1 by default and VPN2 as backup, splitting the pushed route in 2 /25 ranges on VPN1 and pushing the full /24 on VPN2, would result fix this.

In case VPN1 is down and the 2 /25 routes are removed, it still has the /24 of VPN2, so you would gain high availability, albeit without load balancing.

So, on VPN1 you could do:

push "route 172.16.0.0 255.255.255.128"
push "route 172.16.0.128 255.255.255.128"

while on VPN2 you would do:

push "route 172.16.0.0 255.255.255.0"

As the most "narrow" route has precedence, the client would prefer VPN1 over VPN2.

Also you could instead specify a different client-side route-metric in the client configurations, so for instance in the client config for VPN1:

route-metric 200

and in that of VPN2:

route-metric 201

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.