WireGuard Interface Firewall Rules Ignored

[Blixxybo]

I have a WireGuard Instance operational with various Clients working as expected, except for the fact that Firewall rules don't seem to apply or do anything on the WG interface. I've gone over the Floating/Auto generated rules, there's nothing that would be an implied "Allow All". Explicit Deny rules on WG1 don't work, removing all rules doesn't work. No matter what I do, ICMP traffic from the client still passes to my LAN.

Anyone have ideas? You can see in the screenshots I have no rule on WG1 allowing traffic to pass to my LAN interface (172.16.10.0/24) yet somehow, it's still allowed.

[patient0]

Do you have any rules in the "Wireguard (Group)" interface? And 10.1.1.2 is an WG1 address and on what interface is the destination, 172.16.10.2?

[meyergru]

Try pinging something else in that LAN subnet or accessing any port. Also, there could be Wireguard (Group) rules, as patient0 mentioned.

[Blixxybo]

Thanks for the suggestions, unfortunately I have no Wireguard (Group) rules at all.

OPNSense
LAN: 172.16.10.254
WG1: 10.1.1.1

Client:
WG0: 10.1.1.2

From the client, I can ping anything on the 172.16.10.254. I can also make TCP connections to open ports.

For some reason, the lack of Allow ACL on WG1, or even an explicit Deny does absolutely nothing. Traffic still passes to LAN.
I tried putting an Outbound ACL on LAN to block the traffic, that does work. It's quite odd to put the ACL on the outbound interface and not block it at the source. Surely this isn't how it's supposed to work?

[patient0]

OPNSense
LAN: 172.16.10.254
WG1: 10.1.1.1

Client:
WG0: 10.1.1.2

To recap:
OPNsense LAN IP 172.16.10.254, a /24 network I assume. Your pinging to a LAN client with the IP 172.16.10.2
OPNsense WG1 IP 10.1.1.1, a /29 network

WG0 10.1.1.2 is an OPNsense WG1 peer IP outside of your LAN/OPNsense? What does a traceroute from your client to 172.16.10.2 show?

[Blixxybo]

Correct.

10.1.1.0/29 is for WireGuard Tunnel IPs.
172.16.10.0/24 is LAN at the 10.1.1.1/29 side.
10.0.0.0/24 is LAN at the 10.1.1.2/29 side.

10.0.0.65 is 10.1.1.2, it's a host/VPS connected into the OPNSense.
172.16.10.2 is a server on the LAN, behind the OPNsense.

[meyergru]

It seems you have a roadwarrior type of setup where the IP of the client lies within the transfer net (10.x.x.x/24) itself instead of a separate network. I think that because of the "pointopoint" type of your WG interface on the Linux client. You probably should look at the actual source IP of the ping from the client to confirm.

I only use site-2-site setups and can report that the firewall rules apply (and work correctly) in that case.

I think (i.e. do not know) that it is this why it seems to work that way: The packets from the road warrior exit the WG1 interfact on the way to your LAN, not enter it - thus, you might need an outbound rule to actually block them.

[patient0]

It seems you have a roadwarrior type of setup where the IP of the client lies within the transfer net (10.x.x.x/24) itself

Mmhh, I don't think so (or I misunderstand the situation), the WG clients LAN is 10.0.0.0/24 and the WG tunnel is 10.1.1.2/29, seems like a normal, S2S-ish setup.

For me it looks correct, I'm a bit at loss why it would work, without any rules on the wireguard interface, no access is allowed. I'd do a package capture on the OPNsense WG1 interface and check the pf firewall rules file /tmp/rules.debug (via SSH or console) for rules involving the wireguard interface/subnet (of which there shouldn't be any).

You got a second wireguard WG0 running on OPnsense, is that working as expected?

[meyergru]

There is also another possibility that could become visible when you look at the source of the ping: If you defined NAT rules that (accidentally) apply to the WG interfaces.