Allow clients in network to communicate to client connected via OpenVPN

Question

Network topology is like this:

OpenVPN Server:

Private IP (eth0): 10.0.4.23/16
Public IP (eth1): 77.20.30.40/24
Routes:
default via 77.20.30.1
10.0.0.0/16 (not routable, so no gateway)
10.8.0.0/16 via 10.0.0.65

On same private subnet we have dedicated addresses in range of 10.0.13.0/24 network for clients connected via OpenVPN. So clients see the OpenVPN Server address as 10.0.13.1 as a gateway.

Client Machine:

Public IP: 217.40.50.60

Currently, when Client connects to VPN Server, it cannot see subnets in private range. So I've added routes to those networks using OpenVPN Servers tun0 IP (10.0.13.1)

ip r add 10.0.0.0/16 via 10.0.13.1
ip r add 10.8.0.0/16 via 10.0.13.1

It doesn't work. So I've added POSTROUTING iptables rule on OpenVPN Server

iptables -A POSTROUTING -s 10.0.13.0/24 -o eth0 -j MASQUERADE

At that point it worked. But, the problem is, when i connect to a server in that private subnet, for example 10.0.4.20, that server will see originating IP address as OpenVPN Private address 10.0.4.23.

Currently we have Microsoft VPN established and when we use that, all servers can see clients IP addresses that are assigned to by VPN, so it can be done (maybe) but I'm not sure where i got it wrong.

This is OpenVPN Server config file, comments stripped for readers convenience.

port 1194
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.0.13.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 10.0.0.1"
push "dhcp-option DNS 10.0.0.2"
push "route 10.0.0.0 255.255.0.0"
push "route 10.8.0.0 255.255.0.0"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_oy94rAaIiMtrnvAB.crt
key server_oy94rAaIiMtrnvAB.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
status /var/log/openvpn/status.log
log /var/log/openvpn/openvpn.log
verb 3

plugin /opt/openvpn-ldap-auth/lib/openvpn-auth-ldap.so /etc/openvpn/auth/ldap.conf
client-cert-not-required

I've tried setting server 10.0.13.0 255.255.255.0 to server 10.0.13.0 255.255.0.0 as that should be the network, but OpenVPN server doesn't like that config and don't want to start if first octet in subnet is not 0.

So to make it simple: How do i make some server that is on 10.0.0.0/16 network, reach VPN Client that is on 10.0.13.0/24. Or better yet, how do i make OpenVPN Server assign to clients IP addresses in range of 10.0.13.0/24 but actually make them belong to 10.0.0.0/16? Do i maybe need a separate DHCP Server on same server?

Answer 1

I've managed to get this resolved with the help of Ethernet Bridging.

These would be the steps:

• Stop the OpenVPN Server, on CentOS: systemctl stop openvpn@server
• Install bridge-utils package on CentOS 7 yum install bridge-utils
• Create tap0 Virtual ethernet device openvpn --mktun --dev tap0
• Create a bridge brctl addbr br0
• Add eth0 device (the one with private IP) to new bridge brctl addif br0 eth0
• Add tap0 device to bridge brctl addif br0 tap0
• Enable promiscuous mode to tap0 device ifconfig tap0 0.0.0.0 promisc up
• Enable promiscuous mode to eth0 device ifconfig eth0 0.0.0.0 promisc up
• Assign an IP address that was set to eth0 previously to br0 ifconfig br0 10.0.4.23 netmask 255.255.0.0 broadcast 10.0.255.255
• Add iptables rules so new interfaces can accept traffic

    iptables -A INPUT -i tap0 -j ACCEPT
    iptables -A INPUT -i br0 -j ACCEPT
    iptables -A FORWARD -i br0 -j ACCEPT

• Open up VPN Server config file, for example /etc/openvpn/server/server.conf, comment out the dev tun and add the dev tap0 right bellow or above it.
• Comment out the entire line that begins with the server and add IP address that was originally on eth0 and now on br0, also add the DHCP range of the addresses that the VPN will assign to clients, like this:

bridge 10.0.4.23 255.255.0.0 10.0.13.2 10.0.13.254

This will allow server to lease addresses from 10.0.13.2 - 10.0.13.254 to clients.

• Now start the openvpn server and enjoy :) systemctl start openvpn@servers.

Answer 2

From your description I see one missing configuration: you didn't tell your other servers how to reach the VPN clients.

Lacking that configuration, any host having an address of the 10.0/16 network will by default assume that any other address of that same network, thus including the 10.0.13/24 sub-network, is "on-link" i.e. reachable directly with no intervening router.

Just as an example test, try ip r add 10.0.13.0/24 via 10.0.4.23 to any one of your other Linux servers (not the OpenVPN server) belonging to the 10.0/16 network: after that, traffic should flow regularly between that particular Linux server and the OpenVPN clients.

Of course the same applies to all and any host on your 10.0/16 private network, be it Linux or Windows or Mac or Cisco or whatever. In practice, you should put that route on all your hosts of your private network.

Naturally this may be undesirable if you have many hosts. A better approach (networking-wise) would be to make your OpenVPN server host a sort of central gateway for your entire private network, perhaps literally the default gateway for all those hosts.

Presuming that is not feasible, if you already have such a "central gateway" in your private network (perhaps your 10.0.0.65 host ?), then you could try and configure just that one with the route above: the other hosts (the ones referring to that gateway) should normally obey and comply. However this solution can usually be sub-optimal because it makes those hosts be frequently re-routed by the "central gateway" towards the OpenVPN server gateway.

Other alternatives would involve to set special configurations up on your Linux server that is acting as OpenVPN server, in order to make it also act as a sort of "proxy-arp" for your OpenVPN client's addresses. Possible, but complex and advanced.

The bridging solution is certainly a solution, quick and easy, but implies that all broadcast traffic, which can be chatty in a medium-size LAN, is propagated to all your OpenVPN clients, thus occupying your OpenVPN server's resources and your Internet connection to and from your clients, each single broadcast frame multiplied by the number of clients connected.