OpenVPN routing problem

English Network/Internet
#1

Hi

I have problem connecting from OpenSuse(public wifi) to my OpenVPN Server(Home).
I am struggling with this for weeks. I can connect from my phone(4G) so I know server side is good.

Thanks in advance for help.

My net before OpenVpn

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: p6p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 98:e7:43:04:53:da brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:d5:64:57:36:2d brd ff:ff:ff:ff:ff:ff
    inet 10.1.215.115/16 brd 10.1.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 82121sec preferred_lft 82121sec
    inet6 fe80::ef35:860b:4b4:b330/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever


ip route show
default via 10.1.0.1 dev wlp2s0 proto dhcp metric 600 
10.1.0.0/16 dev wlp2s0 proto kernel scope link src 10.1.215.115 metric 600

Trying to connect to OpenVpn I get “/bin/ip route add 0.0.0.0/1 via 192.168.1.1
Error: Nexthop has invalid gateway.”

 # openvpn client.ovpn 
Sat Apr  4 20:56:22 2020 us=382609 ROUTE_GATEWAY 10.1.0.1/255.255.0.0 IFACE=wlp2s0 HWADDR=ac:d5:64:57:36:2d
Sat Apr  4 20:56:22 2020 us=383248 TUN/TAP device tap0 opened
Sat Apr  4 20:56:22 2020 us=383373 TUN/TAP TX queue length set to 100
Sat Apr  4 20:56:22 2020 us=383480 /bin/ip route add 0.0.0.0/1 via 192.168.1.1
Error: Nexthop has invalid gateway.
Sat Apr  4 20:56:22 2020 us=393040 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Apr  4 20:56:22 2020 us=393142 /bin/ip route add 128.0.0.0/1 via 192.168.1.1
Error: Nexthop has invalid gateway.
Sat Apr  4 20:56:22 2020 us=396435 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Apr  4 20:56:22 2020 us=396610 Initialization Sequence Completed
^CSat Apr  4 20:56:32 2020 us=41464 event_wait : Interrupted system call (code=4)
Sat Apr  4 20:56:32 2020 us=41959 TCP/UDP: Closing socket
Sat Apr  4 20:56:32 2020 us=42118 /bin/ip route del 0.0.0.0/1
RTNETLINK answers: No such process
Sat Apr  4 20:56:32 2020 us=44742 ERROR: Linux route delete command failed: external program exited with error status: 2


 ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: p6p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 98:e7:43:04:53:da brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:d5:64:57:36:2d brd ff:ff:ff:ff:ff:ff
    inet 10.1.215.115/16 brd 10.1.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 81438sec preferred_lft 81438sec
    inet6 fe80::ef35:860b:4b4:b330/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
13: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 100
    link/ether b6:4c:ad:87:4f:30 brd ff:ff:ff:ff:ff:ff


ip route show
default via 10.1.0.1 dev wlp2s0 proto dhcp metric 600 
10.1.0.0/16 dev wlp2s0 proto kernel scope link src 10.1.215.115 metric 600
#2

Is your openSUSE client connecting via NetworkManager?

#3

I notice from inspecting the log snippet you shared that the tap0 interface is not brought up and no address assigned. I’d expect to see something like the following evident…

/sbin/ip link set dev tap0 up mtu 1500
/sbin/ip addr add dev tap0 10.8.0.4/24 broadcast 10.8.0.255

BTW, from the reference to 192.168.1.1 in your output, I assume that you’re using 192.168.1.0/24 tunnelling addresses?

#4

Hi deano_ferrari,

thank you very much for help.

Yes I am using NetworkManager as network client. (but I am open to suggestions)
And I expect to get IP from that range 192.168.1.0/24.
gw should be my router 192.168.1.1

There is no tap0 interface until I start openvpn connection.

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: p6p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 98:e7:43:04:53:da brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:d5:64:57:36:2d brd ff:ff:ff:ff:ff:ff
    inet 10.1.215.115/16 brd 10.1.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 85137sec preferred_lft 85137sec
    inet6 fe80::ef35:860b:4b4:b330/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Than I start openvpn connection. I have tried what you suggested, bringing UP tap0 and adding route.
tap0 is UP route is there but I cant ping 192.168.1.1. In shell where I have started openvpn connection there is nothing new(routing/connecting) after adding route.

# ip route show
default via 10.1.0.1 dev wlp2s0 proto dhcp metric 600 
10.1.0.0/16 dev wlp2s0 proto kernel scope link src 10.1.215.115 metric 600 
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.4

#ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: p6p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 98:e7:43:04:53:da brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:d5:64:57:36:2d brd ff:ff:ff:ff:ff:ff
    inet 10.1.215.115/16 brd 10.1.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 85246sec preferred_lft 85246sec
    inet6 fe80::ef35:860b:4b4:b330/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
8: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/ether b6:4c:ad:87:4f:30 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.4/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever

#ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6113ms
#5

Ok, thanks for confirming. The 10.8.0.0/24 is the default openVPN range, so my example was based on that.

There is no tap0 interface until I start openvpn connection.

Yes, that is to be expected. :wink:

