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.
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:
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.
Hi,
i would like to follow up on this. Maybe im not doing it right or its not even supported the way i want to do it.
This is my setup:
firezone: 10.20.0.1
client1: 10.20.0.2
client2: 10.20.0.3
My goal is that all clients are not allowed to reach anything by default. I did this with a deny list entry of 0.0.0.0/0. Thats working great.
But now when i add 10.20.0.3/32 to the allow list i still cant ping it from client1. BUT if i add its with a /29 submask (so it includes the .1) it does work.
Default allowed IPs is set to 10.20.0.0/24.
I would like to dynamically adjust the IPs a client can reach in their lifetime.
Thanks for the awesome product! 
Could you add both the Firezone server tunnel IP and the peers you’d like to reach to the Allowlist individually?
Keep in mind you’ll need PersistentKeepalive set to something like 25 for NAT traversal to work from client to client.
Yes my issue was i only added one side e.g 10.20.0.2 → 10.20.0.3 but not the other way around. So now client1 can ping client2 and vice versa.
Thanks!
