On Sun, Dec 14, 2025 at 10:30:12AM -0700, Brook Milligan wrote: > I am trying to set up an IPv6 tunnel via Hurricane Electric’s tunnelbroker > service, but packets are not routed through the tunnel. > > After registering the tunnel, their instructions for NetBSD are to configure > the network as follows: > > ifconfig gif0 create > ifconfig gif0 tunnel x.x.x.x y.y.y.y
Is the local address here in a public IPv4 prefix that is already assigned to another interface on the host? RFC1918 prefixes or RFC6598 CGNAT address space (100.64.0.0/10) will (almost certainly) not work for protocol 41 tunnels. If it's a public address on the host, then you'll need to make sure your ISP isn't blocking IPv4 protocol 41 in either direction. (I've seen a USA residential DOCSIS provider do this.) > ifconfig gif0 inet6 X:X:X:X::2 Y:Y:Y:Y::1 prefixlen 128 > ifconfig gif0 mtu 1480 > route -n add -inet6 default Y:Y:Y:Y::1 > > where > x.x.x.x is the public IPv4 address of the local server, > y.y.y.y is the public IPv4 address of the remote tunnel server, > X:X:X:X::2 is the IPv6 address assigned to the local end of the tunnel, and > X:X:X:X::1 is the IPv6 address assigned to the remote end of the tunnel. > > Afterwards, I should be able to ping6 X:X:X:X::1 successfully, i.e., send > packets through the tunnel. However, all I get is the following: > > # ping6 Y:Y:Y:Y::1 > PING6(56=40+8+8 bytes) X:X:X:X::2 --> X:X:X:X::1 > 100% packet loss > > Here is the configuration of gif0 reported by ifconfig: > > gif0: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1480 > tunnel inet x.x.x.x --> y.y.y.y > status: active > inet6 X:X:X:X::2/128 -> X:X:X:X::1 flags 0 > inet6 fe80::Z:Z:Z:Z%gif0/64 -> flags 0 scopeid 0x5 > > Here is what I believe to be the relevant subset of the IPv6 routing table > from netstat -rn -f inet6: > > Internet6: > Destination Gateway Flags > Refs Use Mtu Interface > default X:X:X:X::1 UGS > - - - gif0 > X:X:X:X::1 X:X:X:X::2 UHC > - - - gif0 > X:X:X:X::2 gif0 UHl > - - - lo0 > > Are there any kernel options that need to be enabled? This is an 11.0_BETA > kernel from late November. > `options GATEWAY` is not required for what you're trying to do. > Or sysctl variables that need to be set? > The forwarding sysctl shouldn't be needed for just the tunnel itself working. If you get it working and get a delegated prefix that you route to downstream hosts then you'd need the inet6 forwarding sysctl enabled. > I would geatly appreciate more eyes on this and ideas on how to troubleshoot > the problem. This is my first foray into IPv6 land and I’m not finding any > useful debugging information. Most everything says, now ping6 the remote end > of the tunnel; it should work. > > Thank you very much. > > Cheers, > Brook >
