Weird route while using OpenVPN

Started by herakles, September 15, 2021, 12:06:13 PM

Previous topic - Next topic
September 15, 2021, 12:06:13 PM Last Edit: September 16, 2021, 10:58:53 AM by herakles
Hi!

I am using OpenVPN in OPNsense in such a way, that I have an external VPN-Server, that OPNsense connects to. OPNsense acts as a router inside a LAN and provides this LAN to other OpenVPN clients.

What I see on OPNsense is the following routing table while being connected to the OpenVPN Server:


root@OPNsense:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.178.1      UGS        igb1
8.8.4.4            192.168.178.1      UGHS       igb1
10.8.0.0/24        10.8.0.1           UGS      ovpnc1
10.8.0.0&0xa080001 10.8.0.1           UGS      ovpnc1
10.8.0.1           link#8             UH       ovpnc1
10.8.0.10          link#8             UHS         lo0
127.0.0.1          link#5             UH          lo0
192.168.2.0/24     link#3             U          igb2
192.168.2.1        link#3             UHS         lo0
192.168.123.0/24   link#1             U          igb0
192.168.123.1      link#1             UHS         lo0
192.168.178.0/24   link#2             U          igb1
192.168.178.1      00:0d:b9:5a:0e:69  UHS        igb1
192.168.178.39     link#2             UHS         lo0


Problematic is route


10.8.0.0&0xa080001 10.8.0.1           UGS      ovpnc1


This results in certain adresses being misrouted. Take for example IP-addresses from 142.x.x.x to 143.x.x.x, which in result will be misrouted to the VPN, although they should take the default route.

I do not know, why this route is created. On a Windows client, I do not see this route, only on the OPNsense machine.

This is the OpenVPN client config on the OPNsense machine:


root@OPNsense:~ # cat /var/etc/openvpn/client1.conf
dev ovpnc1
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA512
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local 192.168.178.39
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote x.x.x.x yyyyy
auth-user-pass /var/etc/openvpn/client1.up
ca /var/etc/openvpn/client1.ca
comp-lzo adaptive


And this is the OpenVPN server config:


X@Y:~$ cat /etc/openvpn/server.conf
client-to-client
topology subnet
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.123.0 255.255.255.0"
push "dhcp-option DNS 192.168.123.1"
push "dhcp-option WINS 192.168.123.10"

route 192.168.123.0 255.255.255.0

dev tun

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0

dh /etc/openvpn/dh3072.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key

client-config-dir /etc/openvpn/ccd

max-clients 20

comp-lzo

persist-tun
persist-key

verb 3

keepalive 10 60
reneg-sec 0

plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login
client-cert-not-required
username-as-common-name
#duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp
port yyyyy
cipher AES-256-CBC
auth SHA512

mssfix 1431


How can I get rid of this route?

Best regards and thanks in advance,
Dennis

Solution found!

I had client-based scripts activated for those that connect to the server, check the following dirctive in the server config:


client-config-dir /etc/openvpn/ccd


Problem was, that the file for that sepcific client that made this mistake, had this information:


ifconfig-push 10.8.0.10 10.8.0.1


This is wrong, as ifconfig-push expects the netmask as second parameter, not the server-IP.

So the problem was related to the open space in between chair and monitor and nowhere else.

Thanks to everyone who has had some thoughts on this weird problem.

All the best,
Dennis