Wireguard S2S broken

[phaze75]

There are multiple separate issues getting conflated in this thread. The original post was about failure resolving a peer address from a DNS name. @phaze75's issues have nothing to do with that - rather it (now) appears to be a firewall issue (after getting past the "address without a mask" change - also unrelated to the OP) - the VPN is apparently up, but the firewall is not allowing DNS traffic (and probably any other traffic, but DNS is the first victim). Do you have firewall rules to allow traffic from your WG interface?

Sorry for piggybacking. Wasn't aware of it.

I checked my firewall rules and realized that there has been a change and they have become legacy rules. So, I just migrated them to the new format hoping this would be an easy fix. Unfortunately it was not.

To my understanding my firewall ruleset is the most basic one can have, only consisting of default rules. There is a rule that should cover the WG peers. See attached screenshot. Please correct me if I'm wrong.

[dseven]

Possibly a routing issue, then. I see an OpenVPN rule there - is it possible that you've configured OpenVPN to use the same IP addresses as WireGuard, or something?

Under System -> Routes -> Status, do you see a route for destination 192.168.1.2, pointing to your wireguard interface?

[phaze75]

Possibly a routing issue, then. I see an OpenVPN rule there - is it possible that you've configured OpenVPN to use the same IP addresses as WireGuard, or soemthing?

Under System -> Routes -> Status, do you see a route for destination 192.168.1.2, pointing to your wireguard interface?

No, I don't use OpenVPN anymore. There is no instance running and no interface assigned.

Yes, there are four routes 192.168.1.1-.4 for each of my four peers pointing to "wg0", which is my WG interface.

[dseven]

It's a bit of a shot in the dark, but you could try:

Firewall -> Diagnostics -> States -> Actions -> Reset state table

in case there's something funky left over from earlier issues.

Failing that, I'm not sure why you'd be hitting the default rule....

[phaze75]

It's a bit of a shot in the dark, but you could try:

Firewall -> Diagnostics -> States -> Actions -> Reset state table

in case there's something funky left over from earlier issues.

Failing that, I'm not sure why you'd be hitting the default rule....

I reset the state table, but the firewall keeps blocking.

[phaze75]

I just created a dedicated rule from "192.168.1.2" to "LAN network" and moved the rule to the top of the "Interface rules" stack. That works, but it can't be the solution. 

[dseven]

I just created a dedicated rule from "192.168.1.2" to "LAN network" and moved the rule to the top of the "Interface rules" stack. That works, but it can't be the solution. 

Oh, "WireGuard network" probably isn't covering your peers. Does your WireGuard interface have an IP address? Your "Instance" should have a "Tunnel address" with a netmask that covers the range of addresses of your peers.

[dseven]

Actually that might not do it - you might have to configure an address on the assigned interface for that to work. I'm not sure - my rule doesn't specify a source address - just allows anything coming from the WG interface.

[phaze75]

Oh, "WireGuard network" probably isn't covering your peers. Does your WireGuard interface have an IP address? Your "Instance" should have a "Tunnel address" with a netmask that covers the range of addresses of your peers.

Yes, the "Tunnel address" is "192.168.1.254/32" and my four peers are listed within the instance. Until 26.7 the "Tunnel address" was "192.168.1.254". This is where the whole mess started.

[dseven]

Yes, the "Tunnel address" is "192.168.1.254/32" and my four peers are listed within the instance. Until 26.7 the "Tunnel address" was "192.168.1.254". This is where the whole mess started.

For giggles, try /24 instead of /32

[phaze75]

For giggles, try /24 instead of /32

I don't know if I should giggle, laugh, blush or cry. Maybe all of it. 🤦🏼That's it, issue SOLVED. Thank you so much! 🙏🏼

[dseven]

Nice :)

So (from what Franco said earlier), it sounds like FreeBSD used to just assume /24 if a netmask wasn't supplied. Whilst the breaking change is a bit inconvenient, that does seem a bit presumptuous, and I think they probably were right to fix it.

Why it matters for you: you're using a "dynamic alias" in your firewall rule - "WireGuard network" means "the local network currently configured for the WireGuard interface". If the interface address was 192.168.1.254/32. the local network would also be 192.168.1.254/32, and 192.168.1.2 is not part of that, hence the rule didn't match. By changing the netmask to /24, the network changes to 192.168.1.0/24, which 192.168.1.2 is part of. 

[phaze75]

Why it matters for you: you're using a "dynamic alias" in your firewall rule - "WireGuard network" means "the local network currently configured for the WireGuard interface". If the interface address was 192.168.1.254/32. the local network would also be 192.168.1.254/32, and 192.168.1.2 is not part of that, hence the rule didn't match. By changing the netmask to /24, the network changes to 192.168.1.0/24, which 192.168.1.2 is part of. 

Now that we've solved it, everything makes sense. Still, to save a bit of face, I'd like to point out that the term "Tunnel address" in the "Instance" config doesn't really suggest a netmask larger than one (tunnel) address. So it seemed logical to use the /32 netmask instead of /24 for the tunnel's single IP. I'd suggest adding a small note next to the field to save others the same confusion - though maybe that's just me. 😅

[dseven]

/32 will work for the tunnel address. It's just that you can't use the dynamic alias if you do that. You could use static aliases for the source address, or just not specify any source address (i.e. "any").

[phaze75]

/32 will work for the tunnel address. It's just that you can't use the dynamic alias if you do that. You could use static aliases for the source address, or just not specify any source address (i.e. "any").

That's clear now. I don't remeber the exact steps I took when setting up WireGuard, but I'm 99.9% sure the firewall rule(s) were configured automatically or manually exactly as described in the documentation. If the standard rule uses a dynamic alias for "Source," I'd suggest making sure this "WireGuard network" alias aligns with whatever is entered as the "Tunnel address" in the "Instance" configuration. Especially if BSD has previously assumed or suggested a /24 netmask.