Project

General

Profile

Actions

Bug #11502

closed

WireGuard ``matchaddr failed`` kernel messages in system log

Added by Adam Esslinger over 3 years ago. Updated over 3 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
Peter Grehan
Category:
WireGuard
Target version:
-
Start date:
02/22/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:

Description

When I setup 1 wireguard interface things work normally with 1 peer. Once I add a second peer to the same interface Im seeing "matchaddr failed" in the system logs. This issue is also discussed here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253254

https://forum.netgate.com/topic/160897/crash-report-2-5-0-rc/6


Files

peercfg.png (19.2 KB) peercfg.png Peer configuration (windows) Mark Howells, 03/02/2021 10:22 AM
firewall.png (111 KB) firewall.png Rule permitting traffic into the tunnel Mark Howells, 03/02/2021 10:22 AM
routes.png (52.7 KB) routes.png pfsense routing table showing (I think) correct conf. Mark Howells, 03/02/2021 10:22 AM
WGTunnels.png (124 KB) WGTunnels.png Wiregurad tunnels page (wg1 is the failing tunnel) Mark Howells, 03/02/2021 10:22 AM
Actions #1

Updated by Jim Pingle over 3 years ago

  • Assignee set to Peter Grehan
  • Target version set to CE-Next

Peter fixed a similar error before the release, this may be similar.

Actions #2

Updated by Mark Howells over 3 years ago

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

Actions #3

Updated by Kevin Mychal Ong over 3 years ago

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?

Actions #4

Updated by Adam Esslinger over 3 years ago

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.

Actions #5

Updated by Jim Pingle over 3 years ago

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.

Actions #6

Updated by Jim Pingle over 3 years ago

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.

Actions #7

Updated by Mark Howells over 3 years ago

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.

I don't think this is a harmless error. In my case, I'm very carefully using the correct CIDR notations on the tunnel and both peer definitions. And tunnels with multiple peers fail to work. I don't know if you're able to see tickets filed at Netgate (https://go.netgate.com/support/tickets/77390) but in that, I include screenshots and commentary showing what looks (to me) like the correct config. I've attached the screenshots here in case it helps... With the first peer in wg1 activated, I expect the pfsense to be able to ping 192.168.3.2 and the peer to ping 192.168.3.1 - it doesn't

Actions #8

Updated by Jim Pingle over 3 years ago

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.

Actions #9

Updated by Mark Howells over 3 years ago

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

Do you need me to raise a fresh issue?

Actions #10

Updated by Jim Pingle over 3 years ago

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

Actions #11

Updated by Mark Howells over 3 years ago

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.

Actions #12

Updated by Jim Pingle over 3 years ago

  • Target version changed from CE-Next to 2.5.1

Would be nice to at least suppress this console message since it's not useful.

Actions #13

Updated by Jim Pingle over 3 years ago

  • Subject changed from Wireguard matchaddr failed to WireGuard ``matchaddr failed`` kernel messages in system log

Updating subject for release notes.

Actions #14

Updated by Kevin Mychal Ong over 3 years ago

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.

Actions #15

Updated by Jim Pingle over 3 years ago

  • Target version changed from 2.5.1 to Future
Actions #16

Updated by Christian McDonald over 3 years ago

Unable to reproduce this now with latest kmod code.

Actions #17

Updated by Renato Botelho over 3 years ago

  • Status changed from New to Not a Bug
  • Target version deleted (Future)
Actions

Also available in: Atom PDF