Routing Problem between 2 subnets

heinzelrumpel

Hi,

I have set a this configuration

Server side:
IP:192.168.1.0/24
VPN Net: 10.16.0.0/24
VPN host: 192.168.1.99

server.conf

port 1194

proto udp
dev tun
link-mtu 1400

pkcs12 /etc/openvpn/vm-openvpn.p12.neu


dh /etc/openvpn/dh1024.pem

tls-auth /etc/openvpn/ta_xxxxx.key 0
tls-server
;topology p2p
server 10.16.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

client-config-dir ccd

keepalive 10 120

comp-lzo

max-clients 30

;push "route 192.168.1.0 255.255.255.0"
route 192.168.178.0 255.255.255.0
route 10.10.10.0 255.255.255.0



persist-key
persist-tun


crl-verify /etc/openvpn/keys/crl.pem

status openvpn-status.log

verb 3

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.16.0.1  P-z-P:10.16.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1358  Metrik:1
          RX packets:2160007 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3393908 errors:0 dropped:3385 overruns:0 carrier:0
          Kollisionen:0 SendewarteschlangenlÃ¤nge:100
          RX bytes:406149045 (387.3 MiB)  TX bytes:3064649429 (2.8 GiB)

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.16.0.2       *               255.255.255.255 UH    0      0        0 tun0
10.16.0.0       10.16.0.2       255.255.255.0   UG    0      0        0 tun0
192.168.178.0   10.16.0.2       255.255.255.0   UG    0      0        0 tun0
10.10.3.0       *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.16.0.2       255.255.255.0   UG    0      0        0 tun0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Client gets this from ccd

iroute "192.168.178.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"

Client side:

client.conf

client
dev tun
proto udp
remote xxxxxxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
pkcs12 /etc/openvpn/xxxxxxx.p12
tls-auth /etc/openvpn/ta_xxxxxx.key 1
cipher BF-CBC
comp-lzo
verb 3

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.16.0.22  P-t-P:10.16.0.21  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:454 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14373 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:36049 (35.2 KiB)  TX bytes:851274 (831.3 KiB)

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
10.16.0.1       10.16.0.21      255.255.255.255 UGH   0      0        0 tun0
10.16.0.21      *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     10.16.0.21      255.255.255.0   UG    0      0        0 tun0
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0

root@pi-vpn:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Problem:

I cannot reach a client from either subnet. Pinging thrugh the tunnel via openvpn net works

root@pi-vpn:~# ping 10.16.0.1
PING 10.16.0.1 (10.16.0.1) 56(84) bytes of data.
64 bytes from 10.16.0.1: icmp_req=1 ttl=64 time=21.0 ms
64 bytes from 10.16.0.1: icmp_req=2 ttl=64 time=18.9 ms
64 bytes from 10.16.0.1: icmp_req=3 ttl=64 time=19.5 ms
64 bytes from 10.16.0.1: icmp_req=4 ttl=64 time=19.4 ms
^C
--- 10.16.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 18.942/19.771/21.083/0.795 ms

Pinging from server subnet host192.168.1.17 to client subnet host 192.168.178.1 results in the following

root@vm-openvpn:~# tcpdump -i tun0 -n host 192.168.1.17
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
12:39:36.665919 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 1, length 64
12:39:37.672052 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 2, length 64
12:39:38.680105 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 3, length 64
12:39:39.687462 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 4, length 64
12:39:40.695450 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 5, length 64
12:39:41.703515 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 6, length 64
12:39:42.711659 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 7, length 64
12:39:43.719656 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 8, length 64
12:39:44.727748 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 9, length 64
12:39:45.735881 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 10, length 64
12:39:46.744327 IP 192.168.1.17 > 192.168.178.1: ICMP echo request, id 17217, seq 11, length 64
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

On each side the other net is set in the router (default gateway), otherwise the ping would not be shown via tcpdump. Routing ist set in /proc/sys/net/ipv4/ip_forward

root@vm-openvpn:~# cat /proc/sys/net/ipv4/ip_forward
1

Well, I have no idea, why the subnet are not conencted correcly. Does anybody have a clue what I am doing wrong?

Regards, Heinzelrumpel

maikcat

I cannot reach a client from either subnet. Pinging thrugh the tunnel via openvpn net works

