OpenVPN Support Forum

Hi all. I recently attempted to configure OpenVPN on Linux in a routed configuration and I could use a little help. Here's my situation:

LAN1: 192.168.60.0/24
LAN2: 192.168.2.0/24

Router1: 192.168.60.12 (eth0); 192.168.2.1 (eth1)

This is set up and routing properly, e.g. IP forwarding is enabled and each of the above subnets can reach the other via this host.

I then configured OpenVPN in a layer-3 setup to connect to a remote network, i.e.:

LAN3 (local & remote): 10.8.0.0/24
LAN4 (remote): 10.124.37.32/27
Router1: 192.168.60.12 (eth0); 192.168.2.1 (eth1); 10.8.0.6 (tun0)
Router2 (remote): 10.8.0.1 (tun0); 10.124.37.43 (eth0)


I can reach LAN4 hosts from Router1 so I know the VPN is working and the routing tables are configured properly. However, I can't reach hosts on LAN4 from LAN2. Default gateways are set properly since I can reach LAN1 hosts from LAN2, for example.

This may be a Linux routing question but I thought I'd start here since I was routing between LAN1 and LAN2 properly. Is there any kind of OpenVPN configuration which would prevent a VPN client from routing to a tunnel interface, e.g. tun0 in my case?

I'll see if I can generate a diagram to illustrate what I'm describing here. My Visio skills are limited so it might take a little while...


Thanks for any guidance you can provide.


Damon

UPDATE: Here's a link to an image I created in hopes of depicting this configuration visually:

http://d3a5avqutunhad.cloudfront.net/Op ... ration.png

hi there,

please post configs (server/client)...

Michael.

Hi.

Also would like to see the routing table on router1 and router2.

Oops! In my Visio frenzy I forgot to include config files. Here they are:

# grep -vE '^#|^;|^$' /etc/openvpn/server.conf
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log-append /etc/openvpn/openvpn.log
verb 3


# grep -vE '^#|^;|^$' /etc/openvpn/client.conf
client
dev tun
proto tcp-client
remote 208.39.104.114 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
ns-cert-type server
comp-lzo
verb 3
log-append /etc/openvpn/openvpn.log
status /etc/openvpn/openvpn-status.log


And here are routing tables from the two routers:

[Router 1]
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.124.37.32 0.0.0.0 255.255.255.224 U 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.60.1 0.0.0.0 UG 0 0 0 eth0


[Router 2]
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.124.37.32 0.0.0.0 255.255.255.224 U 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 10.124.37.33 0.0.0.0 UG 0 0 0 eth0


Thanks,

Damon

Ok, last post for today. I promise. Here's a quick 'tcpdump' that illustrates my problem:

[root@router1 ~]# tcpdump -i tun0 icmp
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
18:57:44.519322 IP 192.168.2.20 > 10.124.37.36: ICMP echo request, id 49973, seq 112, length 64
18:57:45.535046 IP 192.168.2.20 > 10.124.37.36: ICMP echo request, id 49973, seq 113, length 64
18:57:46.548789 IP 192.168.2.20 > 10.124.37.36: ICMP echo request, id 49973, seq 114, length 64

In other words, traffic from a LAN2 host--192.168.2.20--is reaching router1 and it's being delivered to the OpenVPN tunnel interface. As far as I can tell, Linux is doing the "right thing" here by sending packets destinated for a LAN4 host (10.124.37.36) to the right interface. However, things do look as good on router2:

[root@bofa-vpn1 ~]# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel


In other words, nothing is captured. No traffic shows up on the remote side of the tunnel, despite the fact that router1 can ping the same LAN4 host itself.


Thanks in advance for any guidance...


Damon

You have to add to your server's config the following: Then create a file ccd/client1 with this line: "client1" is the common name gived in the certificate for router2.

Also, for future expansion add to your server's config:

Thanks very much for your response, Mimiko. I added the config entries you referenced (altered a bit so I could remember what I was doing) but I still can't ping LAN4 from LAN2 hosts other than the router itself. Here is the updated server config file:

[root@router2 openvpn]# grep -vE '^#|^;|^$' server.conf
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log-append /etc/openvpn/openvpn.log
verb 3
client-config-dir /etc/openvpn/client-config-dir
route 10.124.37.32 255.255.255.224
push "route 10.124.37.32 255.255.255.224"


