I have my own wireless router to which a remote VPN client, 10.7.0.6, is connected. I want traffic from one of the wireless clients to go through it, but I’m getting «Nexthop has invalid gateway». (I’m aware that I’ll have to persuade 10.7.0.6 to play ball, but the present problem comes before that I think.)
This is the router, 10.0.0.1:
[ad@rout ~]$ ip addr
1: lo: ...
2: wlp0s20f0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:32:1b:06:18:1b brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global wlp0s20f0u1
valid_lft forever preferred_lft forever
...
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 10.7.0.1 peer 10.7.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
...
23: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 82.69.221.62 peer 62.3.89.162/32 scope global ppp0
valid_lft forever preferred_lft forever
[ad@rout ~]$ ip route
default dev ppp0 scope link
10.0.0.0/24 dev wlp0s20f0u1 proto kernel scope link src 10.0.0.1
10.7.0.0/24 via 10.7.0.2 dev tun0
10.7.0.2 dev tun0 proto kernel scope link src 10.7.0.1
62.3.89.162 dev ppp0 proto kernel scope link src 82.69.221.62
and this is the client, 10.0.0.2, before I start mucking around:
ad@blackmail:~$ ip addr
1: ...
2: ...
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 60:57:18:43:12:fa brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global noprefixroute wls1
valid_lft forever preferred_lft forever
inet6 fe80::6257:18ff:fe43:12fa/64 scope link
valid_lft forever preferred_lft forever
ad@blackmail:~$ ip route
default via 10.0.0.1 dev wls1 proto dhcp src 10.0.0.2 metric 303 mtu 1492
10.0.0.0/24 dev wls1 proto dhcp scope link src 10.0.0.2 metric 303 mtu 1492
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
ad@blackmail:~$ ping google.com
PING google.com (216.58.198.238) 56(84) bytes of data.
64 bytes from lhr26s04-in-f238.1e100.net (216.58.198.238): icmp_seq=1 ttl=53 time=17.0 ms
ad@blackmail:~$ ping 10.7.0.6
PING 10.7.0.6 (10.7.0.6) 56(84) bytes of data.
64 bytes from 10.7.0.6: icmp_seq=1 ttl=63 time=626 ms
ad@blackmail:~$ traceroute 10.7.0.6
traceroute to 10.7.0.6 (10.7.0.6), 30 hops max, 60 byte packets
1 rout (10.0.0.1) 3.777 ms 5.372 ms 7.143 ms
2 10.7.0.6 (10.7.0.6) 153.924 ms 153.948 ms 153.999 ms
Now I try to make it go via 10.7.0.6:
ad@blackmail:~$ su
Password:
[root@blackmail ~]# ip route del default
[root@blackmail ~]# ip route add 10.7.0.0/24 via 10.0.0.1
[root@blackmail ~]# ping 10.7.0.6
PING 10.7.0.6 (10.7.0.6) 56(84) bytes of data.
64 bytes from 10.7.0.6: icmp_seq=1 ttl=63 time=428 ms
[root@blackmail ~]# ip route add default via 10.7.0.6
Error: Nexthop has invalid gateway.
Why?
Not sure if installation, configuration or bug report…
I am installing OpenVPN for the first time, so I may of course have missed something, but..
When my (linux) client connects to the vpn, it connects successfully with the following output:
Code: Select all
Fri Feb 2 17:20:29 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,compress lz4-v2,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: timers and/or timeouts modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: compression parms modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: route options modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: route-related options modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: peer-id set
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Feb 2 17:20:29 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Feb 2 17:20:29 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Feb 2 17:20:29 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Feb 2 17:20:29 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Feb 2 17:20:29 2018 ROUTE_GATEWAY 192.168.43.1/255.255.255.0 IFACE=wlp3s0 HWADDR=ac:bc:32:af:1b:bd
Fri Feb 2 17:20:29 2018 TUN/TAP device tun0 opened
Fri Feb 2 17:20:29 2018 TUN/TAP TX queue length set to 100
Fri Feb 2 17:20:29 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Feb 2 17:20:29 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Fri Feb 2 17:20:29 2018 /usr/bin/ip addr add dev tun0 10.8.0.4/24 broadcast 10.8.0.255
Fri Feb 2 17:20:29 2018 /usr/bin/ip route add a.b.c.d/32 via 192.168.43.1
RTNETLINK answers: File exists
Fri Feb 2 17:20:29 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Feb 2 17:20:29 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.8.0.1
Fri Feb 2 17:20:29 2018 /usr/bin/ip route add 128.0.0.0/1 via 10.8.0.1
Fri Feb 2 17:20:29 2018 /usr/bin/ip route add 192.168.0.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Feb 2 17:20:29 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Feb 2 17:20:29 2018 GID set to nobody
Fri Feb 2 17:20:29 2018 UID set to nobody
Fri Feb 2 17:20:29 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Feb 2 17:20:29 2018 Initialization Sequence Completed
The RTNETLINK error is (i gather) that that rule already exists, i.e. no harm in that error. The second error is «Error: Nexthop has invalid gateway.«, which I will get back to below.
Even though the connection ends in «Initialization Sequence Completed», I quickly notice that I cant ping the server (10.8.0.1, config below), and that the vpn generally doesn’t work. Looking at the ip route:
Code: Select all
# ip route show
default via 192.168.43.1 dev wlp3s0 proto dhcp src 192.168.43.43 metric 1024
a.b.c.d via 192.168.43.1 dev wlp3s0
192.168.43.0/24 dev wlp3s0 proto kernel scope link src 192.168.43.43
192.168.43.1 dev wlp3s0 proto dhcp scope link src 192.168.43.43 metric 1024
and addresses
Code: Select all
# ip addr show
...
21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet6 fe80::ec3c:2ec7:a5ec:5015/64 scope link stable-privacy
valid_lft forever preferred_lft forever
I.e. the tun0 has not received neither ip nor routes. Of course, manually adding the routes yields the same «Error: Nexthop has invalid gateway.» as above, as the ip needs to be set first. Manually executing the «ip addr add» command from the openvpn output finishes successfully, and after also manually adding the routes (which now works, since the ip is defined), the vpn connection is all up and running.
It thus seems that the ip addr add command takes no effect and the subsequent errors follow from that. The question now is, am I doing something wrong or is this a bug?
Client config:
Code: Select all
client
dev tun
proto udp
remote ***** ***
nobind
user nobody
group nobody
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
key-direction 1
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
compress lz4-v2
push "compress lz4-v2"
verb 3
Server config:
Code: Select all
port 443
proto udp
dev tun
ca ca.crt
cert nanoheart.crt
key nanoheart.key # This file should be kept secret
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
key-direction 0
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
compress lz4-v2
push "compress lz4-v2"
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
Client version:
Code: Select all
$ openvpn --version
OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no
Server version:
Code: Select all
OpenVPN 2.4.3 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 3 2017
library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no
Содержание
- OpenVPN Support Forum
- ip addr add not taking effect
- ip addr add not taking effect
- Error: Nexthop has invalid gateway. #828
- Comments
- Why «Nexthop has invalid gateway» when it seems to be defined?
- 6 Answers 6
- Error: Nexthop has invalid gateway. #828
- Comments
- Routing through a router which is in another network – “Error: Nexthop has invalid gateway.”
- 1 Answer 1
OpenVPN Support Forum
Community Support Forum
ip addr add not taking effect
ip addr add not taking effect
Post by jonatan.olofsson » Fri Feb 02, 2018 5:13 pm
Not sure if installation, configuration or bug report.
I am installing OpenVPN for the first time, so I may of course have missed something, but..
When my (linux) client connects to the vpn, it connects successfully with the following output:
The RTNETLINK error is (i gather) that that rule already exists, i.e. no harm in that error. The second error is » Error: Nexthop has invalid gateway.«, which I will get back to below.
Even though the connection ends in «Initialization Sequence Completed», I quickly notice that I cant ping the server (10.8.0.1, config below), and that the vpn generally doesn’t work. Looking at the ip route:
I.e. the tun0 has not received neither ip nor routes. Of course, manually adding the routes yields the same » Error: Nexthop has invalid gateway.» as above, as the ip needs to be set first. Manually executing the «ip addr add» command from the openvpn output finishes successfully, and after also manually adding the routes (which now works, since the ip is defined), the vpn connection is all up and running.
It thus seems that the ip addr add command takes no effect and the subsequent errors follow from that. The question now is, am I doing something wrong or is this a bug?
Источник
Error: Nexthop has invalid gateway. #828
Possible to fix?
Connecting from server client to server openvpn
The text was updated successfully, but these errors were encountered:
Can you post the details of ip a and ip r
I try other server and no matter what i try, after i do openvpn mycnf.ovpn it freezes, only reboot helps as like no network . Does it even works on server-to-server vpn? on my local machines that vpn works, but not works on dedicated servers from diff providers vpnOVH-to-vpnSOMEOTHERSERVER
SERVER A — ip a on vpn server (to this i am connecting from other server)
mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::b639:6dcd:feda:24b2/64 scope link stable-privacy valid_lft forever preferred_lft forever»>
SERVER A — ip r on vpn server (to this i am connecting from other server)
SERVER B — ip a on vpn server (from this server i am connecting to the above server)
mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fddd:1194:1194:1194::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::793a:fa2c:fe6b:9c7e/64 scope link stable-privacy valid_lft forever preferred_lft forever»>
SERVER B — ip r on vpn server (from this server i am connecting to the above server)
Источник
Why «Nexthop has invalid gateway» when it seems to be defined?
I have my own wireless router to which a remote VPN client, 10.7.0.6, is connected. I want traffic from one of the wireless clients to go through it, but I’m getting «Nexthop has invalid gateway». (I’m aware that I’ll have to persuade 10.7.0.6 to play ball, but the present problem comes before that I think.)
This is the router, 10.0.0.1:
and this is the client, 10.0.0.2, before I start mucking around:
Now I try to make it go via 10.7.0.6:
6 Answers 6
Perhaps something like:
«Direct connection» can be part of a Layer 2 bridge, as I found, very useful for assigning spare public IPs to internal devices without having to resort to NAT nastiness and complexity..
A gateway address can only be on a directly connected network. The 10.7.0.0/24 network is not directly connected to your host 10.0.0.2, but is instead separated by another network, which is connected to the host at 10.0.0.1.
You must use 10.0.0.1 as your gateway for this network, and that host must also be configured to route the packets in the desired manner.
I’ve also encountered the problem, you need
be aware that if the link has dependencies on other links, such as veth pair, you also need enable them too.
I think this command could solve your problem :
In this case, we consider gateway is always «onlink».
You need policy based routing at your router because the client has no direct connection to the next hop. There is a quick introduction to policy based routing and it was also discussed at this question at superuser.
In your case it could look like this:
I suffered the same problem with OpenPVN tunnels and finally solved by using tap device instead tun.
I think network layer 2 bypasses the problem trying to route every packet independently of the interface state (not really sure about this but it eventually works).
If you are using OpenVPN, change dev in every ovpn config file (server and clients):
Other non OpenVPN setup has to be solved differently (please, comment it here if also solved with tap interfaces).
Источник
Error: Nexthop has invalid gateway. #828
Possible to fix?
Connecting from server client to server openvpn
The text was updated successfully, but these errors were encountered:
Can you post the details of ip a and ip r
I try other server and no matter what i try, after i do openvpn mycnf.ovpn it freezes, only reboot helps as like no network . Does it even works on server-to-server vpn? on my local machines that vpn works, but not works on dedicated servers from diff providers vpnOVH-to-vpnSOMEOTHERSERVER
SERVER A — ip a on vpn server (to this i am connecting from other server)
mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::b639:6dcd:feda:24b2/64 scope link stable-privacy valid_lft forever preferred_lft forever»>
SERVER A — ip r on vpn server (to this i am connecting from other server)
SERVER B — ip a on vpn server (from this server i am connecting to the above server)
mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fddd:1194:1194:1194::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::793a:fa2c:fe6b:9c7e/64 scope link stable-privacy valid_lft forever preferred_lft forever»>
SERVER B — ip r on vpn server (from this server i am connecting to the above server)
Источник
Routing through a router which is in another network – “Error: Nexthop has invalid gateway.”
We have the networks 192.168.88.0/22, 192.168.40.0/23, 192.168.10.0/24.
On 192.168.88.73 is a router (OS: Debian 10) to route from 192.168.40.0 to 192.168.10.0, it has an interface on 192.168.10.0, too.
On 192.168.40.131 is a client (also Debian 10) which should use the router on 192.168.88.73 to connect to 192.168.10.0. It can use the default gateway (192.168.40.251) to connect to 192.168.88.0/22 network. The client was in the past in the same network like the 192.168.88.73 router and it worked, so the router works (ping is ok).
I tried ip route add 192.168.10.0/24 via 192.168.88.73 dev eth0 to create a static route to the router, but it doesn’t work. The error message is: «Error: Nexthop has invalid gateway.».
The reason for this is obviously, the client is not in the same network like the router. But I don’t find a solution.
I tried then route add -host 192.168.88.73 gw 192.168.40.251 as Google suggests, although it is already default gateway. But it didn’t work for me.
1 Answer 1
The solution to your problem is quite obvious: your router needs a network interface inside the client network (192.168.40.0/23) and an interface inside the destination network (192.168.88.0/22) to be able to route packets. After assigning the IP, you need to set this newly assigned IP as gateway: route add -net 192.168.88.0/22 gw 192.168.40.XXX
And don’t forget that the communication is bidirectional: unless you masquerade the routed ip, the destination network also needs a route into the client network!
and, of course, you need to do the same with the third network (192.168.10.0/24)
Obviously, there still is confusion. if you cannot add an network interface to the directly connected router, you need to put in place the routes on the gateway which has the interface. Let me draw a network layout for clarification.
I’ll make the following assumptions:
- Your Default Gateway (192.168.40.251) also is part of the network 192.168.88.0/22, and has the ip 192.168.88.251 inside that network
- Your Router 192.168.88.73 also has a network interface in the 192.168.10.0/24 network
I do not know your network layout in detail, but these assumptions should clarify where to install what routes to achieve that the client A is able to reach the target network.
- Client A only needs one route: the default route over the Default gateway
- On your Default Gateway, you need to install the following route: route add -net 192.168.10.0/24 gw 192.168.88.73 . This works because the default gateway has a network interface to the .88.0/22 network
- on your Router A, you need to install the «backwards» route: route add -net 192.168.40.0/23 gw 192.168.88.251
Источник
Is there a pinned issue for this?
- I have read the pinned issues and could not find my issue
Is there an existing or similar issue/discussion for this?
- I have searched the existing issues
- I have searched the existing discussions
Is there any comment in the documentation for this?
- I have read the documentation, especially the FAQ and Troubleshooting parts
Is this related to a provider?
- I have checked the provider repo for issues
- My issue is NOT related to a provider
Are you using the latest release?
- I am using the latest release
Have you tried using the dev branch latest?
- I have tried using dev branch
Docker run config used
torrent:
image: haugene/transmission-openvpn
container_name: torrent
hostname: torrent
cap_add:
— NET_ADMIN
devices:
— /dev/net/tun
restart: always
dns:
— 8.8.8.8
— 8.8.4.4
volumes:
— /etc/localtime:/etc/localtime:ro
— tor_data:/data
— tor_scripts:/scripts
logging:
driver: «json-file»
options:
max-size: «50m»
max-file: «2»
environment:
— OPENVPN_PROVIDER=NORDVPN
— OPENVPN_USERNAME=HIDDEN
— OPENVPN_PASSWORD=HIDDEN
— OPENVPN_OPTS=
— NORDVPN_COUNTRY=nl
— NORDVPN_PROTOCOL=udp
— NORDVPN_CATEGORY=legacy_p2p
— HEALTH_CHECK_HOST=8.8.8.8
— LOCAL_NETWORK=192.168.56.0/24
volumes:
data:
tor_data:
tor_scripts:
Current Behavior
Since latest version, the route to the VPN server cannot be setup by the container.
The error is:
/sbin/ip route add 213.152.188.73/32 via 192.168.56.254
Error: Nexthop has invalid gateway.
Sat Nov 12 00:32:07 2022 ERROR: Linux route add command failed: external program exited with error status: 2
Expected Behavior
The ip route command to succeed
How have you tried to solve the problem?
-
I tried manually to type
/sbin/ip route add 213.152.188.73/32 via 192.168.56.254
and it failed -
I typed
/sbin/ip route add 213.152.188.73/32 via 192.168.56.254 dev eth0 onlink
and it worked -
Until a fix is found I added this lines in my transmission-post-start.sh
ip=$(grep "^remote " /etc/openvpn/nordvpn/*.ovpn | cut -f2 -d' ' | head -1)
/sbin/ip route add $ip/32 via 192.168.56.254 dev eth0 onlink
Log output
Starting container with revision: f9cb4dea2da1a3aa63bd3945e0162c9b8a9789a4
Creating TUN device /dev/net/tun
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
INFO: OVPN: Checking curl installation
INFO: OVPN: DNS resolution ok
INFO: OVPN: ok, configurations download site reachable
INFO: OVPN: Removing existing configs in /etc/openvpn/nordvpn
Checking NORDPVN API responses
INFO: OVPN:Selecting the best server...
INFO: OVPN: Searching for country : nl (153)
INFO: OVPN: Searching for group: legacy_p2p
INFO: OVPN:Searching for technology: openvpn_udp
INFO: OVPN: Best server : nl925.nordvpn.com, load: 7
INFO: OVPN: Downloading config: nl925.nordvpn.com.ovpn
INFO: OVPN: Downloading from: https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/nl925.nordvpn.com.udp.ovpn
Starting OpenVPN using config nl925.nordvpn.com.ovpn
Modifying /etc/openvpn/nordvpn/nl925.nordvpn.com.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Modification: Updating status for config failure detection
Setting OpenVPN credentials...
adding route to local network 192.168.56.0/24 via 192.168.56.254 dev eth0
Sat Nov 12 00:32:06 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Sat Nov 12 00:32:06 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Sat Nov 12 00:32:06 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Nov 12 00:32:06 2022 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Nov 12 00:32:06 2022 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Nov 12 00:32:06 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]213.152.188.73:1194
Sat Nov 12 00:32:06 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Nov 12 00:32:06 2022 UDP link local: (not bound)
Sat Nov 12 00:32:06 2022 UDP link remote: [AF_INET]213.152.188.73:1194
Sat Nov 12 00:32:06 2022 TLS: Initial packet from [AF_INET]213.152.188.73:1194, sid=82681cc2 2f26c813
Sat Nov 12 00:32:06 2022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Nov 12 00:32:06 2022 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Sat Nov 12 00:32:06 2022 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA7
Sat Nov 12 00:32:06 2022 VERIFY KU OK
Sat Nov 12 00:32:06 2022 Validating certificate extended key usage
Sat Nov 12 00:32:06 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Nov 12 00:32:06 2022 VERIFY EKU OK
Sat Nov 12 00:32:06 2022 VERIFY X509NAME OK: CN=nl925.nordvpn.com
Sat Nov 12 00:32:06 2022 VERIFY OK: depth=0, CN=nl925.nordvpn.com
Sat Nov 12 00:32:06 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
Sat Nov 12 00:32:06 2022 [nl925.nordvpn.com] Peer Connection Initiated with [AF_INET]213.152.188.73:1194
Sat Nov 12 00:32:07 2022 SENT CONTROL [nl925.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sat Nov 12 00:32:07 2022 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.8.2.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.2.4 255.255.255.0,peer-id 7,cipher AES-256-GCM'
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: timers and/or timeouts modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: explicit notify parm(s) modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: compression parms modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat Nov 12 00:32:07 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: --ifconfig/up options modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: route options modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: route-related options modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: peer-id set
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: adjusting link_mtu to 1657
Sat Nov 12 00:32:07 2022 OPTIONS IMPORT: data channel crypto options modified
Sat Nov 12 00:32:07 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Nov 12 00:32:07 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Nov 12 00:32:07 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Nov 12 00:32:07 2022 ROUTE_GATEWAY 192.168.56.254/255.255.255.0 IFACE=eth0 HWADDR=02:42:c0:a8:38:04
Sat Nov 12 00:32:07 2022 TUN/TAP device tun0 opened
Sat Nov 12 00:32:07 2022 TUN/TAP TX queue length set to 100
Sat Nov 12 00:32:07 2022 /sbin/ip link set dev tun0 up mtu 1500
Sat Nov 12 00:32:07 2022 /sbin/ip addr add dev tun0 10.8.2.4/24 broadcast 10.8.2.255
Sat Nov 12 00:32:07 2022 /sbin/ip route add 213.152.188.73/32 via 192.168.56.254
Error: Nexthop has invalid gateway.
Sat Nov 12 00:32:07 2022 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Nov 12 00:32:07 2022 /sbin/ip route add 0.0.0.0/1 via 10.8.2.1
Sat Nov 12 00:32:07 2022 /sbin/ip route add 128.0.0.0/1 via 10.8.2.1
Up script executed with device=tun0 ifconfig_local=10.8.2.4
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.8.2.4
-------------------------------------
Transmission will run as
-------------------------------------
User name: root
User uid: 0
User gid: 0
-------------------------------------
Updating Transmission settings.json with values from env variables
Attempting to use existing settings.json for Transmission
Successfully used existing settings.json /config/transmission-home/settings.json
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.8.2.4
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/completed
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete
Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED]
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
sed'ing True to true
STARTING TRANSMISSION
Executing /scripts/transmission-post-start.sh
/scripts/transmission-post-start.sh returned 0
Transmission startup script complete.
Sat Nov 12 00:32:08 2022 Initialization Sequence Completed
HW/SW Environment
- OS: Ubuntu 22.04.1 LTS - Docker: 20.10.21, build baeda1f
Anything else?
No response
I’ve got the same error. I had to downgrade to 4.0
Also experiencing this. Exactly the same setup as OP.
Edit: downgrading to 4.1 worked for me. 4.2 did not work — same error.
As for the others, 4.2 does not work for me. I confirm that downgrade to 4.1 also works on my side.
+1 on the issue and downgrade worked for me
I have the same issue. Downgrading to 4.1 also fixed it for me.
I have tested 4.3 and it is still not working.
same issue for me. Downgrade to 4.1 works.
same issue for me. Downgrade to 4.1 works.
Yes. 4.1 is the last functional version. 4.2 has broken and latest 4.3.2 still not working.
I wonder if it is a situation with only few people
Same issue here, 4.1 works but 4.2 and 4.3.2 are broken for me.
Hey guys and thanks for reporting this bug. I’ll try to have a look at this over the weekend. I’m also running on an Ubuntu host (20.04 though) and same docker version as OP so it’s a bit strange that I can’t reproduce it. But routes created here is depending on the config so I guess there can be provider differences.
Since it’s also failing in 4.2 that means that it’s not because of the upgrade to ubuntu base image 22.04 and newer OpenVPN and Transmission like #2410 is. That makes me assume that #2285 might be the culprit. Have to do another look through the changes between 4.1 and 4.2 if that’s not the case.
Just to support that hypothesis. Can you try running the container and just commenting out LOCAL_NETWORK
and see if it starts fine then? You won’t be able to connect to it of course, but you can see if the logs look good. Also you should be able to do something like:
➜ ~ docker exec -it openvpn bash -c "curl localhost:9091"
<h1>301: Moved Permanently</h1>
to see that Transmission is actually running in there.
Hey, Great to hear from you
I believe your hypothesis is right. I’ve commented LOCAL_NETWORK and «Nexthop has invalid gateway» message has gone and container started fine. I was able to see «
301: Moved Permanently
»
Hey, Great to hear from you
I believe your hypothesis is right. I’ve commented LOCAL_NETWORK and «Nexthop has invalid gateway» message has gone and container started fine. I was able to see «
301: Moved Permanently
«
I did some tests and:
my LOCAL_NETWORK env is like that: LOCAL_NETWORK=172.17.0.0/16, 192.168.86.0/24 (it doesn’t work)
If I invert addresses like this: LOCAL_NETWORK=192.168.86.0/24, 172.17.0.0/16 (it works)
I am also affected by this, tried things from FAQ, debug guide, tips and tricks to no avail. Downgrading to 4.1 works. Host OS is Ubuntu 22.04, docker-ce upgraded to latest.
4.3.2 doesn’t give the «Error: Nexthop has invalid gateway» message but 4.2 does. 4.3.2 instead prints:
transmission | 2022-12-09 17:44:33 sitnl_send: rtnl: generic error (-101): Network is unreachable
transmission | 2022-12-09 17:44:33 ERROR: Linux route add command failed
Here’s my docker-compose:
transmission:
cap_add:
- NET_ADMIN
image: haugene/transmission-openvpn:4.3.2
container_name: transmission
networks:
- mediacenter_network
environment:
- PUID=${MEDIA_USER}
- PGID=${MEDIA_GROUP}
- CREATE_TUN_DEVICE=true
- WEBPROXY_ENABLED=true
- WEBPROXY_PORT=8118
- LOCAL_NETWORK=192.168.0.0/16,172.24.0.0/24
- ADVERTISE_IP="http://192.168.6.3:32400/"
- OPENVPN_PROVIDER=WINDSCRIBE
- OPENVPN_CONFIG=SanJose-Santana-udp,SanFrancisco-Sanitation-udp,SantaClara-Inside-udp
- OPENVPN_USERNAME=${OPENVPN_USERNAME}
- OPENVPN_PASSWORD=${OPENVPN_PASSWORD}
- OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 --pull-filter ignore ping
- TRANSMISSION_INCOMPLETE_DIR=/downloads/transmission/downloads/incomplete
- TRANSMISSION_DOWNLOAD_DIR=/downloads/transmission/downloads/completed
- TRANSMISSION_WEB_UI=flood-for-transmission
volumes:
- /var/lib/media/apps/transmission:/config
- /var/lib/media/downloads:/downloads
- /var/lib/media/storage:/media
- /etc/localtime:/etc/localtime:ro
expose:
- "9091"
ports:
- 9091:9091
- 8118:8118
restart: unless-stopped
And here are the logs from starting the container:
transmission | Starting container with revision: 3a7320e5cc76a9fb8d478a3cfd6b44a1377d9ca7
transmission | Creating TUN device /dev/net/tun
transmission | Using OpenVPN provider: WINDSCRIBE
transmission | Running with VPN_CONFIG_SOURCE auto
transmission | No bundled config script found for WINDSCRIBE. Defaulting to external config
transmission | Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.Tf3lhvKN4O
transmission | Extracting configs to /tmp/tmp.uIMIRDjZ1T
transmission | Found configs for WINDSCRIBE in /tmp/tmp.uIMIRDjZ1T/vpn-configs-contrib-main/openvpn/windscribe, will replace current content in /etc/openvpn/windscribe
transmission | Cleanup: deleting /tmp/tmp.Tf3lhvKN4O and /tmp/tmp.uIMIRDjZ1T
transmission | 3 servers found in OPENVPN_CONFIG, SanJose-Santana-udp chosen randomly
transmission | Starting OpenVPN using config SanJose-Santana-udp.ovpn
transmission | Modifying /etc/openvpn/windscribe/SanJose-Santana-udp.ovpn for best behaviour in this container
transmission | Modification: Point auth-user-pass option to the username/password file
transmission | Modification: Change ca certificate path
transmission | Modification: Change ping options
transmission | Modification: Update/set resolv-retry to 15 seconds
transmission | Modification: Change tls-crypt keyfile path
transmission | Modification: Set output verbosity to 3
transmission | Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
transmission | Modification: Updating status for config failure detection
transmission | Setting OpenVPN credentials...
transmission | adding route to local network 192.168.0.0/16 via 172.24.0.1 dev eth0
transmission | adding route to local network 172.24.0.0/24 via 172.24.0.1 dev eth0
transmission | 2022-12-09 17:44:32 Note: Treating option '--ncp-ciphers' as '--data-ciphers' (renamed in OpenVPN 2.5).
transmission | 2022-12-09 17:44:32 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
transmission | 2022-12-09 17:44:32 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
transmission | 2022-12-09 17:44:32 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
transmission | 2022-12-09 17:44:32 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
transmission | 2022-12-09 17:44:32 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
transmission | 2022-12-09 17:44:32 TCP/UDP: Preserving recently used remote address: [AF_INET]66.115.165.227:1194
transmission | 2022-12-09 17:44:32 Socket Buffers: R=[212992->212992] S=[212992->212992]
transmission | 2022-12-09 17:44:32 UDP link local: (not bound)
transmission | 2022-12-09 17:44:32 UDP link remote: [AF_INET]66.115.165.227:1194
transmission | 2022-12-09 17:44:32 TLS: Initial packet from [AF_INET]66.115.165.227:1194, sid=3d2a3f1e 51165545
transmission | 2022-12-09 17:44:32 VERIFY OK: depth=2, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=Windscribe Node CA X1
transmission | 2022-12-09 17:44:32 VERIFY OK: depth=1, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=Windscribe Node CA X2
transmission | 2022-12-09 17:44:32 VERIFY KU OK
transmission | 2022-12-09 17:44:32 Validating certificate extended key usage
transmission | 2022-12-09 17:44:32 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
transmission | 2022-12-09 17:44:32 VERIFY EKU OK
transmission | 2022-12-09 17:44:32 VERIFY X509NAME OK: C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=sjc-337.windscribe.com
transmission | 2022-12-09 17:44:32 VERIFY OK: depth=0, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=sjc-337.windscribe.com
transmission | 2022-12-09 17:44:32 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
transmission | 2022-12-09 17:44:32 [sjc-337.windscribe.com] Peer Connection Initiated with [AF_INET]66.115.165.227:1194
transmission | 2022-12-09 17:44:33 SENT CONTROL [sjc-337.windscribe.com]: 'PUSH_REQUEST' (status=1)
transmission | 2022-12-09 17:44:33 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,rcvbuf 256000,sndbuf 256000,route-gateway 10.122.222.1,topology subnet,ping 5,ping-restart 60,dhcp-option DNS 10.255.255.3,ifconfig 10.122.222.10 255.255.254.0,peer-id 17,cipher AES-256-GCM'
transmission | 2022-12-09 17:44:33 Pushed option removed by filter: 'ping 5'
transmission | 2022-12-09 17:44:33 Pushed option removed by filter: 'ping-restart 60'
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
transmission | 2022-12-09 17:44:33 Socket Buffers: R=[212992->425984] S=[212992->425984]
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: --ifconfig/up options modified
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: route options modified
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: route-related options modified
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: peer-id set
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: adjusting link_mtu to 1624
transmission | 2022-12-09 17:44:33 OPTIONS IMPORT: data channel crypto options modified
transmission | 2022-12-09 17:44:33 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
transmission | 2022-12-09 17:44:33 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
transmission | 2022-12-09 17:44:33 net_route_v4_best_gw query: dst 0.0.0.0
transmission | 2022-12-09 17:44:33 net_route_v4_best_gw result: via 172.24.0.1 dev eth0
transmission | 2022-12-09 17:44:33 ROUTE_GATEWAY 172.24.0.1/255.255.255.0 IFACE=eth0 HWADDR=02:42:ac:18:00:11
transmission | 2022-12-09 17:44:33 TUN/TAP device tun0 opened
transmission | 2022-12-09 17:44:33 net_iface_mtu_set: mtu 1500 for tun0
transmission | 2022-12-09 17:44:33 net_iface_up: set tun0 up
transmission | 2022-12-09 17:44:33 net_addr_v4_add: 10.122.222.10/23 dev tun0
transmission | 2022-12-09 17:44:33 net_route_v4_add: 66.115.165.227/32 via 172.24.0.1 dev [NULL] table 0 metric -1
transmission | 2022-12-09 17:44:33 sitnl_send: rtnl: generic error (-101): Network is unreachable
transmission | 2022-12-09 17:44:33 ERROR: Linux route add command failed
transmission | 2022-12-09 17:44:33 net_route_v4_add: 0.0.0.0/1 via 10.122.222.1 dev [NULL] table 0 metric -1
transmission | 2022-12-09 17:44:33 net_route_v4_add: 128.0.0.0/1 via 10.122.222.1 dev [NULL] table 0 metric -1
transmission | Up script executed with device=tun0 ifconfig_local=10.122.222.10
transmission | Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.122.222.10
transmission | Using Flood for Transmission UI, overriding TRANSMISSION_WEB_HOME
transmission | TRANSMISSION_HOME is currently set to: /config/transmission-home
transmission | Enforcing ownership on transmission config directory
transmission | Applying permissions to transmission config directory
transmission | Setting owner for transmission paths to 1001:1001
transmission | Setting permissions for download and incomplete directories
transmission | Mask: 002
transmission | Directories: 775
transmission | Files: 664
transmission | Setting permission for watch directory (775) and its files (664)
transmission |
transmission | -------------------------------------
transmission | Transmission will run as
transmission | -------------------------------------
transmission | User name: abc
transmission | User uid: 1001
transmission | User gid: 1001
transmission | -------------------------------------
transmission |
transmission | Updating Transmission settings.json with values from env variables
transmission | Attempting to use existing settings.json for Transmission
transmission | Successfully used existing settings.json /config/transmission-home/settings.json
transmission | Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.122.222.10
transmission | Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /downloads/transmission/downloads/completed
transmission | Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /downloads/transmission/downloads/incomplete
transmission | Overriding ratio-limit because TRANSMISSION_RATIO_LIMIT is set to 0
transmission | Overriding ratio-limit-enabled because TRANSMISSION_RATIO_LIMIT_ENABLED is set to true
transmission | Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED]
transmission | Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
transmission | Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to
transmission | Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
transmission | sed'ing True to true
transmission | STARTING TRANSMISSION
transmission | Transmission startup script complete.
transmission | Privoxy: Starting
transmission | Privoxy: Using config file at /etc/privoxy/config
transmission | Privoxy: Setting port to 8118
transmission | Privoxy: Running as PID 110
transmission | 2022-12-09 17:44:35 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
transmission | 2022-12-09 17:44:35 Initialization Sequence Completed
#1 2018-12-29 12:35:14
- randomAbraham
- Member
- Registered: 2018-12-29
- Posts: 8
OpenVPN error : Error: Nexthop has invalid gateway.
sudo openvpn openvpn-tcp80.ovpn
Sat Dec 29 18:02:33 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Sat Dec 29 18:02:33 2018 library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10
Enter Auth Username: vpnbook
Enter Auth Password: *******
Sat Dec 29 18:02:42 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sat Dec 29 18:02:42 2018 NOTE: --fast-io is disabled since we are not using UDP
Sat Dec 29 18:02:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]37.187.158.97:80
Sat Dec 29 18:02:42 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
Sat Dec 29 18:02:42 2018 Attempting to establish TCP connection with [AF_INET]37.187.158.97:80 [nonblock]
Sat Dec 29 18:02:43 2018 TCP connection established with [AF_INET]37.187.158.97:80
Sat Dec 29 18:02:43 2018 TCP_CLIENT link local: (not bound)
Sat Dec 29 18:02:43 2018 TCP_CLIENT link remote: [AF_INET]37.187.158.97:80
Sat Dec 29 18:02:46 2018 TLS: Initial packet from [AF_INET]37.187.158.97:80, sid=7d13fd36 eeacb489
Sat Dec 29 18:02:46 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Dec 29 18:02:47 2018 VERIFY OK: depth=1, C=CH, ST=Zurich, L=Zurich, O=vpnbook.com, OU=IT, CN=vpnbook.com, name=vpnbook.com, emailAddress=admin@vpnbook.com
Sat Dec 29 18:02:47 2018 VERIFY OK: depth=0, C=CH, ST=Zurich, L=Zurich, O=vpnbook.com, OU=IT, CN=vpnbook.com, name=vpnbook.com, emailAddress=admin@vpnbook.com
Sat Dec 29 18:02:49 2018 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Sat Dec 29 18:02:49 2018 [vpnbook.com] Peer Connection Initiated with [AF_INET]37.187.158.97:80
Sat Dec 29 18:02:50 2018 SENT CONTROL [vpnbook.com]: 'PUSH_REQUEST' (status=1)
Sat Dec 29 18:02:51 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 213.186.33.99,dhcp-option DNS 91.239.100.100,route 10.12.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.12.0.254 10.12.0.253,peer-id 0,cipher AES-256-GCM'
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: timers and/or timeouts modified
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: route options modified
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: peer-id set
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: adjusting link_mtu to 1627
Sat Dec 29 18:02:51 2018 OPTIONS IMPORT: data channel crypto options modified
Sat Dec 29 18:02:51 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Dec 29 18:02:51 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Dec 29 18:02:51 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Dec 29 18:02:51 2018 ROUTE_GATEWAY 192.168.43.1/255.255.255.0 IFACE=wlp3s0 HWADDR=30:d1:6b:8c:13:5b
Sat Dec 29 18:02:51 2018 TUN/TAP device tun3 opened
Sat Dec 29 18:02:51 2018 TUN/TAP TX queue length set to 100
Sat Dec 29 18:02:51 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Dec 29 18:02:51 2018 /usr/bin/ip link set dev tun3 up mtu 1500
Sat Dec 29 18:02:51 2018 /usr/bin/ip addr add dev tun3 local 10.12.0.254 peer 10.12.0.253
Sat Dec 29 18:02:53 2018 /usr/bin/ip route add 37.187.158.97/32 via 192.168.43.1
Sat Dec 29 18:02:53 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.12.0.253
Error: Nexthop has invalid gateway.
Sat Dec 29 18:02:53 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Dec 29 18:02:53 2018 /usr/bin/ip route add 128.0.0.0/1 via 10.12.0.253
Error: Nexthop has invalid gateway.
Sat Dec 29 18:02:53 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Dec 29 18:02:53 2018 /usr/bin/ip route add 10.12.0.1/32 via 10.12.0.253
Error: Nexthop has invalid gateway.
Sat Dec 29 18:02:53 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Dec 29 18:02:53 2018 Initialization Sequence Completed
Error: Nexthop has invalid gateway.
How to fix this?
Last edited by randomAbraham (2018-12-30 05:30:22)
#2 2018-12-29 12:37:36
- graysky
- Wiki Maintainer
- From: :wq
- Registered: 2008-12-01
- Posts: 10,472
- Website
Re: OpenVPN error : Error: Nexthop has invalid gateway.
Did you google openvpn Error: Nexthop has invalid gateway?
#3 2018-12-29 12:50:15
- randomAbraham
- Member
- Registered: 2018-12-29
- Posts: 8
Re: OpenVPN error : Error: Nexthop has invalid gateway.
Yes, in those they were fixing files that didn’t exist in mine.
#4 2018-12-29 15:20:55
- randomAbraham
- Member
- Registered: 2018-12-29
- Posts: 8
Re: OpenVPN error : Error: Nexthop has invalid gateway.
On restarting,
it gets initialised but after a while this happens :
RTNETLINK answers: Cannot assign requested address
Sat Dec 29 22:09:23 2018 Linux ip addr del failed: external program exited with error status: 2
Sat Dec 29 22:09:24 2018 ROUTE_GATEWAY 192.168.43.1/255.255.255.0 IFACE=wlp3s0 HWADDR=30:d1:6b:8c:13:5b
Sat Dec 29 22:09:24 2018 TUN/TAP device tun0 opened
Sat Dec 29 22:09:24 2018 TUN/TAP TX queue length set to 100
Sat Dec 29 22:09:24 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Dec 29 22:09:24 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Sat Dec 29 22:09:24 2018 /usr/bin/ip addr add dev tun0 local 10.8.0.106 peer 10.8.0.105
Sat Dec 29 22:09:26 2018 /usr/bin/ip route add 192.99.37.222/32 via 192.168.43.1
Sat Dec 29 22:09:26 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.8.0.105
Error: Nexthop has invalid gateway.
Last edited by randomAbraham (2018-12-29 17:06:05)
#5 2018-12-29 22:54:11
- madman_xxx
- Member
- From: PL
- Registered: 2013-07-31
- Posts: 30
Re: OpenVPN error : Error: Nexthop has invalid gateway.
Hello,
randomAbraham wrote:
... Sat Dec 29 22:09:24 2018 /usr/bin/ip addr add dev tun0 local 10.8.0.106 peer 10.8.0.105 ...
I think that’s the problem right there. AFAIK ip addr add expects an IP with netmask, without it /32 is assumed. If such a mask is used, the peer is in fact unreachable (outside of /32) and adding any routes that point to it makes no sense. A mask of /31 would also be inappropriate:
$ ipcalc 10.8.0.106/31
Address: 10.8.0.106 00001010.00001000.00000000.0110101 0
Netmask: 255.255.255.254 = 31 11111111.11111111.11111111.1111111 0
Wildcard: 0.0.0.1 00000000.00000000.00000000.0000000 1
=>
Network: 10.8.0.106/31 00001010.00001000.00000000.0110101 0
HostMin: 10.8.0.106 00001010.00001000.00000000.0110101 0
HostMax: 10.8.0.107 00001010.00001000.00000000.0110101 1
Hosts/Net: 2 Class A, Private Internet, PtP Link RFC 3021
Either the addresses should be e.g. local 10.8.0.106 peer 10.8.0.107 or mask /30.
If you cannot change config on server side, you may just add the addresses manually.
AFAIK2 — Windows systems do not expose this behaviour.
#7 2018-12-30 05:33:48
- randomAbraham
- Member
- Registered: 2018-12-29
- Posts: 8
Re: OpenVPN error : Error: Nexthop has invalid gateway.
@madman_xxx
How do I manually add them?
@jasonwryan
Sorry for that, changed the title.
#8 2018-12-30 20:39:07
- madman_xxx
- Member
- From: PL
- Registered: 2013-07-31
- Posts: 30
Re: OpenVPN error : Error: Nexthop has invalid gateway.
randomAbraham wrote:
…
How do I manually add them?
…
The same way OpenVPN tries to do it (more less):
# Make a connection
openvpn openvpn-tcp80.ovpn
# Open another session
# Become root
sudo -i
# Remove existing, incorrect address
# nothing else than replacing 'add' keyword with 'del'
ip addr del dev tun3 local 10.12.0.254 peer 10.12.0.253
# add proper address
# this should be the same as seen in the connection log, netmask included
ip addr add dev tun3 local 10.12.0.254/30 peer 10.12.0.253
# add static routes - these should work by entering them without modifications:
ip route add 0.0.0.0/1 via 10.12.0.253
ip route add 128.0.0.0/1 via 10.12.0.253
Note: Make sure you use the correct addresses — I have used those from the log.
#9 2018-12-31 08:07:48
- randomAbraham
- Member
- Registered: 2018-12-29
- Posts: 8
Re: OpenVPN error : Error: Nexthop has invalid gateway.
This is what I got this time :
Mon Dec 31 13:35:09 2018 TUN/TAP device tun0 opened
Mon Dec 31 13:35:09 2018 TUN/TAP TX queue length set to 100
Mon Dec 31 13:35:09 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Dec 31 13:35:09 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Mon Dec 31 13:35:09 2018 /usr/bin/ip addr add dev tun0 local 10.8.0.106 peer 10.8.0.105
Mon Dec 31 13:35:12 2018 /usr/bin/ip route add 192.99.37.222/32 via 192.168.43.1
Mon Dec 31 13:35:12 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.8.0.105
Error: Nexthop has invalid gateway.
Mon Dec 31 13:35:12 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Mon Dec 31 13:35:12 2018 /usr/bin/ip route add 128.0.0.0/1 via 10.8.0.105
Error: Nexthop has invalid gateway.
Mon Dec 31 13:35:12 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Mon Dec 31 13:35:12 2018 /usr/bin/ip route add 10.8.0.1/32 via 10.8.0.105
Error: Nexthop has invalid gateway.
Mon Dec 31 13:35:12 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Mon Dec 31 13:35:12 2018 Initialization Sequence Completed
I tried
# ip addr del dev tun3 local 10.8.0.106 peer 10.8.0.105
Cannot find device "tun3"
I modified tun3 to tun0
# ip addr del dev tun0 local 10.8.0.106 peer 10.8.0.105
RTNETLINK answers: Cannot assign requested address
Are these the right addresses?
Last edited by randomAbraham (2018-12-31 08:08:24)
У меня есть собственный беспроводной маршрутизатор, к которому подключен удаленный клиент VPN, 10.7.0.6. Я хочу, чтобы трафик от одного из беспроводных клиентов проходил через него, но я получаю сообщение «Nexthop имеет неверный шлюз ». (Я знаю, что мне придется убедить 10.7.0.6 сыграть в мяч, но я думаю, что настоящая проблема возникает раньше.)
Это маршрутизатор, 10.0.0.1:
[ad@rout ~]$ ip addr
1: lo: ...
2: wlp0s20f0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:32:1b:06:18:1b brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global wlp0s20f0u1
valid_lft forever preferred_lft forever
...
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 10.7.0.1 peer 10.7.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
...
23: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 82.69.221.62 peer 62.3.89.162/32 scope global ppp0
valid_lft forever preferred_lft forever
[ad@rout ~]$ ip route
default dev ppp0 scope link
10.0.0.0/24 dev wlp0s20f0u1 proto kernel scope link src 10.0.0.1
10.7.0.0/24 via 10.7.0.2 dev tun0
10.7.0.2 dev tun0 proto kernel scope link src 10.7.0.1
62.3.89.162 dev ppp0 proto kernel scope link src 82.69.221.62
и это клиент, 10.0.0.2, прежде чем я начну возиться:
ad@blackmail:~$ ip addr
1: ...
2: ...
3: wls1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 60:57:18:43:12:fa brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global noprefixroute wls1
valid_lft forever preferred_lft forever
inet6 fe80::6257:18ff:fe43:12fa/64 scope link
valid_lft forever preferred_lft forever
ad@blackmail:~$ ip route
default via 10.0.0.1 dev wls1 proto dhcp src 10.0.0.2 metric 303 mtu 1492
10.0.0.0/24 dev wls1 proto dhcp scope link src 10.0.0.2 metric 303 mtu 1492
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
ad@blackmail:~$ ping google.com
PING google.com (216.58.198.238) 56(84) bytes of data.
64 bytes from lhr26s04-in-f238.1e100.net (216.58.198.238): icmp_seq=1 ttl=53 time=17.0 ms
ad@blackmail:~$ ping 10.7.0.6
PING 10.7.0.6 (10.7.0.6) 56(84) bytes of data.
64 bytes from 10.7.0.6: icmp_seq=1 ttl=63 time=626 ms
ad@blackmail:~$ traceroute 10.7.0.6
traceroute to 10.7.0.6 (10.7.0.6), 30 hops max, 60 byte packets
1 rout (10.0.0.1) 3.777 ms 5.372 ms 7.143 ms
2 10.7.0.6 (10.7.0.6) 153.924 ms 153.948 ms 153.999 ms
Теперь я пытаюсь заставить его пройти через 10.7.0.6:[12157 impressionWhy?
задан
10 February 2019 в 10:38
Ссылка
6 ответов
Адрес шлюза может находиться только в сети с прямым подключением. Сеть 10.7.0.0/24 не связана напрямую с вашим хостом 10.0.0.2, но вместо этого разделена другой сетью, которая подключена к хосту по адресу 10.0.0.1.
Вы должны использовать 10.0.0.1 в качестве шлюза для эта сеть и этот хост также должны быть настроены для маршрутизации пакетов желаемым образом.
ответ дан
3 December 2019 в 10:32
Ссылка
Я думаю, эта команда может решить вашу проблему:
ip route add default via 10.7.0.6 onlink
В этом случае мы считаем, что шлюз всегда подключен к сети.
ответ дан
3 December 2019 в 10:32
Ссылка
Я также столкнулся с проблемой, вам нужно
ip link set LINK_NAME up
знать, что если ссылка имеет зависимости от других ссылок, таких как пара veth, вам также необходимо включить их.
ответ дан osexp2003
14 January 2020 в 06:39
Ссылка
Возможно что-то вроде:
ip route add <gateway IP> dev <interface on which it should be reachable>
и тогда
ip route add default via <gateway ip>
«Прямое подключение» может быть частью моста уровня 2, как я обнаружил, очень полезно для назначение запасных общедоступных IP-адресов внутренним устройствам без необходимости прибегать к неприятностям и сложности NAT..
Ссылка
Я страдал от той же проблемы с туннелями OpenPVN и, наконец, решил, используя tap device вместо tun.
Я думаю, что сетевой уровень 2 обходит проблему, пытаясь маршрутизировать каждый пакет независимо от состояния интерфейса (не совсем уверен в этом, но в конечном итоге это работает).
Если вы используете OpenVPN, измените dev
в каждом конфигурационном файле ovpn(сервер и клиенты):
;dev tun
dev tap
Другие настройки, отличные от OpenVPN, должны быть решены по-другому (пожалуйста, прокомментируйте это здесь, если это также решено с помощью интерфейсов tap).
ответ дан caligari
5 March 2021 в 11:01
Ссылка