-
-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design: Allow ACL per user and/or per group #688
Comments
I second that, this is the main feature missing for me to consider Defguard for our humble hub-spoke setup, even though it ticks so many other boxes that no other solution does! So basically a way to facilitate the management of netfilter rules on the server (or even any linux-based routing peer, if it gets to that some day), in combination to user/peer-specific primitives. Similar to how Firezone was doing, at least till v0.7. I believe Robert mentioned on a Reddit post that this is planned, let's hope it happens :) Also I see on the Roadmap is mesh networking, which is such a wild complexity beast to tame! Either way, I do hope ACL doesn't happen exclusively at the overlay network level and allows CIDR definitions, unlike Netbird. |
@soymgomez for now defguard is a VPN solution - where you define where users have access based on allowed IPs - which is WireGuard functionality rather then defguard - and then as an administrator based on your firewall. @soymgomez I understand that by ACLs (and restricting across to networks) you mean that defguard should also enable features as a firewall management tool? There is a risk here that when deploying on an actual gateway / firewall defguard would interfere with the solution firewall rules... so either it will completely takes over this responsibility or doesn"t have this at all (current state). TBH I don't see any middle ground. Or am I missing something? @n5ke would you also elaborate your requirements in the light of my above comment? Thank you guys. |
As a fellow user of VPN solutions, I've been following your discussion with great interest. Both of you raise valid points that resonate with my own experiences. Basic user/group access control: Something simple to start with, allowing us to set basic permissions. I believe these additions would make Defguard even more valuable without sacrificing its core simplicity. What do you think? Am I missing any crucial user needs? |
@teon, as of today we have it as you say, the firewall part to provide access separate from the VPN. It works and it is correct, but there are some limitations as I can make rules to allow a VPN server to access a network range, but if I want to give special permissions to a person I can't as I don't know their IPs assigned inside the VPN. That is why I proposed to make a basic ACL management by users and groups to be able to manage this in a unified way. @NerdvanaExplorer I agree with you that Defguard must remain simple but it is also important to be able to have granular control of access. Here we could open another topic and that is to be able to make groups and subgroups that inherit permissions from parents. |
@NerdvanaExplorer @soymgomez could you provide a simple example / description of the ACL requirements (and access to what? how do you envision this?), so we could understand it and propose a good solution for that before implementing? Please do elaborate - the more we understand your requirements the better tool/solution we all have. Thank you in advance. |
Thanks for engaging Robert, I should say that I really admire your creativity and generosity that you've shown with writing and sharing Defguard! I understand your point about the possibility of conflicts with anything else that might be managing firewall rules on the host, on the other hand I think it's a much more common and sane use case to expect Defguard to be deployed on a separate system, than on a firewall itself, and treat it as an independent appliance with nothing else on it.
The problem with AllowedIPs is that it's adjustable at the peer side and the problem with managing access to a firewall independently is that it has no direct knowledge of the wireguard peers' addresses -the user would need to maintain a list somehow and keep it up to date.
The use case is that some VPN users only need access to a limited number of services and it would be a good practice to enforce access to only what they need. The standard use case is that Defguard device has interfaces to a number of internal networks and acts as a router between these subnets and the subnet of the VPN users. All traffic between the VPN subnet and any other networks the Defguard device is a member of can be routed through this (without SNAT/masquerading). So far so good, already happens AFAIK. But that puts the Defguard host to the unique position of being the only authority that knows the addresses and identities of the wireguard peers, so it is in the most privileged position to control access of individual peers towards specific destinations -since any other external system has no easy way of knowing which peer has which IP address at any given time. I am attaching a screenshot of how it could look like from the User-interface perspective (taken from Firezone 0.7): And another screenshot from Netbird's Interface, that unfortunately at this time only allows definining ACL policies between peers/groups instead of peers and arbitrary CIDR definitions From the back-end perspective, I imagine the natural way of doing it would be by injecting ACCEPT/DROP/REJECT netfilter rules (maybe could use something like this, this or this for integration) on the host that Defguard runs on. The likelihood of conflict with rules managed by any other system, if that is deemed likely, could be reduced by applying them explicitly to the Wireguard interface name. If Defguard expands its functionality to include mesh topologies (coordinating p2p tunnels between the peers), this functionality could then be extended to any peer host that happens to be designated as a "routing peer" for a subnet (to borrow the naming that Netbird uses). Nikitas |
@teon As a regular user, I've created a document that describes in detail the ACL features we believe would be valuable for Defguard. Detailed ACL Requirements for Defguard1. Basic User/Group Access ControlRequirement:Ability to define access rules based on users and groups. Example Scenario:
Proposed Implementation:
2. Network Resource DefinitionRequirement:Ability to define internal network resources by IP ranges or specific addresses. Example:
3. Access Rule CreationRequirement:Interface to create rules linking users/groups with network resources. Example Rules:
4. Rule Priority and Conflict ResolutionRequirement:Mechanism to handle rule conflicts and set priorities. Example:
5. Temporary Access ProvisionRequirement:Ability to grant temporary access to users or groups. Example:
6. Logging and MonitoringRequirement:Log access attempts and provide an interface to monitor these logs. Example:
7. Integration with Existing Firewall RulesRequirement:Ensure ACL rules work in harmony with existing firewall configurations. Proposed Approach:
8. User-Friendly InterfaceRequirement:An intuitive interface for managing ACL rules. Features:
|
Describe the solution you'd like
Hello,
I was testing Defguard and I don't see anywhere in the documentation that you can make a granular control per user or per group.
The case I raise is to register a new site not all users will have, or should not have access to the entire network.
It would be interesting in the future to be able to limit within a site to which range or IPs a user or group of users can connect.
I leave it as a future idea because I have not seen anything similar in the roadmap.
Best regards
The text was updated successfully, but these errors were encountered: