0

I'd like to create a OpenVPN Tunnel between to LANs 192.168.1.0/24 and 192.168.2.0/24. However somehow packets entering the tunnel on one side don't come out of the other side ...

The following hosts are involved:

R1=192.168.1.1  Router in LAN 1
R2=192.168.2.1  Router in LAN 2
S1=192.168.1.10 OpenVPN Server in LAN 1, no ip tables, net.ipv4.ip_forward=1
C2=192.168.2.10 OpenVPN Client in LAN 2, no ip tables, net.ipv4.ip_forward=1
H1=192.168.1.20 Some host in LAN 1 with default gateway R1
H2=192.168.2.20 Some host in LAN 2 with default gateway R2

I set up OpenVPN and installed routes into the routers, configuration see below. Connection working, let's to some pinging.

C2> ping 10.8.0.1        # OK
C2> ping S1=192.168.1.10 # OK
C2> ping R1=192.168.1.1  # OK
S1> ping 10.8.0.6        # OK
S1> ping C2=192.168.2.10 # NO
H1> ping C2=192.168.2.10 # NO
H2> ping S1=192.168.1.10 # NO

I checked on S1 and C2 with tcpdump and I noticed that all ICMP requests arrive one end of the tunnel but don't come out the other end, e.g. pinging at first S1 from H2, which did not work, then pinging C2 from S1

C2> tcpdump -s0 -i tun0
17:05:53.070047 IP C2 > 10.8.0.1: ICMP echo request, id 10190, seq 1, length 64
17:05:53.099990 IP 10.8.0.1 > C2: ICMP echo reply, id 10190, seq 1, length 64
17:06:04.115396 IP C2 > S1: ICMP echo request, id 10194, seq 1, length 64
17:06:04.148898 IP S1 > C2: ICMP echo reply, id 10194, seq 1, length 64
17:06:16.160644 IP 10.8.0.1 > C2: ICMP echo request, id 4479, seq 1, length 64
17:06:16.160720 IP C2 > 10.8.0.1: ICMP echo reply, id 4479, seq 1, length 64
17:06:11.532787 IP C2 > R1: ICMP echo request, id 10221, seq 1, length 64
17:06:11.563275 IP R1 > C2: ICMP echo reply, id 10221, seq 1, length 64
17:07:05.149219 IP H2 > S1: ICMP echo request, id 57470, seq 0, length 64

S1> tcpdump -s0 -i tun0
17:05:53.083547 IP 10.8.0.6 > S1: ICMP echo request, id 10190, seq 1, length 64
17:05:53.083624 IP S1 > 10.8.0.6: ICMP echo reply, id 10190, seq 1, length 64
17:06:04.130861 IP 10.8.0.6 > S1: ICMP echo request, id 10194, seq 1, length 64    
17:06:04.130941 IP S1 > 10.8.0.6: ICMP echo reply, id 10194, seq 1, length 64
17:06:11.546125 IP 10.8.0.6 > R1: ICMP echo request, id 10221, seq 1, length 64
17:06:11.546766 IP R1 > 10.8.0.6: ICMP echo reply, id 10221, seq 1, length 64
17:06:16.144123 IP S1 > 10.8.0.6: ICMP echo request, id 4479, seq 1, length 64
17:06:16.172989 IP 10.8.0.6 > S1: ICMP echo reply, id 4479, seq 1, length 64
17:06:43.928054 IP S1 > C2: ICMP echo request, id 4484, seq 1, length 64
17:06:54.095618 IP H1 > C2: ICMP echo request, id 1091, seq 1, length 64

So it does not seem to be a routing problem, nor any firewall related problem as iptables are empty on both S1 and C2. Any idea what could be the problem? Why don't the packets arrive the end of the tunnel? There seems to be some packet filtering enabled in OpenVPN.

R1 routes:

192.168.2.0/24 via 192.168.1.10 dev lan
10.8.0.0/24 via 192.168.1.10 dev lan

R2 routes: 

192.168.1.0/24 via 192.168.2.10 dev lan
10.8.0.0/24 via 192.168.2.10 dev lan

S1 routes:

