Network routes?
Knute Johnson
groups at knutejohnson.com
Mon Jun 12 22:29:15 UTC 2023
Karl:
Answering your post helped me solve my problem, you can go to the end of
this post and skip the rest if you wish. Thanks very much for the assist.
knute...
On 6/12/23 08:47, Karl Auer wrote:
> On Mon, 2023-06-12 at 08:17 -0500, Knute Johnson via ubuntu-users
> wrote:
>> I'm running NetworkManager and when I go to edit that connection and
>> put in a route for the networks that are reachable through the
>> 172.0.10.1 router it doesn't work. If I put a route in on the
>> command line:
>>>
>>> ip route add 172.0.0.0/11 via 172.0.10.1 dev xxxx metric 1
>
> I've set up routes in Network Manager that have worked.
>
> Are your NICs wireless or wired?
>
> Be a bit more specific about "doesn't work". Does the route appear in
> the route table ("ip route show")? What happens when you ping the other
> side of the link to the VPN hardware - do you get a timeout, network
> unreachable, or something else? Does the entry in NetworkManager
> "stick", or does it disappear after ten minutes or so? What exact
> values are you putting in the four boxes for the NetworkManager route?
> And why "/11"? that's an odd prefix length. I guess it's correct if it
> works, but it's odd. It's wrong if you were aiming for RFC1918
> addressing, though (should be e.g. 172.16.0.0/12). Does it match the
> network address and prefix length on the VPN device's interface?
>
> I have found that with Network Manager I need to reconnect in order for
> new things to take effect. Your CLI route command would take immediate
> effect though.
>
> You might like to investigate nmcli, too.
>
> Regards, K.
>
Karl:
Answering your post helped me solve my problem, you can go to the end of
this post and skip the rest if you wish. Thanks very much for the assist.
knute...
On 6/12/23 08:47, Karl Auer wrote:
> On Mon, 2023-06-12 at 08:17 -0500, Knute Johnson via ubuntu-users
> wrote:
>> I'm running NetworkManager and when I go to edit that connection and
>> put in a route for the networks that are reachable through the
>> 172.0.10.1 router it doesn't work. If I put a route in on the
>> command line:
>>>
>>> ip route add 172.0.0.0/11 via 172.0.10.1 dev xxxx metric 1
>
> I've set up routes in Network Manager that have worked.
>
> Are your NICs wireless or wired?
>
> Be a bit more specific about "doesn't work". Does the route appear in
> the route table ("ip route show")? What happens when you ping the other
> side of the link to the VPN hardware - do you get a timeout, network
> unreachable, or something else? Does the entry in NetworkManager
> "stick", or does it disappear after ten minutes or so? What exact
> values are you putting in the four boxes for the NetworkManager route?
> And why "/11"? that's an odd prefix length. I guess it's correct if it
> works, but it's odd. It's wrong if you were aiming for RFC1918
> addressing, though (should be e.g. 172.16.0.0/12). Does it match the
> network address and prefix length on the VPN device's interface?
>
> I have found that with Network Manager I need to reconnect in order for
> new things to take effect. Your CLI route command would take immediate
> effect though.
>
> You might like to investigate nmcli, too.
>
> Regards, K.
>
Karl, thanks for the response.
> Are your NICs wireless or wired?
Wired. One is the onboard NIC, that's the local LAN and the other is a
USB NIC, that one is connected to the hardware encrypted tunnel box.
> Be a bit more specific about "doesn't work".
Nothing, just hangs. Maybe it would time out but I'm too impatient.
> Does the entry in NetworkManager
> "stick", or does it disappear after ten minutes or so?
Yes.
> And why "/11"? that's an odd prefix length. I guess it's correct if it
> works, but it's odd. It's wrong if you were aiming for RFC1918
> addressing, though (should be e.g. 172.16.0.0/12). Does it match the
> network address and prefix length on the VPN device's interface?
Somebody decided (not me) that they know better and we are using
172.0.0.0 to 172.31.255.255. The only reason we are stopping at
172.31.255.255 is that I pitched a fit because our internet access has
to go out through those addresses too and I didn't want to lose any more
wild addresses. There are some other addressing issues too but they
pale in comparison.
> You might like to investigate nmcli, too.
Thanks, I'll do that.
The 172.0.10.0/24 dev exx7cc2c648d5b6 proto kernel scope link src route
comes from the encrypted tunnel box via DHCP. Here I add the route:
knute at knute-XPS-8700:~$ sudo ip r add 172.0.0.0/11 via 172.0.10.1
knute at knute-XPS-8700:~$ ip r
default via 192.168.10.1 dev enp3s0 proto dhcp src 192.168.10.104 metric 100
169.254.0.0/16 dev enp3s0 scope link metric 1000
172.0.0.0/11 via 172.0.10.1 dev enx7cc2c648d5b6
172.0.10.0/24 dev enx7cc2c648d5b6 proto kernel scope link src
172.0.10.26 metric 101
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.104
metric 100
I can now reach all the devices in the 172.0.0.0/11 network.
knute at knute-XPS-8700:~$ traceroute 172.26.10.101
traceroute to 172.26.10.101 (172.26.10.101), 64 hops max
1 172.0.10.1 94.564ms 122.914ms 79.807ms
2 xxx.xx.x.x 94.237ms 100.712ms 99.280ms
3 172.26.10.101 115.325ms 105.369ms 115.685ms
But when I reboot the computer this happens:
knute at knute-XPS-8700:~$ ip r
default via 192.168.10.1 dev enp3s0 proto dhcp src 192.168.10.104 metric 100
default via 172.0.10.1 dev enx7cc2c648d5b6 proto dhcp src 172.0.10.26
metric 101
169.254.0.0/16 dev enp3s0 scope link metric 1000
172.0.10.0/24 dev enx7cc2c648d5b6 proto kernel scope link src
172.0.10.26 metric 101
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.104
metric 100
and I can no longer reach any of the network other than the
172.0.10.0/24 addresses. That's problem number 1.
So I took that route out and rebooted the computer. I then added the
route with the NetworkManager GUI. But after going through the steps
above to explain I saw that I hadn't turned off the Default checkbox nor
checked the Multicast box in the setup GUI and when I did it all worked.
Now I don't know why the route entered with ip route doesn't stay
between reboots but I'm less concerned now that I have it working using
NetworkManager.
After a reboot:
knute at knute-XPS-8700:~$ ip r
default via 192.168.10.1 dev enp3s0 proto dhcp src 192.168.10.104 metric 100
169.254.0.0/16 dev enp3s0 scope link metric 1000
172.0.0.0/11 via 172.0.10.1 dev enx7cc2c648d5b6 proto static metric 101
172.0.10.0/24 dev enx7cc2c648d5b6 proto kernel scope link src
172.0.10.26 metric 101
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.104
metric 100
Perfect!
PS:
There is a 40k limit on post size so I couldn't post the two images of
the NetworkManager GUI. They are located here:
https://knutejohnson.com/test/1.jpg
https://knutejohnson.com/test/2.jpg
--
Knute Johnson
More information about the ubuntu-users
mailing list