FreeBSD 14.x localhost source address

From: Craig Leres <leres_at_freebsd.org>
Date: Sun, 30 Jun 2024 00:17:18 UTC
When I upgraded ~10 systems from 13.3 to 14.1 recently, 90%+ of my 
breakage was due to the localhost source address changing from 127.0.0.1 
to 127.0.0.2. This was on two of my systems.

My lo0 config is standard:

     mote 20 % ifconfig lo0
     lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 
mtu 16384
             options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
             inet 127.0.0.1 netmask 0xff000000
             inet6 ::1 prefixlen 128
             inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
             groups: lo
             nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

What's different on the two problematic systems is that they are 
authoritative nameservers. Following best practices, I use the (bind) 
server for authoritative queries and unbound for recursive resolver 
duties. The way I did this was to configure unbound to listen on 
127.0.0.2 and then change /etc/resolv.conf to use "nameserver 
127.0.0.2". (Which reminds me of another 14.X breakage -- unbound is no 
longer able to provide me with authoritative sshfp records!)

For 14.1 at least, this has the side effect that the source address for 
anything in the 127.0.0.0/8 domain becomes 127.0.0.2 instead of 127.0.0.1.

Given a host that has unbound listening on 127.0.0.2:

     mote 133 # lsof -np `cat /usr/local/etc/unbound/unbound.pid` | 
fgrep domain
     unbound 39496 unbound   3u  IPv4    0xfffff8001ee56000        0 
UDP 127.0.0.2:domain->*:*
     unbound 39496 unbound   4u  IPv4    0xfffff80037c2ea80        0 
TCP 127.0.0.2:domain->*:* (LISTEN)

you can see this with the iperf3 port. Start the server side with:

     iperf3 -s 127.0.0.1

and connect using:

     iperf3 -c 127.0.0.1

The server session will report:

     Accepted connection from 127.0.0.2, port 37306

I believe my configuration is far enough off the well-traveled path that 
I'm the first to notice this. But there are definitely some programs 
(e.g. sendmail/opendkim which appears to sign messages from 127.0.0.1 
but not from 127.0.0.2!) that are hardwired to know about 127.0.0.1 and 
deal with it specially/differently...

		Craig