Egress Rules not working as expected when deny 0.0.0.0/0

I want to deny all and only allow know networks

table inet firezone {
	chain forward {
		type filter hook forward priority filter; policy accept;
		ip daddr 10.140.0.0/16 accept
		ip daddr 0.0.0.0/0 drop
	}
}

but this isn’t working, I am not able to connect to any of IP in the allowed network.

Hm, likely a rule priority issue. We’ll have to expose a priority for allow/deny rules so that it’s clear which take precedence.

2 Likes

Hey, have you guys made any progress on that topic? I also want to deny everything, then allow on a case-by-case basis. Thanks!

Hi @ActiQL

Do you want the client to decide which IP’s/networks to send traffic via Wireguard for? If so I can give you a solution that works for Linux but I have no idea for Windows as I am not familiar with Wireguard on it.

Hi @gbe0, and thanks for reaching out!

What I basically do is that I default the allowed IPs to 172.16.0.0/20 (which includes all of my LANs) so that all clients can have access to anything in my intranet. Then, I fine-tune the egress part when I want to deny everything (that part cannot be overridden by users) by that logic: deny all, then allow some.

What I understood was that you first want to configure your “site defaults” so that clients have the right settings to route traffic through WireGuard, and then you can fine-tune the firewall part thanks to “egress”. Maybe that’s not the way we’re supposed to do that?

All in all, my clients get the right routes. I just want the VPN to filter out traffic for non-authorized users towards some subnets.

Hi @ActiQL

Would it work if you set in the Firezone server config default['firezone']['wireguard']['allowed_ips'] to 172.16.0.0/20 then in the egress rules add the relevant restrictions per device/user as needed:

That way you don’t add any allow list rules, its only the deny list that needs modifications.

@gbe0 , that would work, yes. But, my issue is that by proceeding so, I’d have to explicitly deny more users than I’d allow. As I have only a couple of people (admins) who’d get access to most LANs, I’d have to dial in more deny rules, than allow ones. Adopting your strategy would make me create 30 deny rules. The other way around would have me create 1 deny rule for 2 allow ones.

Your point of setting 172.16.0.0/20 directly in the allowed IPs, and then denying stuff makes sense and I’ll do that. But, my use-case forces me to take the approach of denying first. Unless Firezone has/will implement user grouping?

Feel free to let me know whether my situation’s not quite clear.

Hey @ActiQL – yes, we are actively working on this as part of a major re-architecture that’s underway.

As it stands now in 0.5.7, more specific rules should take priority over more general ones.

We’ll have a new firewall backend based on eBPF that assumes a default-deny or default-allow policy (user-configurable) and then applies the created rules against that. That seems to be a simpler approach and a better fit for most of our users.

Groups are coming too – are you looking to map these automatically via SAML / SCIM or would they just live in Firezone?

Hi @jamil and thanks for jumping in!

As my company relies on Azure AD, we do most of our SSO integrations there. The Azure login with Firezone is a game changer for us, so I’d love to have more user/group functions. I can’t wait to see those promising features in action!

To sum up, addressing the deny-first strategy we’re trying to implement here with the 0.0.0.0/0 won’t work with the current version of Firezone, am I right? So, the best approach would consist in allowing subnets to be served through the VPN with the default['firezone']['wireguard']['allowed_ips'], and then deny some with the denylist, correct?

You should be able to add 0.0.0.0/0 and ::/0 in the Denylist, and then selectively allow CIDRs and IPs in the Allowlist today in 0.5.7. Is that not the behavior you’re seeing? That would be a bug if so.

Hi,
I’m jumping in this thread because I’m having the exact same issue.
I’ve installed firezone 0.5.7 from the install script on debian 11 and rocky 9 (I had to tweak the script for Rocky 9).
I’ve set some rules, 0.0.0.0/0 in the denylist, no port nor user specified, and a few hosts and subnets, with ports, with or without user scope specified in the Allowlist, but it seems that nothing gets through.
If I add a 0.0.0.0/0 with a user scope set in Allowlist, then everything goes through for this user.
Are there any firewall logs where we can see what’s happening ?
Can I help in some way debugging this issue ?

Hi,

I just simulate at Fedora 36 with 0.5.8, it work as follow test:

  • masquerade enable both IPv4 and IPv6 (by default)
  • add global denied rule (0.0.0.0/0)
  • ping to internal and internet, denied as expect
  • add global allow subnet (10.11.11.0/24 , this is my server zone)
  • ping and ssh test, passed
  • remove that rule, add user specific rule, allow only a NAS IP (10.11.11.32/32, TCP 5000)
  • ping test failed, expected, no port allow
  • open browser and access https://10.11.11.32:5000, passed as expect

I not sure does 0.5.7 has issues but I confirm 0.5.8 should work as expect.
or you can execute firezone-ctl reconfigure; firezone-ctl restart to test it again

thanks

Regards,
Lawes

I have to admit that I’m feeling a bit stupid, we have internal DNS sets in wireguard configuration, which are at the other end of the tunnel, so if I don’t add a rule that permit dns requests, it doesn’t work as expected…

Sorry for this one and thanks for your help.