2

Setup description:

  • One VPN server called vpn1
  • One VPN client called vpn2
  • One network behind vpn1 with IP addresses 10.0.0.0/24
  • One network behind vpn2 with IP addresses 10.0.2.0/24
  • For simplicity right now the VPN boxes are the default gateway for machines in their LANs

Server configuration: vpn1

mode server
tls-server
dev tun

local PUBLIC-IP-HERE
port 1194
proto udp

persist-key
persist-tun

# Certificates and encryption
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0

cipher BF-CBC        
comp-lzo            

push "route 10.0.0.0 255.255.255.0"
push "route 10.0.2.0 255.255.255.0"
push "route 10.255.254.0 255.255.255.0"
route 10.0.2.0 255.255.255.0
client-to-client
max-clients 30

user nobody
group nogroup
keepalive 10 120
status /var/log/openvpn-status.log
verb 3

ifconfig-pool-persist ipp.txt
client-config-dir ccd
server 10.255.254.0 255.255.255.0

push "explicit-exit-notify 3"

In ccd/client I have:

iroute 10.0.2.0 255.255.255.0
ifconfig-push 10.255.254.9 10.255.254.10

How "ip a" looks like:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1

172: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.255.254.1 peer 10.255.254.2/32 scope global tun0

How "ip r" looks like (I removed default route since it should not be important):

10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.1
10.0.2.0/24 via 10.255.254.2 dev tun0 
10.255.254.0/24 via 10.255.254.2 dev tun0 
10.255.254.2 dev tun0  proto kernel  scope link  src 10.255.254.1 

Client configuration: vpn2

client
dev tun
remote PUBLIC-IP-HERE 1194
nobind
persist-key
persist-tun
proto udp

ca /etc/openvpn/easy-rsa/keys/client/ca.crt
cert /etc/openvpn/easy-rsa/keys/client/client.crt
key /etc/openvpn/easy-rsa/keys/client/client.key

tls-auth /etc/openvpn/easy-rsa/keys/client/ta.key 1
cipher BF-CBC
comp-lzo
ns-cert-type server
verb 3

How "ip a" looks like:

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    inet 10.0.2.1/24 brd 10.0.2.255 scope global br0

8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.255.254.9 peer 10.255.254.10/32 scope global tun0

How "ip r" looks like (again I removed default gateway and related):

10.0.0.0/24 via 10.255.254.10 dev tun0 
10.0.2.0/24 dev br0  proto kernel  scope link  src 10.0.2.1 
10.255.254.0/24 via 10.255.254.10 dev tun0 
10.255.254.10 dev tun0  proto kernel  scope link  src 10.255.254.9 

General configurations:

  • Iptables policy is allow for everything
  • IP forwarding is enabled
  • RP filter is disabled

What works:

  • Ping from any host in lan1 to vpn2 ( 10.0.0.11 -> 10.255.254.9 )
  • Ping from any host in lan2 to vpn1 ( 10.0.2.11 -> 10.255.254.1 )
  • Ping from vpn1 to lan2 ( 10.255.254.1 -> any host in lan2 10.0.2.0/24 )
  • Ping from vpn2 to lan1 ( 10.255.254.9 -> any host in lan2 10.0.0.0/24 )

What does not work:

  • Ping from any host in lan1 to lan2
  • Ping from any host in lan2 to lan1

With NAT I was able to:

  • Ping from any host in lan1 to lan2
  • But not from any host in lan2 to lan1But not from any host in lan2 to lan1

I should be able to ping any host in LAN2 from LAN1 without NAT and the other way around. What is wrong here? Something is escaping me and I can't figure out what.

2
  • Sigh, when dealing with routing issues use traceroute not ping to debug! Where does a trace fail? Fire up tcpdump and watch icmp traffic. What errors do you see.
    – Zoredache
    Aug 29, 2013 at 14:59
  • That is exactly what I did to debug from the beginning. I omitted to add that information when I posted. With mtr from LAN1 to LAN2 the traffic stops on tun0 from vpn2. With mtr from LAN2 to LAN1 the traffic stops on br0 on vpn2. It looks like the traffic is not routed between br0 and tun0 on vpn2. On vpn1 I reverted back to a configuration without bridges and it works. Problem is that I can not get rid of the bridge interface on vpn2. Maybe with openvswitch I might have a chance, not sure though.
    – Claudiu
    Aug 29, 2013 at 18:42

1 Answer 1

1

It is a routing issue.

I suspect that your iroute directive is not taking effect. The file you have named "ccd/client" must actually have a filename corresponding to the subject name of the client certificate. So, if the client certificate's DN is C=CA,O=Foo Ltd,CN=Example, the file should be "ccd/Example".

Besides this, your configuration looks correct.

5
  • The iroute configuration is taking effect. Including the ifconfig IP that should be always the same for that specific vpn client. I double checked this.
    – Claudiu
    Aug 29, 2013 at 7:11
  • Consider adding vpn-gateway to the end of your pushed routes. Aug 29, 2013 at 7:15
  • That is automatically implied. I did that though, same result. I agree that this looks like a routing issue, but I can't figure out what it is. The routes look just fine to me.
    – Claudiu
    Aug 29, 2013 at 8:39
  • Maybe do a traceroute from clients on either side, and verify they are trying to send the packet through the routers holding the VPN link. It's possible, depending on your topology, that something else is missing a route it needs. The NAT test you did shows that it's close, and that the problem is almost certainly on the return path. Aug 29, 2013 at 9:33
  • The packets are not forwarded between br0 and tun0 on vpn2. Is there a limitation of this kind with openvpn and tun interfaces?
    – Claudiu
    Aug 29, 2013 at 9:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .