Should a VPN have access to all networks from and on all clients?

Question

I have an OpenVPN server and many clients connecting. The VPN settings include

port 443
dev tun
proto tcp

When I add clients to my VPN I have to use apaches proxypass in order to access resources which are local to an individual client, but not to the VPN neetwork.

For example:

-Server is on 10.8.0.1

-Client is on 10.8.0.4

-Another client is on 10.8.0.7

Client 10.8.0.4 is on a work network aswell which can connect to internal url 10.82.54.11/internal_url (as one of its network adapters is on subnet 10.82.54.0) .

This client has an apache proxypass setup so when they are at home they can connect to 10.82.54.11/internal_url by opening 10.8.0.4:84.

I have recently been told that ALL clients on a VPN should have access to ALL networks, is this correct (or even possible as would be very useful to me)?

So essentially as long as the client 10.8.0.4 is connected to the VPN, from home he can still point a browser to 10.82.54.11/internal_url .

I have tried dev tap0 for server and all clients (think i may need ethernet bridging on all too) but no joy. Please help

Answer 1

OpenVPN provides a link. If running in tun (recommended) mode, it provides a link for IP traffic. If running in tap mode, it provides a link for Ethernet traffic (which includes IP, but also all kinds of other things).

If you run in tap mode, you need to bridge your OpenVPN tap interface to your Ethernet interface. You can do that with brctl, but, generally, I wouldn't recommend this, unless you need non-IP protocols to work. Its slower (more overhead), and can have serious issues, depending on latency. [OK, you could treat it as a separate network segment and use IP routing, but then you should switch to tun mode.]

When you run in tun mode (which it sounds like you are, and should be), you need to get your IP routing correct. In this case, I'm guessing your client doesn't know that traffic to 10.82.54.11 needs to be routed over the VPN. You need to let the client know this. You could manually set up a static route on the client, or run a routing protocol, or use a built-in feature OpenVPN provides by adding this line to your OpenVPN server config:

push "route 10.82.54.0 255.255.255.0"

push sends an option to the remote side. So the client will add the option route 10.82.54.0 255.255.255.0 which means to add a static route to route 10.82.54.0/24 through the VPN.

The next thing you need to do is to make sure the routing the other way around is correct, too. Your server 10.82.54.11 (or, more likely, the router or firewall that functions as its default gateway) needs to know that the route to 10.8.0.0/24 is through the VPN gateway. It could be you only have one router/firewall, so the server is behind the firewall that's the VPN server as well, in which case you may just need to add something like this to your OpenVPN config (if you don't already have it):

route 10.8.0.0 255.255.255.0

Which should look familiar, and does the same thing—just on the server end, not the client, due to the lack of push.

(Adjust all netmasks as appropriate for your network. I assumed /24, but of course you may be using anything.)

[Note: I'm assuming you're using OpenVPNs multi-client mode, not its point-to-point mode. If you're using point-to-point, then the IP addresses in the route commands may be different.]