Ubuntu – Can’t access LAN devices behind OpenVPN Server

local-area-networknetworkingopenvpnUbuntuvyos

I have OpenVPN running on Ubuntu Server 16.04 (10.122.224.2). On the same LAN as the OpenVPN server (10.122.224.0/24), I have a VoIP PBX (10.122.224.5).

Local to me, I have an IP Phone (192.168.10.110) and a Windows computer on the same subnet. I can get both the Windows PC and the IP Phone to successfully connect to the VPN and grab an IP in the 10.122.222.0/24 VPN subnet. The Windows PC and the IP Phone can ping each other over the 10.122.222.0/24 subnet, as well as ping the OpenVPN server at 10.122.224.2, but they cannot ping the PBX at 10.122.224.5. The OpenVPN server can ping all devices no problem.

I have enabled IPv4 forwarding on the OpenVPN server, I have the push route added in my OpenVPN Server config. I cannot seem to get access to the subnet behind the OpenVPN server through the clients connected to the VPN.

Here is a what my server config looks like

local PUBLIC_IP
port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cloudco.crt
key /etc/openvpn/keys/cloudco.key
dh /etc/openvpn/keys/dh2048.pem
server 10.122.222.0 255.255.255.0
push "route 10.122.224.0 255.255.255.0"
client-to-client
comp-lzo no
keepalive 10 120
persist-key
persist-tun
verb 3
tls-server
log-append /var/log/openvpn.log

And here is the client config

remote PUBLIC_IP
client
dev tun
resolv-retry infinite
ping 10
persist-key
persist-tun
float
comp-lzo no
proto udp
ca keys/ca.crt
cert keys/pctest.crt
key keys/pctest.key
ns-cert-type server
pull

I've searched around and found some solutions that worked for others, but does not seem to be working for me. Looking for some direction.

EDIT
I have switched to VyOS from Ubuntu. The VPN server is up, I am able to connect to the VPN, although I still cannot access the LAN devices behind the VPN. The VyOS box is the gateway for the LAN.

Traceroutes

10.122.224.5 to 10.122.222.2

traceroute to 10.122.222.2 (10.122.222.2), 30 hops max, 60 byte packets
 1  gw.sv2.orionvm.net (23.90.82.1)  0.955 ms  1.039 ms  0.884 ms
 2  192.168.50.1 (192.168.50.1)  1.071 ms  0.971 ms  0.956 ms
 3  206.16.209.233 (206.16.209.233)  1.205 ms  0.919 ms  1.185 ms
 4  mdf001c7613r0001-gig-10-3.wdc1.attens.net (63.240.192.137)  32.565 ms  32.557 ms  32.426 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

10.122.222.2 to 10.122.224.5

λ tracert 10.122.224.5

Tracing route to 10.122.224.5 over a maximum of 30 hops

  1    41 ms    41 ms    39 ms  10.122.222.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

10.122.222.2 to vyos public

λ tracert 23.90.82.138

Tracing route to 23-90-82-138.sv2.orionvm.net [23.90.82.138]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.10.1
  2     1 ms     8 ms    10 ms  agg15.lncsnycd01h.northeast.rr.com [24.58.27.213]
  3     9 ms     9 ms     9 ms  agg37.lkwnnyad02r.northeast.rr.com [24.58.38.24]
  4    16 ms    13 ms    15 ms  be29.albynyyf01r.northeast.rr.com [24.58.32.58]
  5    24 ms    26 ms    21 ms  bu-ether16.nycmny837aw-bcr00.tbone.rr.com [66.109.6.74]
  6    17 ms    17 ms    17 ms  unk-426d0577.adelphiacom.net [66.109.5.119]
  7    17 ms    19 ms    19 ms  nyk-b6-link.telia.net [62.115.156.214]
  8    17 ms    17 ms    18 ms  nyk-b5-link.telia.net [213.155.130.32]
  9    35 ms    36 ms    36 ms  192.205.34.53
 10    40 ms    39 ms    42 ms  cr2.n54ny.ip.att.net [12.122.130.110]
 11    40 ms    43 ms    39 ms  cr2.wswdc.ip.att.net [12.122.28.42]
 12   131 ms   134 ms    66 ms  gar3.ascva.ip.att.net [12.122.113.89]
 13    80 ms    39 ms    40 ms  12.122.251.206
 14    49 ms    48 ms    47 ms  mdf002c7613r0002-gig-12-1.wdc1.attens.net [63.240.192.142]
 15    39 ms    39 ms    40 ms  206-16-217-10.attens.net [206.16.217.10]
 16     *        *        *     Request timed out.
 17    37 ms    37 ms    38 ms  23-90-82-138.sv2.orionvm.net [23.90.82.138]

Trace complete.

Best Answer

Do the devices on the 10.122.224.0/24 network have a route or router that that would let them reach 10.122.222.0/24?

Your devices connected to VPN have routes to reach the other network, but devices on that network wouldn't magically have a route for return traffic unless the VPN server is also the gateway for that network. So you are going to need to adjust routes on that network. Or do something ugly on the VPN server with NAT.

P.S. You might want to strongly consider using topology subnet in your OpenVPN config. It will make the routes OpenVPN simpler compared to the default net30 topology.