step by step troubleshooting,

from client it self, can you ping:

openvpn servers lan ip?
a client at server side? this client uses as gateway the openvpn servers lan ip? did you disable firewall on it?

if yes then on a pc on your client side,

can you ping openvpn client tun ip?
can you ping openvpn servers tun ip?
can you ping openvpn servers lan ip?

Michael.

heinzelrumpel

Hi,

on client side (from client IP 192.168.178.42)

I cannot ping server Lan IP (192.168.1.99)
I cannot ping server tun IP (10.16.0.1)
I can ping client tun IP (10.16.0.22)

There are absolutley now firewalls. I have setup exact the same solution with this server as you can see in the server.conf with net 10.10.10.0/24. It works perfectly.

maikcat

on client side (from client IP 192.168.178.42)

you mean the pc with the openvpn client on it?

I have setup exact the same solution with this server as you can see in the server.conf with net 10.10.10.0/24. It works perfectly.

so you have 2 clients and 2 networks for routing..

can you post both their ccd files and the names of the certificates used?

Michael.

heinzelrumpel

maikcat wrote
on client side (from client IP 192.168.178.42)
you mean the pc with the openvpn client on it?

Michael.

No, the client with opvn on it has the ip 192.168.178.20

Ping results from that are:

root@pi-vpn:~# ping 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_req=1 ttl=64 time=25.0 ms
64 bytes from 192.168.1.99: icmp_req=2 ttl=64 time=19.2 ms
^C
--- 192.168.1.99 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 19.276/22.141/25.006/2.865 ms
root@pi-vpn:~# ping 10.16.0.1
PING 10.16.0.1 (10.16.0.1) 56(84) bytes of data.
64 bytes from 10.16.0.1: icmp_req=1 ttl=64 time=21.7 ms
64 bytes from 10.16.0.1: icmp_req=2 ttl=64 time=19.3 ms
64 bytes from 10.16.0.1: icmp_req=3 ttl=64 time=17.8 ms
64 bytes from 10.16.0.1: icmp_req=4 ttl=64 time=20.8 ms
^C
--- 10.16.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 17.824/19.936/21.720/1.497 ms
root@pi-vpn:~# ping 192.168.1.13
PING 192.168.1.13 (192.168.1.13) 56(84) bytes of data.
64 bytes from 192.168.1.13: icmp_req=1 ttl=126 time=36.0 ms
64 bytes from 192.168.1.13: icmp_req=2 ttl=127 time=19.5 ms
64 bytes from 192.168.1.13: icmp_req=3 ttl=127 time=25.1 ms
^C
--- 192.168.1.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.556/26.903/36.016/6.836 ms

So this means for me, that the tunnel works, that routing on server side is working, otherwise the packets could not get back.

This is the ccd file from the working network

root@vm-openvpn:~# cat /etc/openvpn/ccd/sesamstrasse
iroute 10.10.10.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

This ist the ccd fiel from the faulty network

root@vm-openvpn:~# cat /etc/openvpn/ccd/xxx_home
iroute "192.168.178.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"

Actually we use pkcs12 to connect. The certificate names included are sesamstrasse.crt and xxx_home.crt

maikcat

can you remove the " from iroute statement from the ccd file?

Michael.

heinzelrumpel

maikcat wrotecan you remove the " from iroute statement from the ccd file?

Michael.

Unbelievable. Thats it. Wow. 2 stupid " cost me that trouble, but how come, that the other network works?

maikcat

This is the ccd file from the working network

root@vm-openvpn:~# cat /etc/openvpn/ccd/sesamstrasse
iroute 10.10.10.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

This ist the ccd fiel from the faulty network

root@vm-openvpn:~# cat /etc/openvpn/ccd/xxx_home
iroute "192.168.178.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"

the other is correct... 😃

Regards,

Michael.

heinzelrumpel

maikcat wrote

This is the ccd file from the working network

root@vm-openvpn:~# cat /etc/openvpn/ccd/sesamstrasse
iroute 10.10.10.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

This ist the ccd fiel from the faulty network

root@vm-openvpn:~# cat /etc/openvpn/ccd/xxx_home
iroute "192.168.178.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"

the other is correct... 😃

Regards,

Michael.

Great. How could I not see this. :o