I added the client config file you suggested in the specified directory:

[root@router2 ~]# ls -l /etc/openvpn/client-config-dir
total 4
-rw-r--r-- 1 root root 36 Jul 22 10:41 client1

[root@router2 ~]# cat /etc/openvpn/client-config-dir/client1
iroute 10.124.37.32 255.255.255.224


I then stopped the client, restarted the server, and started the client. I see some routing updates being propogated, e.g.:

Fri Jul 22 10:41:32 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Jul 22 10:41:33 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,pi
ng-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Fri Jul 22 10:41:33 2011 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jul 22 10:41:33 2011 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jul 22 10:41:33 2011 OPTIONS IMPORT: route options modified
Fri Jul 22 10:41:33 2011 ROUTE default_gateway=192.168.60.1
Fri Jul 22 10:41:33 2011 TUN/TAP device tun0 opened
Fri Jul 22 10:41:33 2011 TUN/TAP TX queue length set to 100
Fri Jul 22 10:41:33 2011 /sbin/ip link set dev tun0 up mtu 1500
Fri Jul 22 10:41:33 2011 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Fri Jul 22 10:41:33 2011 /sbin/ip route add 10.8.0.0/24 via 10.8.0.5
Fri Jul 22 10:41:33 2011 Initialization Sequence Completed


However, the client configuration I added is oddly missing. It does show up in the server's log file, though:

Fri Jul 22 10:41:26 2011 TCP connection established with 131.239.15.22:2103
Fri Jul 22 10:41:26 2011 TCPv4_SERVER link local: [undef]
Fri Jul 22 10:41:26 2011 TCPv4_SERVER link remote: 131.239.15.22:2103
Fri Jul 22 10:41:27 2011 131.239.15.22:2103 TLS: Initial packet from 131.239.15.22:2103, sid=e15d3bbb 65530c48
Fri Jul 22 10:41:34 2011 131.239.15.22:2103 [client1] Peer Connection Initiated with 131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/client-config-dir/client1
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: Learn: 10.8.0.6 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: primary virtual IP for client1/131.239.15.22:2103: 10.8.0.6
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: internal route 10.124.37.32/27 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: Learn: 10.124.37.32/27 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 REMOVE PUSH ROUTE: 'route 10.124.37.32 255.255.255.224'
Fri Jul 22 10:41:36 2011 client1/131.239.15.22:2103 PUSH: Received control message: 'PUSH_REQUEST'
Fri Jul 22 10:41:36 2011 client1/131.239.15.22:2103 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)


After establishing the connection, I can no longer ping LAN4 hosts from router1. I still can't ping LAN4 hosts from LAN2 but that's the problem I had initially.

Is the server removing the route we specified?

Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 REMOVE PUSH ROUTE: 'route 10.124.37.32 255.255.255.224'

I'm not sure why that's happening.

Thanks for your suggestions thus far!


Damon

Sorry for dont mention. Add to server config: That will make router2 aware of LAN's behind router1.

Then, print routing table on both router1 and router2. And make a trace from a computer in LAN2 to a computer in LAN4, and vice-versa.

Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: Learn: 10.8.0.6 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: primary virtual IP for client1/131.239.15.22:2103: 10.8.0.6
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: internal route 10.124.37.32/27 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 MULTI: Learn: 10.124.37.32/27 -> client1/131.239.15.22:2103
Fri Jul 22 10:41:34 2011 client1/131.239.15.22:2103 REMOVE PUSH ROUTE: 'route 10.124.37.32 255.255.255.224'
Fri Jul 22 10:41:36 2011 client1/131.239.15.22:2103 PUSH: Received control message: 'PUSH_REQUEST'
Fri Jul 22 10:41:36 2011 client1/131.239.15.22:2103 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

This log shows, that server got your client from public ip 131.239.15.22, then assigned IP 10.8.0.6 to tun adapter of the client, then added to local routing table of router1 the route 10.124.37.32/27 to this client.
Remove indicates that this client already have LAN 10.124.37.32/27 on its side, so no pushing this route to client is needed. Pushin route 10.124.37.32/27 will be needed to other clients in order to find this router2 client's LAN.
And finally, server pushes routes for 10.8.0.0 to client so client will know that all trafic to this network must be routed to server. Here will appear and pushing routes to client for LAN1 and LAN2.

You almost done it.