DefGuard
Design: Allow ACL per user and/or per group
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
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. @n5ke , I completely agree with your need for more granular access control. In my company, we have different teams accessing various resources, and it would be incredibly helpful to have finer control over who can access what. It's not just about security; it's also about maintaining a clean, efficient network. @teon , I appreciate your caution about feature creep. As a user, I value simplicity and don't want a VPN tool that tries to do everything and ends up being a nightmare to configure. From my perspective, here's what I'd love to see in Defguard:
Basic user/group access control: Something simple to start with, allowing us to set basic permissions. User-friendly interface: An intuitive way to set and view these access rules. Not all of us are network experts! Optional advanced features: For those of us who need more complex setups, maybe an 'advanced mode' that doesn't clutter the basic interface. Compatibility: Whatever new features are added, please ensure they play nice with existing network setups. We don't want to reconfigure everything!
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? Looking forward to seeing how Defguard evolves!
@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. Robert
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.
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.
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.
@n5ke would you also elaborate your requirements in the light of my above comment?
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. This proposal attempts to balance the needs of advanced users with the necessity of keeping the system relatively simple. It includes aspects such as basic user/group access control, network resource definition, rule creation, and priority setting. I've also included some specific examples to better illustrate how these features might be applied in real-world scenarios. I believe this proposal can serve as a starting point for further discussion on ACL functionality in Defguard. I hope it provides some valuable insights for you and the development team.
Detailed ACL Requirements for Defguard
1. Basic User/Group Access Control
Requirement:
Ability to define access rules based on users and groups.
Example Scenario:
- Marketing team needs access to web servers and analytics tools
- Development team needs access to development servers and databases
- IT team needs access to all resources
Proposed Implementation:
- Create user groups (e.g., Marketing, Development, IT)
- Assign users to these groups
- Define access rules for each group
2. Network Resource Definition
Requirement:
Ability to define internal network resources by IP ranges or specific addresses.
Example:
- Web Servers: 192.168.1.0/24
- Database Servers: 192.168.2.0/24
- Analytics Tools: 192.168.3.10, 192.168.3.11
3. Access Rule Creation
Requirement:
Interface to create rules linking users/groups with network resources.
Example Rules:
- Marketing Group can access Web Servers and Analytics Tools
- Development Group can access Web Servers and Database Servers
- IT Group can access all defined resources
4. Rule Priority and Conflict Resolution
Requirement:
Mechanism to handle rule conflicts and set priorities.
Example:
- Group rules apply by default
- Individual user rules can override group rules
- Explicit "Deny" rules take precedence over "Allow" rules
5. Temporary Access Provision
Requirement:
Ability to grant temporary access to users or groups.
Example:
- Grant a contractor access to specific resources for 30 days
- Provide temporary elevated access to a developer for a specific project
6. Logging and Monitoring
Requirement:
Log access attempts and provide an interface to monitor these logs.
Example:
- Log successful and failed access attempts
- Provide a dashboard showing access patterns and potential security issues
7. Integration with Existing Firewall Rules
Requirement:
Ensure ACL rules work in harmony with existing firewall configurations.
Proposed Approach:
- Apply ACL rules specifically to the Wireguard interface
- Provide options to export ACL rules in a format compatible with common firewall solutions
8. User-Friendly Interface
Requirement:
An intuitive interface for managing ACL rules.
Features:
- Drag-and-drop rule creation
- Visual representation of network layout and access paths
- Ability to simulate access to check rule effectiveness
Hello, below is a proposed design of ACL functionality. Let us know what do you think, what could be done better?
The main idea is to separate it into Aliases and Rules. This is similar to the solution in most firewall solutions. Aliases tab is for creating Destinations based on IPs and ports. You can use those Aliases later on while creating rules for users and groups in Rules tab, although you can also just create rules using just IPs and ports directly.
Aliases are pre-defined configurations that name any IP, range of IPs or ports, when defined make it easier to use re-use them in any rules you define later. If you change the alias all rules that use the alias will automatically updated, making it very convenient to use instead of defining networks/ports in every rule by hand.
Default ACL defines how users and devices interact with your network by default. The default setting is to Allow all traffic from the VPN to your local networks. If you want this setting, we recommend defining Deny ACL rules to restrict access to specific networks, addresses, or ports that users should not access. You can change this in Global Settings > ACL Tab. If the default ACL rule is Deny, you need to define Allow rules to grant users or groups access to selected networks, IPs, or ports.
This is proposed Aliases tab with Create Alias modal:
This is proposed Rules tab with Create Rule modal:
Drop down state for search and add destination aliases:
