ipv6 gif tunnel loses v4 tunnel mapping after wan interface is reinitialized by dhclient

[ultramage]

I use a gif tunnel to he.net to get ipv6 connectivity. I placed the tunnel setup commands from their guide into a rc script that runs at startup. It works fine, however when the host's modem reboots and dhclient refreshes the interface, ipv6 connectivity is lost. The reason is because something removes tunnel inet [wan ipv4] --> [he ipv4] property from the gif0 interface. All other properties, such as the v6 ip, gateway, prefix and route, remain intact. This seems to be the same issue as https://forums.freebsd.org/threads/gif-4-tcp-ipv6-routing-after-service-netif-restart.84126/ from a year ago.

The issue can be tested by pinging gif0's ipv6 gateway from gif0's v6 ip. It will report ping6: bind: Can't assign requested address. Trying to use the primary ipv6 address assigned by the tunnel broker results in ping6: UDP connect: No route to host.

I have done an experiment where I created a dummy lo1 interface with some ipv4 address, then created a gif1 interface that tunnels from lo1 to somewhere. Then I destroyed lo1. ifconfig showed that the tunnel was still configured on gif1, even though the ipv4 address, and even the interface it was configured on, were gone. This is what I was expecting to happen. Therefore, either dhclient or some related rc script is deliberately cleaning the tunnel up. This is unhelpful, both because it is being done even if there's no change to the wan ip address (alternatively, it's not restoring the tunnel), and because a change of wan ip requires an account update on the other side, which is best left to an user script.

Could you help me properly understand what's going on, and what would be the proper way to fix this behavior? It is possible that my configuration is incorrect or incomplete, and/or that there is builtin logic that I need to know about.

 

[SirDice]

I placed the tunnel setup commands from their guide into a rc script that runs at startup.

Don't need to. You can use the regular rc.conf for it. I've used a tunnel broker from HE for many, many years. Let me dig up my settings.

cloned_interfaces="gif0"
create_args_gif0="tunnel <yourIPv4> <IPv4tunnel>"
ifconfig_gif0_ipv6="inet6 <IPv6tunneladdress> <IPv6tunnel_end> prefixlen 128"
ipv6_defaultrouter="-iface gif0"

Tunnel remained "active" even when my IPv4 uplink crapped out. And by "active" I mean the tunnel configuration was still there but obviously can't send anything any more. It automagically started working again when the ISP connection came back up. Very rarely did I have to restart the gif0 interface or the IPv6 default route.

 

[ultramage]

Mine also includes an alias for the lan interface, to operate the /64 subnet assigned to me. Probably could be worked in too. I opted to write its own rc script, so that all the shenanigans could be contained, plus I originally planned to extend it to handle interface up/down events, respond to dynamic IP changes by updating the broker, etc, but there wasn't really the need to be fancy since my ip changes like once in a decade.

By "uplink crapped out", do you mean a network outage, or the link actually powering down? Because the setup doesn't have a problem if something along the route breaks. It's the direct ethernet link to the modem going down that messed things up, since it caused an interface down/up event and activated dhclient in some sort of forced reinitialization mode.

And I'm still curious about knowing what exactly is causing my issue.

 

[SirDice]

Mine also includes an alias for the lan interface, to operate the /64 subnet assigned to me.

Yes. I left that one out. It was just something like:

ifconfig_em0.10_ipv6="inet6 2001:<rest of your assigned prefix>::1 prefixlen 64"

With em0.10 being the internal interface on my firewall. It was connected to my internal LAN. Then ran rtadvd(8) to provide SLAAC for my internal hosts.

By "uplink crapped out", do you mean a network outage, or the link actually powering down?

Both. I had a cable modem in bridge mode directly connected to my firewall. That way I could simply use ifconfig_em1="SYNCDHCP" and get my internet IP address directly on the firewall. That was the main reason I had to use the HE tunnel broker because the ISP only supported IPv6 if the modem was in 'router' mode. Quite annoying.