0

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.
  • When the VPN server is not the gateway, you also need to add a route on the gateway to route the VPN addresses to your VPN server. – mivk Feb 27 at 9:10
1

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.

  • Thanks for the reply. After reading your comment, it seemed to make more sense to run this on a VyOS box as the gateway, since I already have one as my gateway running an IPSEC site-to-site VPN. This box is the gateway for the LAN, I am able to connect to the VPN, yet I still cannot access the LAN devices. Any ideas? – Steve Stoveld Jul 26 '17 at 18:06
  • You probably need to perform traceroutes between the various systems and include route tables. So what what is the output of attempting to trace from a 10.122.224.0 system to 10.122.222.0 one. What happens in the reverse. Do packets follow the path they should. Do you get destination unreachable results, from what address. A traceroute really should give you all the answers. – Zoredache Jul 26 '17 at 18:25
  • I ran 3 traceroutes. i.imgur.com/cTqS7dq.png and i.imgur.com/o3Rd9cU.png - The first one in the first screenshot is from my Desktop on the VPN (10.122.222.2) to a server behind the VyOS (10.122.224.5). The second is from my desktop (10.122.222.2) to the VyOS public ip. In the second screenshot, I ran a traceroute from the server behind the VyOS (10.122.224.5) to my desktop on the VPN (10.122.222.2). Looks like going from my 10.122.222.2 to 10.122.224.5, it hits 10.122.222.1 and then nothing. From 10.122.224.5 to 10.122.222.2, it dies out somewhere outside both networks – Steve Stoveld Jul 26 '17 at 19:54

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.