[Bug 256393] Issue with recreation of ppp/tun interfaces

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 03 Jun 2021 18:01:19 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256393

--- Comment #3 from Nathan Whitehorn <nwhitehorn@FreeBSD.org> ---
I at least found the proximate problem:

root@conference:/home/nwhitehorn # netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            128.135.X.X    UGS      vtnet0
127.0.0.1          link#2             UH          lo0
128.135.X.X/25 link#1             U        vtnet0
128.135.X.X    link#1             UHS         lo0
169.254.169.254    128.135.X.X    UGHS     vtnet0
192.168.42.1       127.0.0.1          UH          lo0  <- this is the IP that
the tunnel will use once established, and it didn't go away when the tunnel
interface did

If I delete the route to the tunnel endpoint on the loopback interface that
appeared:

root@conference:/home/nwhitehorn # route delete 192.168.42.1
delete host 192.168.42.1

Then the connection re-establishes itself without issue.

The route in question seems to have been added by routed(8), replacing the
link-level default route, though I am not sure why it is not going away when
routed(8) exits and the interface disappears or why routed(8) is re-writing it:


root@conference:/home/nwhitehorn # netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            128.135.X.X    UGS      vtnet0
127.0.0.1          link#2             UH          lo0
128.135.X.X/25 link#1             U        vtnet0
128.135.X.X    link#1             UHS         lo0
169.254.X.X    128.135.X.X    UGHS     vtnet0
192.168.42.0/24    192.168.42.2       UGS        tun0
192.168.42.1       link#3             UHS         lo0 <- Original loopback
route
192.168.42.2       link#3             UH         tun0
root@conference:/home/nwhitehorn # service routed start
Starting routed.
root@conference:/home/nwhitehorn # netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            128.135.X.X    UGS      vtnet0
10.7.114.0/24      192.168.42.2       UG         tun0
127.0.0.1          link#2             UH          lo0
128.135.X.X/25 link#1             U        vtnet0
128.135.X.X    link#1             UHS         lo0
157.132.6.8/29     192.168.42.2       UG         tun0
169.254.X.X    128.135.158.134    UGHS     vtnet0
192.168.1.0/24     192.168.42.2       UG         tun0
192.168.2.0/24     192.168.42.2       UG         tun0
192.168.3.0/24     192.168.42.2       UG         tun0
192.168.5.0/24     192.168.42.2       UG         tun0
192.168.42.0/24    192.168.42.2       UGS        tun0
192.168.42.1       127.0.0.1          UH          lo0 <- Rewritten by routed(8)
192.168.42.2       link#3             UH         tun0
192.168.176.0/24   192.168.42.2       UG         tun0

On the 12.2 system on the other end of this link, the same loopback host route
is present, but it doesn't seem to prevent re-IP'ing the link:

$ netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
192.168.42.1       link#5             UHS        tun0
192.168.42.2       127.0.0.1          UH          lo0

My suspicion is that the actual problem is that some of the routing-table
verification code that went in recently is preventing adding an IP address with
an address to which there is already a route on another interface.

-- 
You are receiving this mail because:
You are the assignee for the bug.