default via 192.168.1.1 dev eth0  proto static  metric 1024 
10.8.0.0/24 via 10.8.0.2 dev tun0  proto static  metric 20 
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.10 
192.168.1.1 dev eth0  proto dhcp  scope link  src 192.168.1.10  metric 1024 
192.168.2.0/24 via 10.8.0.2 dev tun0  proto static  metric 20

C2 routes:

default via 192.168.2.1 dev wlp2s0  proto static  metric 1024 
10.8.0.1 via 10.8.0.5 dev tun0  proto static  metric 20 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6 
192.168.1.0/24 via 10.8.0.5 dev tun0  proto static  metric 20 
192.168.2.0/24 dev wlp2s0  proto kernel  scope link  src 192.168.2.10

server.conf

dev tun
port 1195
proto tcp
server 10.8.0.0 255.255.255.0
route 192.168.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

ca       ca.crt
cert     server.crt
key      server.key
dh       dh2048.pem
tls-auth ta.key 0

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody

client.conf

client
dev tun
port 1195
proto tcp-client
tls-client
remote mylan.de 1195

ca       ca.crt
cert     client.crt
key      client.key
tls-auth ta.key 1
verify-x509-name server name

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody
buergi
  • 101
  • 1
  • 4

2 Answers2

0

in H1 try to add a route like this "route add -net 192.168.2.0/24 gw 192.168.1.10" and after that try to ping again, now if you want H1 and H2 ping each other, in H2 do the same, "rout add -net 192.168.1.0/24 gw 192.168.2.10"

In this the two pc in the two lans, they will use the vpn client and vpn server to reach the remote lan
c4f4t0r
  • 5,301
  • 3
  • 31
  • 42
  • Thanks, however, by setting the routes in the routers, which are default gateway for all hosts in the corresponding LAN the packets are routed correctly, they arrive the VPN Tunnel as the tcpdumps show. Traceroute confirms the correct routing. It must have something to do with the VPN configuration, some protection mechanism dropping traffic not originating from the client, or related to such traffic. – buergi Dec 01 '14 at 07:03
0

Found the solution myself, there were two problems: After reading through the openvpn manual the word iroute caught my eye, which was the first and major part of the solution. For details I recommend reading this tutorial https://community.openvpn.net/openvpn/wiki/RoutedLans.

After that almost anything worked except connecting to openvpn server and client host S1 and C2. The second problem was a kernel feature I didn't know about: multiple routing tables and RPDB. There was a second routing table with another default gateway set:

S1> ip route list table 1
default via 192.168.1.1 dev eth0
192.168.1.0/24 via 192.168.1.10 dev eth0

S1> ip rule
0:      from all lookup local
500:    from 192.168.1.10 lookup 1
32766:  from all lookup main
32767:  from all lookup default

The solution was a custom route-up script to inject the correct routes into this routing table.

server.conf

dev tun
port 1195
server 10.8.0.0 255.255.255.0

# allow script execution
script-security 2

# routing information
route 192.168.2.0 255.255.255.0
route-up /etc/openvpn/vpn-route-up.sh
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
client-to-client

# setup client specific iroutes
client-config-dir /etc/openvpn/ccd/

ca       ca.crt
cert     server.crt
key      server.key
dh       dh2048.pem
tls-auth ta.key 0

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody

ccd/client1 on S1 (client1 is the client's CN)

iroute 192.168.2.0 255.255.255.0

client.conf

dev tun
port 1195
client
remote mylan.de 1195

# allow script execution
script-security 2

# routing information
redirect-private bypass-dhcp bypass-dns
route-up vpn-route-up.sh

ca       ca.crt
cert     client1.crt
key      client1.key
tls-auth ta.key 1
verify-x509-name server name

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody

vpn-route-up.sh on S1

#!/bin/sh
ip route add 10.8.0.0/24 dev tun1  proto kernel  scope link  src 10.8.0.1 table 1
ip route add 192.168.2.0/24 via 10.8.0.2 dev tun1 table 1

vpn-route-up.sh on C2

#!/bin/sh
ip route add 10.8.0.0/24 dev tun1  proto kernel  scope link  src 10.8.0.2 table 1
ip route add 192.168.1.0/24 via 10.8.0.1 dev tun1 table 1
buergi
  • 101
  • 1
  • 4