Ordinarily, this should all be taken care of automatically of course, but reading online there seem to be a few who are impacted similarly and resulting in the gateway error you were getting.

Since you’re using 192.168.1.0/24, you could try assigning tap0 with 192.168.1.4 (for example) or whatever your server config should have pushed…

/sbin/ip link set dev tap0 up mtu 1500
/sbin/ip addr add dev tap0 192.168.1.4/24 broadcast 192.168.1.255
#6

BTW, some users have found that adding a route delay helps if using DHCP for the tunnel addressing. It is explained here

Reference:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

–route-delay [n] [w]
Delay n seconds (default=0) after connection establishment, before adding routes. If n is 0, routes will be added immediately upon connection establishment. If –route-delay is omitted, routes will be added immediately after TUN/TAP device open and –up script execution, before any –user or –group privilege downgrade (or –chroot execution.)This option is designed to be useful in scenarios where DHCP is used to set tap adapter addresses. The delay will give the DHCP handshake time to complete before routes are added.

So, you could try adding a 4 second delay to your client config and see if that makes a difference with providing time to get the tap0 address and subsequent routing in place…

route-delay 4
#7

It`s working !

Man you are genius !
You don`t have a clue for how long I was fighting with this before I opened a thread.
Thank you so much.

ip route show
default via 10.1.0.1 dev wlp2s0 proto dhcp metric 600 
10.1.0.0/16 dev wlp2s0 proto kernel scope link src 10.1.215.115 metric 600 
89.164.111.100 via 10.1.0.1 dev wlp2s0 
192.168.1.0/24 dev tap0 proto kernel scope link src 192.168.1.4 


ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: p6p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 98:e7:43:04:53:da brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:d5:64:57:36:2d brd ff:ff:ff:ff:ff:ff
    inet 10.1.215.115/16 brd 10.1.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 81256sec preferred_lft 81256sec
    inet6 fe80::ef35:860b:4b4:b330/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/ether b6:4c:ad:87:4f:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global tap0
       valid_lft forever preferred_lft forever

ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=14.7 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.74 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=5.29 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=5.52 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=8.16 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=5.40 ms
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 4.738/7.301/14.696/3.483 ms

I will now try with delay setup in server… and be right back.

#8

Glad to have been of assistance. The manual commands are only a workaround, but at least it provides a means to have a working VPN tunnel for now. Hopefully the route delay will do the trick to having it work automatically.

#9

Unfortunately its not working when I add “route-delay 4” (or 10 )to client config.
What can I do now to make it permanent.

I just dont understand why I can add route manually but not thru client config.
Is he pushing right routes ?

 *ERROR: Nexthop has invalid gateway. ERROR: Linux route add command failed: external program exited with error status: 2*

TUN/TAP device tap0 opened
Mon Apr  6 22:13:20 2020 us=902000 TUN/TAP TX queue length set to 100
Mon Apr  6 22:13:24 2020 us=370196 /bin/ip route add 89.164.xxx.yyy/32 via 10.1.0.1
Mon Apr  6 22:13:24 2020 us=371619 /bin/ip route add 0.0.0.0/1 via 192.168.1.1
Error: Nexthop has invalid gateway.
Mon Apr  6 22:13:24 2020 us=372822 ERROR: Linux route add command failed: external program exited with error status: 2
Mon Apr  6 22:13:24 2020 us=372861 /bin/ip route add 128.0.0.0/1 via 192.168.1.1
Error: Nexthop has invalid gateway.
#10

This is my client config

dev tap
persist-tun
persist-key
cipher AES-256-CBC
ncp-disable
auth SHA512
tls-client
client
resolv-retry infinite
remote my-name.org 1194 udp
route-gateway 192.168.1.1
remote server 1194
lport 0
verify-x509-name "OpenVpn Server" name
remote-cert-tls server
#fragment 0
#float
comp-lzo adaptive
tun-mtu 1500
auth-nocache
route-delay 10
verb 4

When I remove route-gateway 192.168.1.1 from config I get

NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
#11

As you can see the gateway doesn’t exist, since tap0 doesn’t yet have an address assigned. I’m not sure why the regression exists though and a bug report might be needed. Does adding a longer route delay help?

#12

Yes, don’t do that.

#13

Can you post your working sever configuration? Are you using DHCP or pushing a static IP address? I’m wondering if the server and/or client config just needs tuning. Which guide were you following?

**–route-gateway gw|’dhcp’**Specify a default gateway gw for use with **–route.**If dhcp is specified as the parameter, the gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN.

#14

Adding longer delay is not working.
Im using OpenVpn TAP server on pfSense box. And using single DHCP to provide address to LAN and OpenVpn. I have assigned one part of the range for DHCP and other smaller to give fix IP. Dont know how to export OpenVpn settings from pfSense.

I’m wondering if the server and/or client config just needs tuning. Which guide were you following?

Maybe in client config instead –route-gateway using* --ifconfig* to assign IP.
I have this setup for some years but I didn’t have real need to use PC to connect. And Android was working.

Maybe I do have to fill bug report. But to whom, OpenVpn or OpenSuse ? I am new to OS community.

#15

Perhaps try the OpenVPN Forums first.