0

I've got an openVPN client connected to an openVPN server with a particular set of routing tables. That openVPN server is also a client connected to another openVPN server with a different set of routing tables. I am having trouble getting my client to route a particular subnet to the second openVPN server.

Here's a quick (and hopefully helpful) illustration of my setup with said routing tables:

draw.io diagram

Client's openvpn client config:

    client
    dev tun0
    proto udp
    remote some-domain.com 1195
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    comp-lzo
    verb 3
    key keys/vpn192-168-128-0.key
    cert keys/vpn192-168-128-0.crt
    ca keys/ca.crt
    log /var/log/openvpn.log
    verb 4        

    route 10.100.0.0 255.255.255.0
    route 10.55.128.0 255.255.255.0

Server 1's openvpn server config:

    mode server
    tls-server
    port 1195
    proto udp
    dev tun1
    ca server/keys/ca.crt
    cert server/keys/server.crt
    key server/keys/server.key
    dh server/keys/dh1024.pem
    server 10.100.1.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    topology p2p        

    # route these networks
    route 192.168.128.0 255.255.240.0
    route 10.55.128.0 255.255.255.0      

    client-to-client        

    # client specific configs in here
    client-config-dir ccd
    keepalive 10 120
    comp-lzo
    persist-key
    persist-tun
    status openvpn-status-vpn100.log
    log /var/log/openvpn-server.log
    verb 4

Server 1's client config to Server 2:

    client
    dev tun0
    proto udp
    remote some-domain2.com 1194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    comp-lzo
    verb 3
    key /etc/openvpn/client/vpc10-100-0-0.key
    cert /etc/openvpn/client/vpc10-100-0-0.crt
    ca /etc/openvpn/client/ca.crt
    log /var/log/openvpn-client.log
    verb 4
    route 10.55.128.0 255.255.255.128

Server 2's openvpn server config:

    mode server
    tls-server
    port 1194
    proto udp
    dev tun1
    ca keys-vpc/ca.crt
    cert keys-vpc/server.crt
    key keys-vpc/server.key
    dh keys-vpc/dh1024.pem
    server 10.41.88.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    topology p2p        

    # push 10.45.0.0 route to all connecting clients.
    push "route 10.45.0.0 255.255.128.0"
    push "route 10.39.88.0 255.255.255.0"
    route 10.44.0.0 255.255.128.0 #core-west
    route 10.55.128.0 255.255.128.0 #us-east-1 galaxy
    route 10.100.0.0 255.255.255.0 #gcp-us-east-1
    route 192.168.128.0 255.255.240.0 #gcp-zing-preview        

    client-to-client        

    # client specific configs in here
    client-config-dir ccd-vpc
    keepalive 10 120
    comp-lzo
    persist-key
    persist-tun
    status openvpn-status-vpc.log
    log  /var/log/openvpn-vpc.log
    verb 4
    duplicate-cn

Client's route table:

    default via 192.168.128.1 dev ens4 proto dhcp metric 100
    10.55.128.0/24 via 10.100.1.1 dev tun0
    10.100.0.0/24 via 10.100.1.1 dev tun0
    10.100.1.1 dev tun0 proto kernel scope link src 10.100.1.4
    192.168.128.1 dev ens4 proto dhcp scope link metric 100

Server 1's route table:

    default via 10.100.0.1 dev ens4 proto dhcp metric 100
    10.39.88.0/24 via 10.41.88.1 dev tun0
    10.41.88.0/24 via 10.41.88.1 dev tun0
    10.41.88.1 dev tun0 proto kernel scope link src 10.41.88.6
    10.55.128.0/24 via 10.41.88.1 dev tun0
    10.100.0.1 dev ens4 proto dhcp scope link metric 100
    10.100.1.0/24 via 10.100.1.2 dev tun1
    10.100.1.2 dev tun1 proto kernel scope link src 10.100.1.1
    192.168.128.0/20 via 10.100.1.2 dev tun1

Server 2's route table:

    default via 10.45.0.1 dev eth0
    10.39.88.0/24 dev tun0  proto kernel  scope link  src 10.39.88.1
    10.41.88.0/24 via 10.41.88.2 dev tun1
    10.41.88.2 dev tun1  proto kernel  scope link  src 10.41.88.1
    10.45.0.0/27 dev eth0  proto kernel  scope link  src 10.45.0.10
    10.55.128.0/17 via 10.41.88.2 dev tun1
    10.100.0.0/24 via 10.41.88.2 dev tun1
    192.168.128.0/20 via 10.41.88.2 dev tun1

Iptables are clean on all three boxes as of right now.

I am trying to ping 10.55.128.18 from the client and have it route all the way to Server 2. It makes its way to Server 1 and won't route to Server 2. I can ping 10.55.128.18 directly on Server 1 (not from the client).

I've got IP forwarding enabled everywhere and firewall rules are open for ICMP between all three devices.

Anything insight you can provide would be very helpful!

Thanks.

  • Does 10.55.128.18 have a route that would permit it to reply to the 10.100.0.0/24 network? What does the route table look like on 10.55.128.18? – Zoredache May 25 '18 at 20:10
  • BTW, you know on Linux you can use actual names for your tunnels? So you could use something like dev tun_foo or ` dev tun_bar`? I like using tunnel devices with useful names, because it makes your routing tables and config far easier to read, since you don't have to remember what tunN is on a give system. – Zoredache May 25 '18 at 20:14
  • Yep - it does. I've ran a tcpdump on server 1 and server 2. I can see the ICMP requests come in from the client on server 1, but I don't see the request make it to server 2. If the request originates from server 1, it will route appropriately. The problem is when the request originates from the client. – jmct May 25 '18 at 20:54
  • Well, but the client is going to have a completely different source IP and subnet then what server1 has. When you are doing that tcpdump, are you seeing any destination unreachable messages or other icmp errors? Can you poing server1 from the client? Can you ping server 2 from the client? Is it only that that 10.55.128.18 address that is failing? – Zoredache May 25 '18 at 21:04
  • I'm not seeing any destination unreachable messages unfortunately (wish I was - then I'd have something to work with!) I'm filtering for ICMP requests against all interfaces on server 2 (not much would be pinging) and I don't see anything coming through. I can ping server 1 from the client, yep. I can't ping the client from server 2. The problem is affecting the entire 10.55.128.0 subnet (the IP I was referencing is just my test). – jmct May 25 '18 at 21:15
0

I've got this resolved. There were additional routes that needed to be added (VPN routes that did not exist), as well a mis-configured iroute in the ccd directory for that connection.

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.