And that's how routing table looks like:
Code:
Destination Gateway Flags Netif Expire
10.1.1.42 link#1 UH igb0
That seems to be the culprit. Prior to FreeBSD 13 this route used to point to the loopback interface
lo0, now it instead points to the physical interface. I'm seeing similar behaviour with an apache web server running on an alias IP, a setup I haven't touched in many years and up to FreeBSD 12.2 it was working. Now with FreeBSD 13 the server can be accessed externally, but not from the host itself. I found that connection attempts from the host itself are now blocked by my
pf(4) firewall, which is intended behaviour as such traffic is not supposed to go out on
igb0 in the first place.
So what would be recommended/best practice way to bring back 12.2 behavior ?
I'm still looking for a definitive solution.
Manually deleting the route and adding one with
lo0 as the interface seems to restore the old behaviour:
Code:
# route del 10.1.1.42
# route add 10.1.1.42 -interface lo0
But that is hardly a long-term solution. Creating the IP alias with the 'real' netmask instead of /32 seems to create a route like in previous releases, but all documentation suggests that /32 is correct for alias IPs:
Code:
ifconfig igb0 inet 10.1.1.42 -alias
ifconfig igb0 inet 10.1.1.42/24 alias
So far I could only find a few clues regarding this issue.
The FreeBSD 13.0 release notes mention:
Duplicate routes installation issue for /32 or /128 interface aliases has been fixed. 81728a538d24
Then there are also
D30811 and
D28246 as well as some related bug reports
256681 and
258949.
Some of the comments suggest that
it is working as intended, which for us it clearly is not.