Re: FreeBSD 14.x localhost source address

On Sat, Jun 29, 2024 at 8:17 PM Craig Leres <leres@freebsd.org> wrote:
>
> 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
>

 What netmask are you using for 127.0.0.2? I'd treat it as I would an
IP alias (only on localhost) with a /32 netmask, should keep it
isolated. Just tried it myself on a test box and iperf works as
expected, using 127.0.0.1 as the source when connecting.


-Proto