Home / server / Questions / 348543
In Process
Majid Azimi
Asked: 2012-01-11 08:21:37 +0800 CST

Routing issue In OpenVPN

  • 772

Below is my openVPN network topology. This is an example in openvpn cookbook. Topology here is my server config file(fedora is server):

proto udp
port 1194
dev tun
server 192.168.200.0 255.255.255.0

ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/openvpnserver.crt
key /etc/openvpn/cookbook/openvpnserver.key
dh /etc/openvpn/cookbook/dh2048.pem
tls-auth /etc/openvpn/cookbook/ta.key 0

keepalive 10 60

push "route 192.168.4.0 255.255.255.0"
topology subnet

daemon
log-append /home/mazimi/Desktop/openvpn.log

client-config-dir /etc/openvpn/cookbook/clients
route 192.168.2.0 255.255.255.0 192.168.200.1

Here is /etc/openvpn/cookbook/clients file:

iroute 192.168.2.0 255.255.255.0

This is my openvpn client(ubuntu):

client
proto udp
remote 192.168.3.1
port 1194
dev tun

ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.key 1

daemon
log-append /root/openvpn.log

ns-cert-type server

This configuration is working fine. But why the next hop is set to 192.168.200.1?(it is a local interface not next-hop). Shouldn't it be 192.168.200.2? I changed it to 192.168.200.2. The only difference is that:

  1. I can not ping ubuntu's interface(192.168.3.254) from client1
  2. I can not ping fedora's interface(192.168.3.1) from client2 All other IPs are reachable.

Could someone explain?

routing openvpn

3 Answers

  1. I believe the 192.168.200.* IPs are artifacts of how OpenVPN tunnels actually work. OpenVPN in this configuration is essentially point-to-point, and each point gets its own IP address. When you route through the tunnel, you have to specify the near end of the tunnel. Think of these IPs as being internal to the way OpenVPN works (for my own clarification, I assign an entirely different non-routable block, e.g., 10.0.0.0/8, if my network is 192.168.0.0/16; the 10.0.0.0/8 IPs only exist for OpenVPN as far as I'm concerned).

    In contrast, with at TAP interface, you'd actually get the IP of the LAN you're bridging to assigned to OpenVPN.

    I'm sure it's somewhere in the FAQ, but I don't see it at a quick glance.

    • 1

  2. I believe you need to use the client-to-client directive, and you are missing routing pushes for 192.168.3.0 and 192.168.4.0

    • 0

  3. This is actually a trimmed down version of my own OpenVPN implementation as I have in place. You don't actually state it in your details but you would likely need the following included in your /etc/sysctl.conf or under /etc/sysctl.d on both your Fedora 16 server and your Ubuntu 11.10 client in order to route traffic through them as a gateway.

    net.ipv4.ip_forward = 1

    After you've run sysctl -a after the line was entered you should then be ready to work on your OpenVPN config. I would suggest trying the following for your server config:

    proto udp
port 1194
dev tun

ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/openvpnserver.crt
key /etc/openvpn/cookbook/openvpnserver.key
dh /etc/openvpn/cookbook/dh2048.pem
tls-auth /etc/openvpn/cookbook/ta.key 0

server 192.168.200.0 255.255.255.0
topology subnet

client-config-dir /etc/openvpn/cookbook

client-to-client
route 192.168.2.0 255.255.255.0 192.168.200.2
route 192.168.4.0 255.255.255.0 192.168.200.1

keepalive 10 60

push "route 192.168.4.0 255.255.255.0"
topology subnet

daemon
log-append /home/mazimi/Desktop/openvpn.log

    Next, assuming your Ubuntu client certificate CN is client one add the following into /etc/openvpn/cookbook/client1:

    ifconfig-push 192.168.200.2 255.255.255.0
iroute 192.168.2.0 255.255.255.0

    Then finally, for your Ubuntu client config file:

    client
proto udp
remote 192.168.3.1 1194
dev tun

persist-key
persist-tun

ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/client1.crt
key /etc/openvpn/cookbook/client1.key
tls-auth /etc/openvpn/cookbook/ta.key 1

daemon
log-append /root/openvpn.log

ns-cert-type server

    As I said, this is a trimmed down version of what I use. My configs have a few more options than yours but the defaults for them should be sufficient. For me my client1 has 2 subnets behind it (192.168.1.0/24 & 172.16.20.0/24). My corp OpenVPN server runs on 10.20.30.0/24 and my client OpenVPN server runs on 10.8.0.0/24 with clients connecting to it. corp ovpn server is assigned 10.20.30.1 and the client ovpn server receives 10.20.30.2 and client1 receives 10.20.30.3 when they connect to corp ovpn server.

    So my corp server config includes the following:

    route 172.16.20.0 255.255.255.0 10.20.30.3
route 192.168.1.0 255.255.255.0 10.20.30.3
route 10.8.0.0 255.255.255.0 10.20.30.2

    While the CCD file for client1 contains the following:

    ifconfig-push 10.20.30.3 255.255.255.0
iroute 172.16.20.0 255.255.255.0
iroute 192.168.1.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

    And the CCD file for client ovpn server contains the following:

    ifconfig-push 10.20.30.2 255.255.255.0
iroute 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "route 172.16.20.0 255.255.255.0"
push "route 10.20.30.0 255.255.255.0"

    That said... From my laptop on my wifi which receives the IP 192.168.1.140 if I traceroute to my client connected to client ovpn server as 10.8.0.30 I get the following:

    traceroute to 10.8.0.30 (10.8.0.30), 30 hops max, 60 byte packets
 1  192.168.1.1  2.108 ms  2.078 ms  2.460 ms
 2  192.168.1.2  3.370 ms  3.340 ms  3.671 ms
 3  10.20.30.2  20.250 ms  20.220 ms  20.518 ms
 4  10.8.0.30  33.505 ms  34.326 ms  34.809 ms

    You can disregard the first hop (192.168.1.1) as that is the AP/router that has static routes configured for 10.0.0.0/8 and 172.16.0.0/12 routed to 192.168.1.2 client1's IP address. Just for the sake of being complete, here is the return route from that client (10.8.0.30).

     traceroute to 192.168.1.140 (192.168.1.140), 64 hops max, 52 byte packets
 1  10.8.0.1  8 ms  8 ms  8 ms
 2  10.20.30.3  21 ms  22 ms  24 ms
 3  192.168.1.140  24 ms  24 ms  23 ms
    • 0