Openvpn LAN IP not going through tunnel

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

yeah my question might be better in a Openvpn forum but I am still going to ask here as the Server is on Openwrt and also I have seen here super capable people on the forum.
I have several Openvpn Client/Server setup and all of them working but one Client/Server is driving me nuts as I think I have everything correctly configured but it it only working with the clients transfer net IP and not the LAN IP.

When I ping the server from transfer net IP I get a clean reply. But when I use the LAN IP (of the client) as a source of the ping I can see the package going into the tunnel but it doesn't come out on the other end. I have not seen any errors in the logs and when I connect to a different server with the client it is working as expected.

Here the tests I done with the tcpdump results.

Client Side:
IP Addresses:
eth0: inet 192.168.178.4 netmask 255.255.255.0 broadcast 192.168.178.255
tun1: inet 10.20.0.6 netmask 255.255.255.255 destination 10.20.0.5

Routes:
10.20.0.1 via 10.20.0.5 dev tun1
10.20.0.5 dev tun1 proto kernel scope link src 10.20.0.6
192.168.100.0/24 via 10.20.0.5 dev tun1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.4 metric 202

Server Side:
IP Addresses:
br-lan: inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
tun1: inet addr:10.20.0.1 P-t-P:10.20.0.2 Mask:255.255.255.255

Routes:
10.20.0.0/28 via 10.20.0.2 dev tun1
10.20.0.2 dev tun1 scope link src 10.20.0.1
192.168.100.0/24 dev br-lan scope link src 192.168.100.1
192.168.178.0/24 via 10.20.0.2 dev tun1

Running ping -c 1 10.20.0.1
Client Tunnel tcpdump:
12:59:04.823319 IP 10.20.0.6 > 10.20.0.1: ICMP echo request, id 18427, seq 1, length 64
12:59:04.847484 IP 10.20.0.1 > 10.20.0.6: ICMP echo reply, id 18427, seq 1, length 64

Server Tunnel tcpdump:
13:59:04.837792 IP 10.20.0.6 > 10.20.0.1: ICMP echo request, id 18427, seq 1, length 64
13:59:04.837993 IP 10.20.0.1 > 10.20.0.6: ICMP echo reply, id 18427, seq 1, length 64

Running ping -c 1 -I 192.168.178.4 10.20.0.1
Client Tunnel tcpdump:
13:00:43.857853 IP 192.168.178.4 > 10.20.0.1: ICMP echo request, id 18431, seq 1, length 64

Server Tunnel tcpdump:
NOTHING

2

Shouldn't that be via 10.20.0.6?

3

Not that I am aware of, as that route normally points to the local end of the tunnel not the remote

4

On the client it is evident that client has 10.20.0.6 and server 10.20.0.5

Did you add this route manually or is it part of the configuration?
Post also the server/client configs.

Please use the "Preformatted text </>" button for logs, scripts, configs and general console output.
grafik

1 Like
5

Didn't add it manually

mode server
tls-server
tls-auth /etc/openvpn/keys/ta.key 0
port 7900
proto tcp
dev tun1
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/router.server.crt
key /etc/openvpn/keys/router.server.key
dh /etc/openvpn/keys/dh2048.pem
server 10.20.0.0 255.255.255.240
push "route 192.168.100.0 255.255.255.0 vpn_gateway"
client-config-dir /etc/openvpn/remote-config/
route 192.168.178.0 255.255.255.0
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
verb 3
keepalive 20 120

remote-config on server
iroute 192.168.178.0 255.255.255.0

Client config


client
tls-client
tls-auth ta.key 1
dev tun1
proto tcp
remote SERVER 7900
remote-cert-tls server
resolv-retry infinite
nobind
ca ca.crt
cert client.crt
key client.key
comp-lzo
cipher AES-256-CBC
persist-tun
persist-key
verb 3
6

without the vpn_gateway.

This one needs a gateway

1 Like
7

removed that

have now route 192.168.178.0 255.255.255.0 10.20.0.2
Result is the same.

8

Why do you insist on 10.20.0.2? The client has 10.20.0.6 on tun1

1 Like
9

Post the server side logs while connecting the problematic client.

10

If I use 10.20.0.6 there it will not add the route as the 10.20.0.6 is not a IP on the router and would not be accepted as a gateway.

root@router:~# ip ro add 192.168.178.0/24 via 10.20.0.6 dev tun1
ip: RTNETLINK answers: Network unreachable
11

Why don't you use topology subnet?

12 
Oct 20 17:47:20 router openvpn(server)[9558]: DE_Client/156.67.135.36:6409 Connection reset, restarting [0]
Oct 20 17:47:20 router openvpn(server)[9558]: DE_Client/156.67.135.36:6409 SIGUSR1[soft,connection-reset] received, client-instance restarting
Oct 20 17:47:20 router openvpn(server)[9558]: TCP connection established with [AF_INET]156.67.135.36:6426
Oct 20 17:47:21 router openvpn(server)[9558]: 156.67.135.36:6426 TLS: Initial packet from [AF_INET]156.67.135.36:6426, sid=ebc54dbf 16d4adf3
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 VERIFY OK: depth=1, C=HK
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 VERIFY OK: depth=0, C=DE
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_VER=2.4.7
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_PLAT=linux
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_PROTO=2
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_NCP=2
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_LZ4=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_LZ4v2=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_LZO=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_COMP_STUB=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_COMP_STUBv2=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 peer info: IV_TCPNL=1
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Oct 20 17:47:22 router openvpn(server)[9558]: 156.67.135.36:6426 [Net] Peer Connection Initiated with [AF_INET]156.67.135.36:6426
Oct 20 17:47:22 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 MULTI_sva: pool returned IPv4=10.20.0.6, IPv6=(Not enabled)
Oct 20 17:47:22 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 MULTI: Learn: 10.20.0.6 -> DE_Client/156.67.135.36:6426
Oct 20 17:47:22 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 MULTI: primary virtual IP for DE_Client/156.67.135.36:6426: 10.20.0.6
Oct 20 17:47:23 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 PUSH: Received control message: 'PUSH_REQUEST'
Oct 20 17:47:23 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 SENT CONTROL [Net]: 'PUSH_REPLY,route 192.168.100.0 255.255.255.0,route 10.20.0.1,topology net30,ping 20,ping-restart 120,ifconfig 10.20.0.6 10.20.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Oct 20 17:47:23 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 Data Channel: using negotiated cipher 'AES-256-GCM'
Oct 20 17:47:23 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Oct 20 17:47:23 router openvpn(server)[9558]: DE_Client/156.67.135.36:6426 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
1 Like
13

Would have to read up on that. I just used a config that is working on my other client/router config.

14

You are not supposed to add it like this.
And as you can see from the logs the client has 10.20.0.6
Maybe @vgaetera can verify that client-config is correct?

1 Like
15

That was just to show you that you can not use a gateway that is not local to the router.

16

The log must have similar lines for 192.168.178.0/24.
As they are missing, this means your CCD config is likely incorrect.

1 Like
17

Thats the CCD config
iroute 192.168.178.0 255.255.255.0

1 Like
18

Make sure the cert CN matches the config file name:

1 Like
19

OMG, I knew it was something simple on which I wasted hours :slight_smile:
The name was DE_client a simple lower case c instead of upper case C.

@vgaetera many thanks for reminding me!

Basically all configs were correct just a small typo

2 Likes
20

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.