Design: Allow ACL per user and/or per group

[soymgomez]

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

[n5ke]

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.

[teon]

@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.

[NerdvanaExplorer]

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!

[soymgomez]

@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.

[teon]

@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

[n5ke]

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

[NerdvanaExplorer]

@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

[eblet]

633? Oo

[4lb]

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:

[NerdvanaExplorer]

@teon @4lb The design of an access control system should revolve around three core objectives: usability, security, and flexibility. Looking at the current design, dividing functionality into alias management and rule management is a good starting point, drawing from traditional firewall best practices. However, considering the complex requirements of modern enterprises, I recommend more comprehensive optimization and expansion on this foundation.

Let's first look at alias management. The current design supports IPv4/IPv6 addresses, which is good, but the user experience could be more friendly. For instance, we could add a subnet calculator to help users quickly calculate and validate CIDR address ranges. When entering IP addresses, the system should perform real-time format validation and use different colors to identify IPv4 and IPv6 addresses, making them instantly distinguishable. For frequently used addresses, the system should support creating address groups and allow adding descriptive tags such as "Development Environment" or "Production Servers."

Port management could also be made more intelligent. While the current dropdown selector is good, adding a range selection slider would be more intuitive. We can preset common port combinations like "Web Services" (80, 443) and "Mail Services" (25, 110, 143). Users should also be able to create custom port groups and add tags and descriptions to these groups. To prevent configuration errors, the system should detect potential conflicts when selecting port ranges.

Rule management is another area requiring significant optimization. The current design separates user group and target configuration, which is clear but involves too many steps. We recommend changing this to an integrated configuration panel where all settings can be completed in a single view. The rule list should support drag-and-drop sorting, allowing administrators to intuitively adjust rule priorities. To help users understand a rule's scope, we should add a preview feature showing which users and resources would be affected. For complex rule settings, we should provide rule templates enabling users to quickly create rules based on templates, reducing repetitive work.

Multi-environment support is essential for modern enterprises. The system should allow administrators to create independent rule sets for different environments (development, testing, staging, production) and provide rule synchronization capabilities between environments. For example, rules from the development environment can be selectively synchronized to production after testing. During synchronization, the system needs to automatically detect rule conflicts and provide detailed comparison reports.

Temporary access management is also crucial. External consultants and temporary developers often need short-term access to specific resources. The system should provide comprehensive temporary permission management features, including: access time limits, automatic expiration mechanisms, and application and approval processes. These temporary permissions should be viewable and manageable at any time, with the ability to revoke them immediately if necessary.

For security, several essential mechanisms need to be added. First is the approval process - important rule changes should require approval before taking effect. The system must record all configuration change history, supporting version control and rollback. When rules change, the system should automatically analyze potential impacts and generate risk assessment reports. For abnormal situations, there must be emergency response mechanisms to quickly switch to preset security modes. We recommend adding behavioral analysis and anomaly detection features, using machine learning to identify unusual access patterns and automatically generate alerts.

Dynamic identity authentication is another important means of enhancing security. Besides basic user group permissions, the system should consider factors like login location, device type, and behavior patterns to dynamically adjust access permissions. For example, when detecting unusual login locations, it should automatically increase security levels and require additional identity verification.

Permission management needs proper tiering. We recommend three permission levels: junior administrators can only modify existing rules, senior administrators can create new rules, while critical settings like changing default policies are restricted to super administrators. Each permission level must have clearly defined operational scope limits and audit log records.

The interface design should adopt a three-column layout: navigation menu on the left showing different function categories; main operation area in the middle supporting rule drag-and-drop sorting; and context information panel on the right displaying detailed information and help for cur

My Design：

Of course, this is my personal opinion.