pfSense

Just for reference, it appears a similar issue was observed early in WireGuard's original development.

https://git.zx2c4.com/wireguard-monolithic-historical/commit/?id=1e96d7f29551309f1ab5480e39dcc6124ea89aa0

Similarly, it appears this similar code made it into the Linux Kernel implementation as well

https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/device.c
https://github.com/torvalds/linux/blob/master/drivers/net/wireguard/device.c

if (dev_v4) {
        /* At some point we might put this check near the ip_rt_send_
     * redirect call of ip_forward in net/ipv4/ip_forward.c, similar
     * to the current secpath check.
         */
        IN_DEV_CONF_SET(dev_v4, SEND_REDIRECTS, false);
        IPV4_DEVCONF_ALL(dev_net(dev), SEND_REDIRECTS) = false;
    }

It would appear this may need to be corrected in the FreeBSD upstream.

Possibly relevant:
https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/ip_input.c
Line #119 (sysctl check)
Line #1040 (conditional logic)

https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/ip_var.h
Line 185 VNET_DECLARE(int, ipsendredirects);
Line 201 #define V_ipsendredirects VNET

I tried to poke around and look for other interfaces that were selectively disabling forward/redirect or other sysctl, but am not familiar enough with the code.
Thank you!

One last interesting tidbit, similar assumptions causing issues with p2p interfaces in ipv6 which caused issues for WG pre-kernel implementation.

https://github.com/freebsd/freebsd-src/commit/1e9b8db9b254b98ae065889f8c33b0dcc18138a1

I've disabled redirect via the sysctl/tunable as suggested already.

Just to clarify this is for every incoming packet that is forwarded by FreeBSD/pfSense from one peer on a WireGuard interface to another peer on the same WireGuard interface.

I think the concern would be the overhead this would add unnecessarily. If I understand the FreeBSD ip_forward function properly, it will be sending a redirect for every non-fragmented packet forwarded.

I will test this and get back to you shortly with some packet statistics to confirm if this assertion is correct.

Another workaround is to do one peer per tunnel and a dynamic routing protocol like BGP, or routes using the remote peer tunnel address as the gateway (fill in the Peer WireGuard Address appropriately, leave Allowed IPs blank, add your own manual static routes)

If it's the routes targeting the interface itself to blame, that should take it out of the equation.

I was able to confirm that there does not appear to be any rate limiting, the overhead isn't terrible though as the ICMP packets are so small. Getting statistics was a little more difficult on this new MacBook however and your proposed solution is the best I believe. This simplifies firewall rules and routing semantics.

Thank you

Christian McDonald Just for the record, I'm hitting this exact issue right now on current 22.05 snaps, with WG 0.1.6_1 package and 2 configured remote peers connected. It was easy to reproduce. Found a fairly recent forum thread with the same issue too.

Is the net.inet.ip.redirect=0 tunable still the best workaround we have here?

Christian McDonald wrote in #note-9:

Unable to replicate.

We can revisit if someone can demonstrate that this issue is still valid.

This issue is still valid. We just installed Wireguard on pfsense 2 days ago and we have the same behaviour.
The "workaround" "net.inet.ip.redirect=0" is not really acceptable, as we want to use this tunable enabled (for other purposes).
Can this be fixed in some other way?...

PS - to make it easier for anyone else to replicate:
we used this tutorial:
https://www.wundertech.net/how-to-set-up-wireguard-on-pfsense/
We have pfSense Community Edition (virtual machine, not physical).