Nexthop has invalid gateway ошибка - Ремонт и установка крупной бытовой техники

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?

Источник

У меня есть собственный беспроводной маршрутизатор, к которому подключен удаленный клиент 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

Ссылка

Похожие вопросы

Источник

View previous topic :: View next topic Author Message Frautoincnam
Apprentice

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 3:50 am Post subject: [SOLVED] Nexthop has invalid gateway

hi,

I’m installing Gentoo on a VPS, and I have a network problem I don’t understand

My fixed IPv4 : AAA.BBB.219.143

Gateway : AAA.BBB.216.1

Here what I get when I use dhcp (but I’d like to not use dhcp and make fixed config as suggested on some forums of the VPS) :

Code:

$ ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet AAA.BBB.219.143 netmask 255.255.255.255 broadcast AAA.BBB.219.143

inet6 fe80::84b7:a6c1:9f41:498a prefixlen 64 scopeid 0x20<link>

ether fa:16:3e:77:ac:2a txqueuelen 1000 (Ethernet)

RX packets 2474 bytes 191990 (187.4 KiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1658 bytes 201270 (196.5 KiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Code:

ip route

Destination Passerelle Genmask Indic Metric Ref Use Iface

0.0.0.0 AAA.BBB.216.1 0.0.0.0 UG 2 0 0 eth0

AAA.BBB.216.1 0.0.0.0 255.255.255.255 UH 2 0 0 eth0

but with /etc/conf.d/net :

Code:

config_eth0=»AAA.BBB.219.143/32 brd AAA.BBB.219.143″

routes_eth0=»default via AAA.BBB.216.1″

when I restart net.eth0, I get this error :

Code:

* Bringing up interface eth0

* AAA.BBB.219.143/32 … [ ok ]

* Adding routes

* default via AAA.BBB.216.1 …

Error: Nexthop has invalid gateway. [ !! ]

But, if I manualy set routes like :

Code:

ip route add AAA.BBB.216.1 dev eth0

ip route add default via AAA.BBB.216.1

All is ok and works fine.

What do I need to put in my /etc/conf.d/net please ?

Last edited by Frautoincnam on Sat Apr 17, 2021 6:51 pm; edited 1 time in total

Joined: 08 Feb 2004
Posts: 190

Posted: Fri Apr 16, 2021 6:09 am Post subject:

A gateway address can only be on a directly connected network.

AAA.BBB.216.1/32 is not part of AAA.BBB.219.143/32 and for the local host not known yet which interface to use.

Try to incorporate your manual steps

Code:

routes_eth0=»AAA.BBB.216.1/32 dev eth0

default via AAA.BBB.216.1″

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 9:38 am Post subject:

Frautoincnam,

Normally the gateway is in the same subnet as your IP but

Code:

Destination Passerelle Genmask Indic Metric Ref Use Iface

0.0.0.0 AAA.BBB.216.1 0.0.0.0 UG 2 0 0 eth0

AAA.BBB.216.1 0.0.0.0 255.255.255.255 UH 2 0 0 eth0

says that your ‘subnet’ only has a single IP so your gateway is outside your subnet.

That’s your problem.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 17 Oct 2006
Posts: 2814
Location: Bavaria

Posted: Fri Apr 16, 2021 9:39 am Post subject: Re: Nexthop has invalid gateway

Frautoincnam wrote:

My fixed IPv4 : AAA.BBB.219.143

Gateway : AAA.BBB.216.1

If these addresses are correct you must do:

1. Read this chapter: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Networking#Understanding_network_terminology

2. to understand why you need a netmask of 255.255.252.0 (=128+64+32+16+8+4 = 6 bits)

216 = 128+64+0+16+8+0 + 0+0

219 = 128+64+0+16+8+0 + 2+1

Frautoincnam wrote:

What do I need to put in my /etc/conf.d/net please ?

Solution should be:

Frautoincnam wrote:

but with /etc/conf.d/net :

Code:

config_eth0=»AAA.BBB.219.143 netmask 255.255.252.0 brd AAA.BBB.219.255″

routes_eth0=»default via AAA.BBB.216.1″

P.S.: This is the same:

Code:

config_eth0=»AAA.BBB.219.143/22 brd AAA.BBB.219.255″

routes_eth0=»default via AAA.BBB.216.1″

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 11:43 am Post subject:

Frautoincnam, An OVH VPS by any chance? You need some of this or your netmask is incorrect. Your VPS provider will tell you more. _________________ Regards, NeddySeagoon Computer users fall into two groups:- those that do backups those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 2:36 pm Post subject:

@all: First, thanks a lot for your help.

user wrote:

A gateway address can only be on a directly connected network.

Code:

routes_eth0=»AAA.BBB.216.1/32 dev eth0

default via AAA.BBB.216.1″

doesn’t work :

Code:

Error: either «to» is duplicate, or «default» is a garbage. [ !! ]

*******************************************

NeddySeagoon wrote:

your ‘subnet’ only has a single IP so your gateway is outside your subnet.

I understood that

Quote:

That’s your problem.

But no choice.

Quote:

An OVH VPS by any chance?

Yes !

Quote:

You need some of this or your netmask is incorrect.

I’ll have a look

Quote:

Your VPS provider will tell you more.

OVH ? tell something ? Hmmmm

*******************************************

I promise I’ll read it again !

Quote:

2. to understand why you need a netmask of 255.255.252.0 (=128+64+32+16+8+4 = 6 bits)

My problem was here.

I tried AAA.BBB.219.143/22 but with «brb AAA.BBB.219.143», as I could see in the «ifconfig» from dhcp configuration.

Quote:

Code:

config_eth0=»AAA.BBB.219.143/22 brd AAA.BBB.219.255″

routes_eth0=»default via AAA.BBB.216.1″

Works !

But I dont have the same result with ifconfig (as with dhcp) :

Code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet AAA.BBB.219.143 netmask 255.255.252.0 broadcast AAA.BBB.219.255

ether fa:16:3e:77:ac:2a txqueuelen 1000 (Ethernet)

RX packets 1595576 bytes 124229157 (118.4 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1562326 bytes 4038241973 (3.7 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

and no IPV6.

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 2:55 pm Post subject:

Frautoincnam,

When I was with OVH they were absolutely hopeless and that’s being kind.

However, the user contributed documentation was OK.

You really only have a single IP so setting your netmask to anything other than 255.255.255.255 is not the right way to fix it.

You need a static route to your gateway, then the default rout will work as expected.

IPv6 is an entirely separate nest of vipers.

It can but does not normally use dhcp. Configuration is fairly automatic.

Do you hawe an IPv6 address that starts with a 2?

If not, you don’t have a public IP address.

Do you have a /64 or just a single IPv6 address?

The

Code:

inet6 fe80::84b7:a6c1:9f41:498a

you showed is only a local IP.

I don’t remember if its site local or link local but its not rotatable anyway.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 3:06 pm Post subject:

NeddySeagoon wrote:

Frautoincnam,

When I was with OVH they were absolutely hopeless and that’s being kind.

However, the user contributed documentation was OK.

I saw a lot of posts on their forums where VPS users say that OVH does not answer them on this subject, that the configuration of the VPS is not their responsibility.

Quote:

Si @pietinger is not a solution for me ?

Quote:

IPv6 is an entirely separate nest of vipers.

It can but does not normally use dhcp. Configuration is fairly automatic.

Ok. I don’t really know anything about IPV6.

Quote:

Do you hawe an IPv6 address that starts with a 2?

Yes ! 2001:41d0:XXX:YYY::ZZZZ

Quote:

Do you have a /64 or just a single IPv6 address?

I don’t really know.

But they give me a gateway IPV6 : 2001:41d0:XXX:YYY::1

Quote:

The

Code:

inet6 fe80::84b7:a6c1:9f41:498a

you showed is only a local IP.

I don’t remember if its site local or link local but its not rotatable anyway.

Ok.

Joined: 19 May 2017
Posts: 248

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 3:27 pm Post subject:

Frautoincnam,

It works for the wrong reasons.

If you want to try a static IPv6 setup, add it into the

Code:

routes_eth0=»AAA.BBB.216.1/32 dev eth0

default via AAA.BBB.216.1″

statements.

Code:

config_eth0=»192.168.122.104/24

2a01:4f8:x.y.z::8001/96″

routes_eth0=»default via 192.168.122.1

default via fe80::5054:ff:fe07:3867″

That’s from a KVM of on mine. Use your numbers, not mine

If you run

Code:

ping6 ff02::2 -I eth0

responses will all be from routers.

Pick one. There may only be one.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 5:36 pm Post subject:

NeddySeagoon wrote:

It works for the wrong reasons.

The only solution is to ask OVH so ?

Quote:

Code:

2a01:4f8:x.y.z::8001/96″

really with ::8001/96 ?

Or just MY own IPV6 I described as 2001:41d0:XXX:YYY::ZZZZ/96

I don’t know if your «x.y.z» is my «XXX.YYY.ZZZZ»

And /96 ? not /64 ?

Quote:

If you run

Code:

ping6 ff02::2 -I eth0

responses will all be from routers.

Pick one. There may only be one.

with «2001:41d0:XXX:YYY::ZZZZ/96»

I get :

Code:

# ping6 ff02::2 -I eth0

ping6: Warning: source address might be selected on device other than: eth0

PING ff02::2(ff02::2) from :: eth0: 56 octets de données

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=1 ttl=64 temps=0.292 ms

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=2 ttl=64 temps=0.174 ms

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=3 ttl=64 temps=0.136 ms

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=4 ttl=64 temps=0.237 ms

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=5 ttl=64 temps=0.135 ms

64 octets de 2001:41d0:XXX:YYY::1 : icmp_seq=6 ttl=64 temps=0.174 ms

^C

— statistiques ping ff02::2 —

6 paquets transmis, 6 reçus, 0% packet loss, time 5115ms

rtt min/avg/max/mdev = 0.135/0.191/0.292/0.056 ms

# ping6 google.com -I eth0

PING google.com(fra16s49-in-x0e.1e100.net (2a00:1450:4001:80f::200e)) from 2001:41d0:XXX:YYY::ZZZZ eth0: 56 octets de données

64 octets de fra07s64-in-x200e.1e100.net (2a00:1450:4001:80f::200e) : icmp_seq=1 ttl=111 temps=12.9 ms

64 octets de fra07s64-in-x200e.1e100.net (2a00:1450:4001:80f::200e) : icmp_seq=2 ttl=111 temps=11.4 ms

64 octets de fra07s64-in-x200e.1e100.net (2a00:1450:4001:80f::200e) : icmp_seq=3 ttl=111 temps=11.4 ms

64 octets de fra16s49-in-x0e.1e100.net (2a00:1450:4001:80f::200e) : icmp_seq=4 ttl=111 temps=11.4 ms

^C

— statistiques ping google.com —

4 paquets transmis, 4 reçus, 0% packet loss, time 3005ms

rtt min/avg/max/mdev = 11.397/11.786/12.910/0.648 ms

Is it ok ?

Last edited by Frautoincnam on Sat Apr 17, 2021 3:18 pm; edited 1 time in total

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 5:42 pm Post subject:

Frautoincnam, Use whatever OVH gave you. I was only showing the syntax. I have a heztner server that has one IPv4 address and a /64 IPv6 subnet. The /64 is subnetted to the KVMs. A /96 each is plenty. _________________ Regards, NeddySeagoon Computer users fall into two groups:- those that do backups those that have never had a hard drive fail.

Joined: 17 Oct 2006
Posts: 2814
Location: Bavaria

Posted: Fri Apr 16, 2021 5:47 pm Post subject:

Frautoincnam wrote:

Si @pietinger is not a solution for me ?

Yes, it is not a solution for you.

In case of doubt the answer is always: Trust Neddy …

… because even a network specialist can be wrong. I thought your netmask (/32) is a typo, because /22 would be generally the correct answer for your problem. But not in your special case. You must know: A network mask with all bits set (/32 = 255.255.255.255) means: There is no network (or: you are the network :-) ). Your host is then only able to talk with a specified router. This will be done usually for telephones, network TVs … and in some cases for a vpn (or for point-to-point-connections; there is also an old Windows solution). I dont know OVH and the last time I played with a VPNs is many years. If Neddy knows OVH he surely can help you further.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 7:38 pm Post subject:

Frautoincnam wrote:

Ok. I’ll ask OVH.

But, I realize that I can»t ask them, because that’s a real problem of configuration.

Because with :

Code:

config_eth0=»AAA.BBB.219.143/32 brd AAA.BBB.219.143″

I can set routes with :

Code:

ip route add AAA.BBB.216.1 dev eth0

ip route add default via AAA.BBB.216.1

And I have my 255.255.255.255 mask.

The problem is to add this in my configuration.

So, now, I have

Code:

dns_domain_lo=»vps.ovh.net»

dns_servers_eth0=»1.1.1.2 213.186.33.99″

dns_domain_eth0=»vps.ovh.net»

dns_search_eth0=»vps.ovh.net»

config_eth0=» AAA.BBB.219.143/32 brd AAA.BBB.219.143

2001:41d0:XXX:YYY::ZZZZ/96″

routes_eth0=» default via 2001:41d0:XXX:YYY::1″

postup() {

if [ «${IFACE}» = «eth0» ] ; then

ip route add AAA.BBB.216.1 dev eth0

ip route add default via AAA.BBB.216.1

fi

}

And it seems to be nice.

Code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet AAA.BBB.219.143 netmask 255.255.255.255 broadcast AAA.BBB.219.143

inet6 2001:41d0:XXX:YYY::ZZZZ prefixlen 96 scopeid 0x0<global>

ether fa:16:3e:77:ac:2a txqueuelen 1000 (Ethernet)

RX packets 1627248 bytes 126445339 (120.5 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1592728 bytes 4062876885 (3.7 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I hope you’ll confirm.

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 8:05 pm Post subject:

Frautoincnam,

Code:

2001:41d0:XXX:YYY::ZZZZ/96

is unlikely to be correct.

OVH will have allocated you a /64 or more likely a /128, just a single address.

The

Code:

postup() {

if [ «${IFACE}» = «eth0» ] ; then

ip route add AAA.BBB.216.1 dev eth0

ip route add default via AAA.BBB.216.1

fi

}

is not required. It can all be written in

Code:

routes_eth0=» default via 2001:41d0:XXX:YYY::1″

I’m not sure how though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 9:07 pm Post subject:

Frautoincnam,

This page says you have a /128, if your VPS is on that page.

You will need to do the same host route thing as IPv4 needs to set in up properly.

Wild guess … you need a host route. As it goes to exactly one host, not a network, its a /32

Code:

routes_eth0=» default via 2001:41d0:XXX:YYY::1

AAA.BBB.216.1/32

default via AAA.BBB.216.1

The AAA.BBB.216.1/32 host route must be set before the default route or the kernel will net be able to reach the next hop.

I can’t test easily as as I don’t have a setup like that.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 9:34 pm Post subject:

NeddySeagoon wrote:

This page says you have a /128, if your VPS is on that page.

Mine is «Starter». Not in the «compare» page. I’m not able to find details about it.

Quote:

You will need to do the same host route thing as IPv4 needs to set in up properly.

I don’t really understand what you mean here.

Quote:

Code:

routes_eth0=» default via 2001:41d0:XXX:YYY::1

AAA.BBB.216.1/32

default via AAA.BBB.216.1

The AAA.BBB.216.1/32 host route must be set before the default route or the kernel will net be able to reach the next hop.

Ok !

Quote:

I can’t test easily as as I don’t have a setup like that.

It seems to be ok for me.

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Fri Apr 16, 2021 9:49 pm Post subject:

Frautoincnam,

All the VPS on the compare page have

Code:

IPv4 address 1

IPv6 address /128

or one of each.

The starter VPS is lower cost, so it will not be any better.

Ahh, it’s here and its the same in the connectivity department.

— edit —

Your IPv6 needs the same thing. For IPv6 a host route is /128, not /32
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Fri Apr 16, 2021 11:58 pm Post subject:

NeddySeagoon wrote:

All the VPS on the compare page have

Code:

IPv4 address 1

IPv6 address /128

or one of each.

with /128, I get :

Code:

RTNETLINK answers: No route to host [ !! ]

and no error with /64.

Quote:

The starter VPS is lower cost, so it will not be any better.

/64 is better than /128 ?

Quote:

Your IPv6 needs the same thing. For IPv6 a host route is /128, not /32

Surely because of my bad english, it’s not better.

You suggest me to make some other modification in my actual config ?

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Sat Apr 17, 2021 11:13 am Post subject:

Frautoincnam,

To make IPv4 work correctly, you need a host route to your IPv4 gateway, so that the default route can work.

That’s the

Code:

routes_eth0=»

AAA.BBB.216.1/32

default via AAA.BBB.216.1

As you have only one IPv6 address, you need the same thing.

Code:

routes_eth0=» 2001:41d0:XXX:YYY::1/128

default via 2001:41d0:XXX:YYY::1

An IPv4 address consists of 32 bits, hence the /32

An IPv6 address is 128 bits, hence the /128. Both say to reach a single host.

Putting it together in a single statement.

Code:

routes_eth0=» 2001:41d0:XXX:YYY::1/128

default via 2001:41d0:XXX:YYY::1

AAA.BBB.216.1/32

default via AAA.BBB.216.1

The host routes must appear before the default route that uses the host route. Other than that, ordering is not imporrtant.

As you have single IP addresses, your system does not belong to any subnet.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Sat Apr 17, 2021 3:17 pm Post subject:

NeddySeagoon wrote:

Code:

routes_eth0=» 2001:41d0:XXX:YYY::1/128

default via 2001:41d0:XXX:YYY::1

AAA.BBB.216.1/32

default via AAA.BBB.216.1

Ok, it’s much clearer now. Sorry for being so «heavy».

Code:

* Bringing up interface eth0

* AAA.BBB.219.143/32 … [ ok ]

* 2001:41d0:XXX:YYY::ZZZZ/64 … [ ok ]

* Adding routes

* 2001:41d0:XXX:YYY::1/128 … [ ok ]

* default via 2001:41d0:XXX:YYY::1 … [ ok ]

* AAA.BBB.216.1/32 … [ ok ]

* default via AAA.BBB.216.1 … [ ok ]

* Waiting for tentative IPv6 addresses to complete DAD (5 seconds) .. [ ok ]

Code:

# ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet AAA.BBB.219.143 netmask 255.255.255.255 broadcast AAA.BBB.219.143

inet6 2001:41d0:XXX:YYY::ZZZZ prefixlen 64 scopeid 0x0<global>

inet6 fe80::f816:3eff:fe77:ac2a prefixlen 64 scopeid 0x20<link>

ether fa:16:3e:77:ac:2a txqueuelen 1000 (Ethernet)

RX packets 1187965 bytes 82903199 (79.0 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1182202 bytes 3075588337 (2.8 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# ip -6 route

2001:41d0:XXX:YYY::1 dev eth0 metric 2 pref medium

2001:41d0:XXX:YYY::/64 dev eth0 proto kernel metric 256 pref medium

fe80::/64 dev eth0 proto kernel metric 256 pref medium

multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium

default via 2001:41d0:XXX:YYY::1 dev eth0 metric 2 pref medium

# route -6 -n

Table de routage IPv6 du noyau

Destination Next Hop Flag Met Ref Use If

::1/128 :: Un 0 4 0 lo

2001:41d0:XXX:YYY::1/128 :: U 2 2 0 eth0

2001:41d0:XXX:YYY::ZZZZ/128 :: Un 0 2 0 eth0

2001:41d0:XXX:YYY::/64 :: U 256 1 0 eth0

fe80::f816:3eff:fe77:ac2a/128 :: Un 0 2 0 eth0

fe80::/64 :: U 256 1 0 eth0

ff00::/8 :: U 256 2 0 eth0

::/0 2001:41d0:XXX:YYY::1 UG 2 1 0 eth0

Does all this seem normal to you?

Joined: 05 Jul 2003
Posts: 52692
Location: 56N 3W

Posted: Sat Apr 17, 2021 3:47 pm Post subject:

Frautoincnam,

Not everyone’s first language is English and I try to point the way rather than say «do this».

You are not being heavy. Teaching fishing means I point the way too far ahead on some occasions.

Where does the

Code:

2001:41d0:XXX:YYY::/64 dev eth0 proto kernel metric 256 pref medium

come from?

I would not expect to see that but its possible that OVH’s router does that.

If its not coming out of your net file its OK.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-

those that do backups

those that have never had a hard drive fail.

Joined: 19 May 2017
Posts: 248

Posted: Sat Apr 17, 2021 4:42 pm Post subject:

NeddySeagoon wrote:

Not everyone’s first language is English and I try to point the way rather than say «do this».

You are not being heavy. Teaching fishing means I point the way too far ahead on some occasions.

You’re right. I aggree with all of that, of course. And I like learning. But sometime, it’s embarassing to ask, ask and ask…

Quote:

Where does the

Code:

2001:41d0:XXX:YYY::/64 dev eth0 proto kernel metric 256 pref medium

come from?

Of course from my config

I modified like (nothing else in) /etc/conf.d/net (/64 to /128):

Code:

dns_servers_eth0=»1.1.1.2 213.186.33.99″

dns_domain=»mydomain»

dns_search=»mydomain»

config_eth0=» AAA.BBB.219.143/32 brd AAA.BBB.219.143

2001:41d0:XXX:YYY::ZZZZ/128″

routes_eth0=» 2001:41d0:XXX:YYY::1/128

default via 2001:41d0:XXX:YYY::1

AAA.BBB.216.1/32

default via AAA.BBB.216.1″

Quote:

I would not expect to see that but its possible that OVH’s router does that.

If its not coming out of your net file its OK.

Code:

# ifconfig eth0 | anonyme

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet AAA.BBB.219.143 netmask 255.255.255.255 broadcast AAA.BBB.219.143

inet6 2001:41d0:XXX:YYY::ZZZZ prefixlen 128 scopeid 0x0<global>

inet6 fe80::f816:3eff:fe77:ac2a prefixlen 64 scopeid 0x20<link>

ether fa:16:3e:77:ac:2a txqueuelen 1000 (Ethernet)

RX packets 1197619 bytes 83608442 (79.7 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1189537 bytes 3077120396 (2.8 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# route -6 -n | anonyme

Table de routage IPv6 du noyau

Destination Next Hop Flag Met Ref Use If

::1/128 :: Un 0 4 0 lo

2001:41d0:XXX:YYY::1/128 :: U 2 1 0 eth0

2001:41d0:XXX:YYY::ZZZZ/128 :: Un 0 3 0 eth0

2001:41d0:XXX:YYY::ZZZZ/128 :: U 256 2 0 eth0

fe80::f816:3eff:fe77:ac2a/128 :: Un 0 3 0 eth0

fe80::/64 :: U 256 1 0 eth0

ff00::/8 :: U 256 2 0 eth0

::/0 2001:41d0:XXX:YYY::1 UG 2 2 0 eth0

# ip -6 route | anonyme

2001:41d0:XXX:YYY::1 dev eth0 metric 2 pref medium

2001:41d0:XXX:YYY::ZZZZ dev eth0 proto kernel metric 256 pref medium

fe80::/64 dev eth0 proto kernel metric 256 pref medium

multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium

default via 2001:41d0:XXX:YYY::1 dev eth0 metric 2 pref medium

Better now ?

Display posts from previous:

Источник

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?

Это маршрутизатор, 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 ответов

ответ дан
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

ответ дан 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>

Ссылка

Я страдал от той же проблемы с туннелями OpenPVN и, наконец, решил, используя tap device вместо tun.

Если вы используете OpenVPN, измените devв каждом конфигурационном файле ovpn(сервер и клиенты):

;dev tun
dev tap

ответ дан caligari
5 March 2021 в 11:01

Ссылка

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

I am trying to route some traffic over a VPN (to certain IPs) and other via my normal connection. To do this I am trying to add a static route to make traffic to some IPs bypass the VPN tunnel.

Very strangely it seems to work for some IPs and not for others giving the Error: Nexthop has invalid gateway.

So This works:

root@ubuntu:~# ip r add 193.27.14.179/32 via 127.31.1.1 dev eth0
root@ubuntu:~# ip r
default via 172.31.1.1 dev eth0 proto dhcp src 49.12.189.197 metric 100 
172.31.1.1 dev eth0 proto dhcp scope link src 49.12.189.197 metric 100 
193.27.14.179 via 172.31.1.1 dev eth0

This doesn’t work:

root@ubuntu:~# ip r add 168.119.56.29/32 via 127.31.1.1 dev eth0
Error: Nexthop has invalid gateway.

So what is going on.. I would appreciate any advises or comments!

root@ubuntu:~# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    100    0        0 eth0
172.31.1.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
193.27.14.179   172.31.1.1      255.255.255.255 UGH   0      0        0 eth0
root@ubuntu:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
root@ubuntu:~# ip r show table local
local 49.12.189.197 dev eth0 proto kernel scope host src 49.12.189.197 
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
root@ubuntu:~# ip r show table main
default via 172.31.1.1 dev eth0 proto dhcp src 49.12.189.197 metric 100 
172.31.1.1 dev eth0 proto dhcp scope link src 49.12.189.197 metric 100 
193.27.14.179 via 172.31.1.1 dev eth0 
root@ubuntu:~# ip r show table default
Error: ipv4: FIB table does not exist.
Dump terminated
root@ubuntu:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

I am trying to route some traffic over a VPN (to certain IPs) and other via my normal connection. To do this I am trying to add a static route to make traffic to some IPs bypass the VPN tunnel.

Very strangely it seems to work for some IPs and not for others giving the Error: Nexthop has invalid gateway.

So This works:

root@ubuntu:~# ip r add 193.27.14.179/32 via 127.31.1.1 dev eth0
root@ubuntu:~# ip r
default via 172.31.1.1 dev eth0 proto dhcp src 49.12.189.197 metric 100 
172.31.1.1 dev eth0 proto dhcp scope link src 49.12.189.197 metric 100 
193.27.14.179 via 172.31.1.1 dev eth0

This doesn’t work:

root@ubuntu:~# ip r add 168.119.56.29/32 via 127.31.1.1 dev eth0
Error: Nexthop has invalid gateway.

So what is going on.. I would appreciate any advises or comments!

root@ubuntu:~# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    100    0        0 eth0
172.31.1.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
193.27.14.179   172.31.1.1      255.255.255.255 UGH   0      0        0 eth0
root@ubuntu:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
root@ubuntu:~# ip r show table local
local 49.12.189.197 dev eth0 proto kernel scope host src 49.12.189.197 
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
root@ubuntu:~# ip r show table main
default via 172.31.1.1 dev eth0 proto dhcp src 49.12.189.197 metric 100 
172.31.1.1 dev eth0 proto dhcp scope link src 49.12.189.197 metric 100 
193.27.14.179 via 172.31.1.1 dev eth0 
root@ubuntu:~# ip r show table default
Error: ipv4: FIB table does not exist.
Dump terminated
root@ubuntu:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Содержание

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

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?

Источник

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?

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

SERVER A — ip a on vpn server (to this i am connecting from other server)

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)

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»

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.

➜  ~ 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

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:

And here are the logs from starting the container:

Did you manage to get this working again got the same error?

according to logs dev is null. Restarting container with env var DEBUG=True, you could have more information about the error.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale
bot

added
the

inactivity

Used by Stale bot to mark issues that will be closed

label

May 21, 2023

Feel free to re-open this issue if you think it deserves another look.

Источник

Теги

Похожие вопросы

Теги

Похожие вопросы

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

Current Behavior

Expected Behavior

How have you tried to solve the problem?

Log output

HW/SW Environment

Anything else?

301: Moved Permanently

301: Moved Permanently

OpenVPN Support Forum

ip addr add not taking effect

ip addr add not taking effect

Why «Nexthop has invalid gateway» when it seems to be defined?

6 Answers 6

Error: Nexthop has invalid gateway. #828

Routing through a router which is in another network – “Error: Nexthop has invalid gateway.”

1 Answer 1

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

Current Behavior

Expected Behavior

How have you tried to solve the problem?

Log output

HW/SW Environment

Anything else?

301: Moved Permanently

301: Moved Permanently