1

I am having trouble with a site to site tunnel. Both routers are centos based routers. Router A is the server, and router B is the client.

The VPN tunnel is established. From router B, I can ping anything on the network of router A. From router A (and the network behind it),

I cannot ping anything on the network behind router B, or behind router A.

So basically, router B is the only node that can ping anything on the opposite network.

Any idea where I should look? They are both running iptables. IP Forwarding is enabled.

I am guessing that router B can access anything on router A's network because it is using the tunnel interface, and not the interface of the local network.

There is no route on the server (router A) for my destination network. What should the default gateway of this be? The P-t-P address of router B?

Sorry if none of this makes sense!

Server config:

local 113.192.xx,xx
port 1194
proto tcp
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 10.104.17.0 255.255.255.0"
route 192.168.5.0 255.255.255.0
client-config-dir client-configs
keepalive 5 30
comp-lzo
persist-key
persist-tun
status 1194.log
verb 5
daemon

Client:

client
dev tun
proto tcp
remote 113.192.xx.xx 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/remote.crt
key /etc/openvpn/keys/remote.key
comp-lzo
verb 3

When the tunnel is up, the rounting table looks like this:

Client:

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.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
192.168.5.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
10.104.17.0     10.8.0.5        255.255.255.0   UG        0 0          0 tun0
0.0.0.0         192.168.5.2     0.0.0.0         UG        0 0          0 eth2

Server:

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
113.192.xx.xx   0.0.0.0         255.255.255.248 U         0 0          0 eth1
192.168.5.0     10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.104.17.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         113.192.40.41   0.0.0.0         UG        0 0          0 eth1

As you can probably guess, the network behind the VPN server is the 10.104.17.0/24 network, and the network behind the client is the 192.168.5.0/24 network

Lock
  • 1,637
  • 7
  • 26
  • 33
  • Since they are both running iptables have you tried clearing your rules to rule-out a firewalling issue? Can you post the network configuration and routing configuration for the two systems? – Zoredache Aug 11 '12 at 05:44
  • I've turned iptables off on both ends to rule that out. I'm sure the problem is at the server end. I'll update my original post – Lock Aug 11 '12 at 06:09

1 Answers1

0

What you're missing is that the OpenVPN server doesn't know which client has access to the 192.168.5.0/24 network. You need to tell it this with an iroute directive in the appropriate client config. Assuming that the CN of the client's certificate is "router-b.example.com", add this to /etc/openvpn/client-configs/router-b.example.com:

iroute 192.168.5.0 255.255.255.0
mgorven
  • 30,615
  • 7
  • 79
  • 122
  • Thankyou. I actually worked it out before reading your post, but that was kind of what the issue was. My config file was referencing the client-configs directory, but not as an absolute path. I changed this and it worked. I also had the wrong name for the CN of the certificate. I checked my persistent ipp file and got the CN from there – Lock Aug 12 '12 at 06:37