Drop packets arriving from the network that have our source IP
address. If maliciously crafted they can create evil effects
like an RST exchange between two of our listening TCP ports.
Such packets just can't be legitimate. Enable the tunable
by default. Long time due for a modern Internet host.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Today I was doing a loopback test across two Mellanox ConnectX-4 LX ports on the same NIC, with a fresh 25GBE SFP+ DAC cable. This is with a fresh install of 15.0-RELEASE on a plain Samsung EVO SATA SSD, with a recycled Dell Optiplex 3020.
The mce(4) ports are not enabled at all by FreeBSD on boot, as we'd expect; they have not been explicitly configured; Moreover, according to sysrc -A, "ipv6_activate_all_interfaces" defaults to NO, so I am purely using IPv4 for my testing here. Had I not done that, I may not have run into the issue.
I proceeded to force my IPv4 packets to transit 802.3, rather than loopback, in the traditional way for this:
ifconfig mce0 192.168.1.1/30
ifconfig mce1 192.168.1.2/30
route -n del 192.168.1.0/30
route -n del 192.168.1.1
route -n del 192.168.1.2
Then, the ICMPv4 ECHO test:
- bypass routing table to reach mce1, force source to be mce0
- i.e. do *not* use -iface routes.
ping -S 192.168.1.1 -r 192.168.1.2
Then I discovered sysctl net.inet.ip.source_address_validation was blocking the packets. A new feature to me.
However, setting sysctl net.inet.ip.source_address_validation=0 did not appear to have an effect, until an ARP cache invalidation was forced:
ifconfig mce1 down
ifconfig mce1 up
Then, I got ICMP ECHO responses back just fine, and I went on to run iperf 2.x TCP and UDP tests.
Is this by design? This is probably worth reporting to others in case it is unexpected, but it certainly broke POLA for me.
While I'm here, note that I never got to submit my patches for bwping(8) back to the author from my PhD work in 2014/15, and lost them in my life crisis. At that time, bwping could only have its test load controlled by a "volume of bytes to send" parameter, and not a duration, unlike iperf. It has since moved to GitHub; this may have changed.
For such a test you'd better move one of the interfaces into VIMAGE jail. This will isolate not only from this particular problem, but from other potential problems.