Least-privilege Allowed IPs generated from Firewall Rules

Allowed IPs in the WireGuard® config can now be derived from the Firewall Rules that apply to a specific user, so a config never reveals subnets that user has no permission to reach.

Beyond convenience, this feature closes a subtle but real security gap in WireGuard®-based Zero Trust Network Access (ZTNA): users should not be given unnecessary routes to network resources they don’t have permission to access - even at the config level.

The gap in static Allowed IPs

WireGuard®‘s Allowed IPs setting doubles as both a split-tunneling control and an access boundary - whatever IP ranges appear there define what the client can route to.

With static, manually maintained Allowed IPs, it’s easy for a WireGuard® config to end up broader than a user’s actual entitlements, whether through legacy entries, copy-pasted configs or simple oversight. That over-broad list effectively exposes internal network structure - a form of unintended network reconnaissance - even if the firewall ultimately blocks the traffic.

Deriving Allowed IPs from entitlements

Now, Allowed IPs in the WireGuard® config managed by Defguard can be derived directly from the Firewall Rules that apply to that specific user, enforcing true identity-based, least-privilege access at the visibility layer, not just the enforcement layer.

This setting is disabled by default and you may enable it during location configuration. Manually defined Allowed IPs are not replaced entirely - they are combined with the entries derived from ACLs.

This strengthens network segmentation and reduces attack surface by ensuring configs stay minimal and accurate - a form of automated VPN configuration hygiene.

Example

A company has three internal services on separate subnets:

HR system - 10.10.1.0/24
Finance system - 10.10.2.0/24
Engineering tools - 10.10.3.0/24

Firewall Rules grant:

Alice (HR team): access to 10.10.1.0/24 only
Bob (Engineering team): access to 10.10.3.0/24 only

When their WireGuard® device configs are generated (the client refreshes them every 30 seconds):

Alice’s Allowed IPs include 10.10.1.0/24 - the Finance and Engineering subnets never appear.
Bob’s Allowed IPs include 10.10.3.0/24 - the HR and Finance subnets never appear.

Neither user’s config reveals that the other two subnets even exist, tightening the ZTNA posture even before firewall enforcement kicks in.

Documentation: Location management and Firewall configuration