pfSense

I have the same issue. Loads of "matchaddr failed" messages and any WG tunnel with more than a single peer fails.
I also see lots of "arprequest: cannot find matching address" messages too

Current version is v2.5.0

This is not isolated to when using multiple peers. It also happens to many people with just 1 peer (site to site). Do I need to file another bug?

I was able to resolve this issue however I'm not sure which thing I did that resolved it so here is what I changed.

1. On the peer WireGuard address first off Im using a /30 network for each VPN tunnel, then on each peer WireGuard address I'm putting in a specific address for each peer. Here is an example.
VPN Tunnel network is 192.168.100.0/30 which means that 192.168.200.1 and 192.168.200.2 are the only host useable addresses in that subnet. On Firewall1 I put in 192.168.200.1 without the / notation and on firewall2 I put in 192.168.200.2 again without the /notation.
2. I noticed that there were additional "LAN" network that weren't defined in the WireGuard allowed IPs that were trying to use the tunnel. What I mean by "LAN" networks is that I had OpenVPN Remote Access networks that were trying to get to hosts across the WireGuard tunnel and the OpenVPN IPs weren't specified in the WireGaurd allowed IPs.

Kevin Mychal Ong wrote:

This is not isolated to when using multiple peers. It also happens to many people with just 1 peer (site to site). Do I need to file another bug?

It's all likely the same root cause here. No need for a duplicate issue.

Adam Esslinger wrote:

I noticed that there were additional "LAN" network that weren't defined in the WireGuard allowed IPs that were trying to use the tunnel.

That is likely the source of all of these errors -- traffic attempting to use WireGuard which isn't matched by Allowed IPs. For example from a misconfiguration, unintended routing, or behavior of a daemon on the firewall bound to the interface address.

But it's not necessary to spam the console/logs with the error so we can likely suppress the message without harm.

Any other consequences such as a panic are likely unrelated to the error, but it still bears investigating.

That looks unrelated to this issue. I can connect multiple clients and ping them, but with the remotes being dynamic not only do the remote peers have to activate their VPN they must send traffic first. Otherwise WireGuard on the server has no idea where to send the traffic since the peer endpoint is dynamic. If the remote peers activate and send traffic, then I can ping all of them. I just can't ping them first from the server side. Also client firewalls could be blocking ping.

None of that has to do with this specific error, however, as far as I can see. I tried several combinations of the above procedure and at no time did it produce a matchaddr error, even when the ping failed before the remote peer sent traffic.

Maybe - I may be just conflating the matchaddr issue with my issue.

Do you need me to raise a fresh issue?

Mark Howells wrote:

Maybe - I may be just conflating the matchaddr issue with my issue.

Do you need me to raise a fresh issue?

Either continue along the existing support issue or start a forum thread -- I can't replicate what you are seeing, and we'd need a lot more information before making a definite statement about it being intended behavior vs misconfiguration vs an actionable bug

Jim Pingle wrote:

Mark Howells wrote:

Maybe - I may be just conflating the matchaddr issue with my issue.

Do you need me to raise a fresh issue?

Either continue along the existing support issue or start a forum thread -- I can't replicate what you are seeing, and we'd need a lot more information before making a definite statement about it being intended behavior vs misconfiguration vs an actionable bug

Understood and no worries. Thanks for your help.

Jim Pingle wrote:

Adam Esslinger wrote:

I noticed that there were additional "LAN" network that weren't defined in the WireGuard allowed IPs that were trying to use the tunnel.

That is likely the source of all of these errors -- traffic attempting to use WireGuard which isn't matched by Allowed IPs. For example from a misconfiguration, unintended routing, or behavior of a daemon on the firewall bound to the interface address.

But it's not necessary to spam the console/logs with the error so we can likely suppress the message without harm.

Any other consequences such as a panic are likely unrelated to the error, but it still bears investigating.

In my WG S2S scenario, I do have an OpenVPN Remote Access server configured on one end but I specifically have a rule in the OpenVPN_RA interface to block traffic from the OpenVPN_RA subnet to the WG S2S transit subnet. So I'm not sure what unauthorized traffic is trying to traverse the WG tunnel.

Unable to reproduce this now with latest kmod code.