Group-Based Access Over One VPN: Accounting, Warehouse, IT, Different Rights

The model: one VPN, many rights

“One VPN” doesn’t mean “one trust level.” It means one entry point and one operational surface area: one client profile experience,
one support workflow, one place to rotate keys and certificates. Rights are computed after authentication and enforced on the way
to the destination. Think of it like an airport: everyone enters the building, but not everyone gets into the cockpit.

For accounting, “rights” usually means access to ERP, financial shares, and maybe a jump host to a terminal server. For warehouse,
it’s typically WMS, barcode handheld apps, printers, maybe a limited file drop. For IT, it’s admin networks, management interfaces,
backups, hypervisors, and the authority to break glass when everything is on fire.

You get reliable group-based access by combining four primitives:

• Strong identity: who is this user/device, and how sure are we?
• Group membership: which role(s) do they have right now?
• Policy: what that role is allowed to reach (networks, ports, apps, shares).
• Enforcement: where that policy is actually applied (firewall, routing, storage ACLs, application auth).

If you only do one layer, you will be disappointed. If you do two, you’ll sleep better. If you do three or four,
you’ll stop having philosophical debates about “security vs productivity” because the system will be both.

Paraphrased idea (attributed): Systems that must be reliable should assume things fail and design for that reality — John Allspaw.
The VPN and its policies are no exception.

Joke #1: A VPN without access controls is like a nightclub with one bouncer and no list—everyone gets in, and the DJ ends up doing incident response.

Interesting facts & historical context

• VPNs started as “secure pipes,” not “identity systems.” Early IPsec thinking was tunnel-first; authorization was often an afterthought.
• Split tunneling has been controversial since it became common. It’s a security tradeoff: less backhaul, more risk if endpoints are messy.
• RADIUS predates most modern VPN UI workflows. Group-based authorization via RADIUS attributes has been around for decades.
• Active Directory group sprawl is a predictable failure mode. “Temporary access” groups have a way of becoming permanent roommates.
• Network segmentation used to be mostly physical. VLANs and VRFs made it logical; modern VPN policy makes it identity-driven.
• SMB permissions and POSIX permissions evolved separately. When you mix Samba + Linux ACLs + Windows groups, misunderstandings are guaranteed.
• “Zero Trust” is a new label for old principles. Least privilege, strong auth, and logging weren’t invented in 2019; they just got better marketing.
• WireGuard is young but opinionated. It intentionally avoids built-in user auth; you’re expected to integrate identity elsewhere.
• Audit requirements quietly shape architecture. If you can’t answer “who accessed what,” your design will be rewritten by compliance later.

Reference architecture that actually holds up

Pick a control plane, then stick to it

The fastest way to build a brittle VPN is to let every layer invent its own notion of “group.”
Your VPN server has “client configs,” your firewall has “address objects,” your NAS has “local users,”
and your auditors have “questions.” Don’t do that.

Choose one identity source of truth:

• Active Directory (AD) if you’re already a Windows shop.
• LDAP/FreeIPA if you want strong Linux-native identity.
• An identity provider + SSO if you’re modernizing, but be realistic about operational complexity.

Enforcement points: where policy becomes real

The clean design uses multiple enforcement points, each doing what it’s good at:

• VPN gateway: authentication, IP assignment, pushing routes/DNS, coarse per-group policy.
• Firewall/segment gateway: least-privilege network access (ports, destinations) with auditable logs.
• Application controls: ERP/WMS/SSH all have their own auth; use it.
• Storage controls: Samba/NTFS ACLs, NFSv4 ACLs, S3/IAM, ZFS dataset delegation—whatever fits, but enforce it.

The VPN gateway is not a magical policy appliance. It’s a choke point. Use it to ensure identities map to expected IPs and routes.
Then make the firewall the source of truth for “who can talk to what.”

A concrete, production-friendly layout

Here’s a layout that scales and doesn’t turn into a haunted house:

• One VPN entry: vpn-gw01 (and vpn-gw02 for HA if you value weekends).
• Separate internal segments behind a firewall/VRF boundary:
  • FIN-NET (accounting apps, finance file shares)
  • WMS-NET (warehouse app servers, printers)
  • MGMT-NET (hypervisors, iDRAC/iLO, backup servers)
  • USER-NET (general corp services)
• VPN address pools per group (or per role), e.g.:
  • 10.66.10.0/24 for accounting
  • 10.66.20.0/24 for warehouse
  • 10.66.30.0/24 for IT
• Firewall rules keyed on source VPN pool plus identity logs from VPN auth.
• DNS per group: finance users shouldn’t resolve mgmt hostnames, not because DNS is “security,” but because it’s hygiene and reduces mistakes.

You’ll notice the pattern: isolate by default, allow narrowly, and make it easy to prove it.

Identity and group mapping: where access control really starts

Users vs devices: decide what you’re authorizing

Warehouse environments often have shared devices, kiosk logins, or embedded scanners.
Accounting tends to have named users with higher sensitivity. IT often has named users and privileged devices.

Decide, explicitly:

• User-based VPN: user authenticates with MFA; group membership is derived from directory groups.
• Device-based VPN: device certificate or pre-shared key; group is derived from device identity.
• Hybrid: device must be enrolled plus user must authenticate (best for IT admin access).

If you can’t articulate whether your warehouse scanners are “users” or “devices,” you’re about to build the wrong policy.

Group mapping: keep it boring

Use a small number of “access groups” that correspond to network policy sets, not organizational charts.
Organizational groups change with reorgs and politics. Access groups should change with application needs.

Practical pattern:

• VPN-Accounting → FIN apps + finance shares
• VPN-Warehouse → WMS app + printers
• VPN-IT → mgmt networks + jump hosts + SSH/RDP to servers
• VPN-AllUsers → minimal baseline (DNS, NTP, endpoint management)

MFA: do it, but don’t be performative

MFA is not a policy. It’s a speed bump that helps when credentials leak.
You still need authorization controls because an attacker with a compromised session token doesn’t care about your motivational posters.

Enforcement layers: routing, firewall, and storage

Routing: control blast radius with address pools and route pushing

Assign separate VPN pools per group. This is the simplest, most audit-friendly lever you have.
It makes firewalling straightforward and makes “who did this” investigations less like reading tea leaves.

Route pushing should be minimal:

• Accounting clients get routes only to FIN-NET and shared corp services they actually need.
• Warehouse clients get routes only to WMS-NET and printer subnets.
• IT clients can get broader routes, but still prefer jump hosts for admin surfaces.

If you’re tempted to “just push 0.0.0.0/0 to everyone” to make things easy: that’s not simplicity, that’s debt.

Firewall: the adult in the room

The firewall policy should be explicit, logged, and change-controlled.
Prefer allow-lists per group. Deny by default. Log denies for debugging (but rate-limit so you don’t DDoS your own SIEM).

A solid rule structure:

• Source: VPN pool (10.66.10.0/24)
• Destination: app subnet or host group
• Service: TCP/443, TCP/445, UDP/161, etc.
• Action: allow + log (at least for admin networks)

Storage permissions: where “network access” is not enough

Finance data isn’t protected by being on FIN-NET. It’s protected by the file server enforcing permissions.
If a warehouse user can mount an SMB share and browse accounting folders, your network segmentation is decorative.

Do this properly:

• Samba/SMB: use AD-backed ACLs; map groups cleanly; avoid local users on the NAS for corporate shares.
• NFSv4: prefer NFSv4 ACLs with directory-backed identity; don’t rely on UID guessing.
• ZFS datasets: separate datasets per sensitivity class; snapshots; delegation for IT ops without data access where possible.

Joke #2: If your “access policy” is a spreadsheet and hope, congratulations—you’ve invented Compliance Theater: The Musical.

Practical tasks with commands, outputs, and decisions

These are the tasks you actually run when you’re building or debugging group-based access over one VPN.
Each task includes: a command, what typical output means, and the decision you make.
Hostnames and paths are realistic; adjust them to your environment.

1) Confirm the VPN interface is up and has the right address pool

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.0.1/16

Meaning: The gateway interface exists and is assigned the expected supernet. If you intended separate /24 pools,
the gateway may still use a larger prefix; that’s fine as long as firewall rules key off client source IP.

Decision: If the interface is missing or IP is wrong, stop and fix VPN bring-up/config before chasing “permissions.”

2) Check active VPN peers and their assigned addresses

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 3m4x...redacted
  listening port: 51820

peer: Zq1a...redacted
  endpoint: 198.51.100.24:53321
  allowed ips: 10.66.10.23/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 102.45 MiB received, 88.22 MiB sent

Meaning: This peer is using 10.66.10.23, which should correspond to a group (here: accounting pool).
A recent handshake confirms the tunnel is alive.

Decision: If a warehouse user shows up in the accounting range, your identity-to-IP assignment logic is broken.
Fix that before tweaking firewall rules; otherwise you’ll “fix” it by punching holes.

3) Verify routing for a protected subnet from the VPN gateway

cr0x@server:~$ ip route get 10.20.10.50
10.20.10.50 via 10.0.0.1 dev eth0 src 10.0.0.10 uid 1000

Meaning: The gateway knows how to reach FIN-NET (example host 10.20.10.50). If this is wrong, clients can authenticate but won’t reach anything.

Decision: If the route points somewhere unexpected (or is missing), fix internal routing/VRF before blaming VPN users.

4) Confirm IP forwarding on the gateway (classic “it connects but nothing works”)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Meaning: The gateway can route traffic between interfaces.

Decision: If it’s 0, enable it (and persist it) before debugging firewall rules.

5) Inspect nftables rules that gate VPN pools

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ip saddr 10.66.10.0/24 ip daddr 10.20.10.0/24 tcp dport { 443, 445 } accept
    ip saddr 10.66.20.0/24 ip daddr 10.30.20.0/24 tcp dport 443 accept
    ip saddr 10.66.30.0/24 ip daddr 10.40.0.0/16 accept
    counter drop
  }
}

Meaning: Default drop. Then explicit allows per VPN pool. This is what “different rights” looks like in real life.

Decision: If accounting can reach warehouse or mgmt networks, you’ll likely find an overly broad allow rule or an unexpected source range.

6) Validate that the firewall is logging the deny you care about

cr0x@server:~$ sudo journalctl -k -n 20 | grep -E "DROP|DENY" | tail
Dec 28 11:04:02 vpn-gw01 kernel: IN=wg0 OUT=eth0 SRC=10.66.20.44 DST=10.20.10.50 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=39321 DF PROTO=TCP SPT=51522 DPT=445 WINDOW=64240 SYN

Meaning: A warehouse client tried to hit SMB on a finance server, and it was blocked. Good. That’s policy enforcement doing its job.

Decision: If you see no logs, either the packets aren’t reaching the gateway (routing) or logging isn’t enabled (harder debugging).

7) Confirm what IP a user actually has (on the client side)

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.20.44/32

Meaning: Client is in the warehouse pool. This is your first sanity check when someone claims “I’m in accounting but can’t reach finance.”

Decision: If the IP doesn’t match the expected pool, fix group mapping or profile assignment, not the firewall.

8) Test reachability to an allowed service (TCP/443) and interpret failure modes

cr0x@server:~$ nc -vz -w 2 10.30.20.10 443
Connection to 10.30.20.10 443 port [tcp/https] succeeded!

Meaning: Network path and firewall allow are good for that service.

Decision: If it times out, it’s usually routing/firewall. If it’s “refused,” the host is reachable but the service isn’t listening or is blocked locally.

9) Trace path when routing is weird (especially with multiple internal hops)

cr0x@server:~$ traceroute -n 10.20.10.50
traceroute to 10.20.10.50 (10.20.10.50), 30 hops max, 60 byte packets
 1  10.66.0.1  9.214 ms  9.012 ms  9.118 ms
 2  10.0.0.1   10.202 ms  10.144 ms  10.165 ms
 3  10.20.10.50  11.011 ms  10.989 ms  10.972 ms

Meaning: You see the VPN gateway, then the internal firewall/router, then the destination. That’s the happy path.

Decision: If it dies at hop 1, it’s local client/VPN. If it dies at hop 2, it’s internal routing/firewall.

10) Verify DNS behavior per group (because “can’t reach ERP” is often “wrong name resolution”)

cr0x@server:~$ resolvectl status wg0
Link 12 (wg0)
      Current Scopes: DNS
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: no
  DNS Servers: 10.20.10.53
   DNS Domain: corp.example

Meaning: DNS for the VPN interface points to the finance DNS server (example). If warehouse users should not use this DNS,
they shouldn’t get it pushed.

Decision: If the wrong DNS is applied, fix VPN pushed DNS or client config; don’t “fix” it by opening firewall to random resolvers.

11) Confirm AD group membership for a user (authorization input)

cr0x@server:~$ id jsmith
uid=11820(jsmith) gid=10513(domain users) groups=10513(domain users),12900(VPN-Warehouse),12910(WMS-Users)

Meaning: This user is in VPN-Warehouse and should be assigned warehouse access policy.

Decision: If the user is missing the expected VPN group, fix directory membership and re-authenticate; don’t add exceptions in firewall.

12) Inspect Samba share ACLs (storage enforcement)

cr0x@server:~$ getfacl /srv/samba/finance
# file: srv/samba/finance
# owner: root
# group: "CORP\\Finance Admins"
user::rwx
group::rwx
group:"CORP\\Accounting":rwx
group:"CORP\\Warehouse":---
mask::rwx
other::---

Meaning: Warehouse has no permissions. Accounting does. This is what “different rights” looks like where the data lives.

Decision: If warehouse can read finance anyway, you likely have a different share path, inherited ACLs, or SMB guest mapping misconfiguration.

13) Confirm SMB sees the correct identity mapping (classic “permissions look right but access still wrong”)

cr0x@server:~$ wbinfo -i jsmith
jsmith:*:11820:10513:John Smith:/home/CORP/jsmith:/bin/bash

Meaning: Winbind can map the AD user to a Unix identity. If this fails, ACLs that reference AD groups won’t behave.

Decision: Fix directory integration (Kerberos, winbind, SSSD) before you touch ACLs.

14) Prove which side is dropping packets with tcpdump (use sparingly, but use it)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.66.10.23 and host 10.20.10.50 and tcp port 445 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
11:06:41.112233 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 12345 ecr 0,nop,wscale 7], length 0
11:06:42.114512 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 13345 ecr 0,nop,wscale 7], length 0

Meaning: SYNs arrive on the VPN interface; if no SYN-ACK returns, the drop is downstream (firewall, routing, host firewall, service).

Decision: If you see traffic on wg0 but not on eth0, the gateway firewall is dropping. If you see it on eth0 too, it’s downstream.

15) Check conntrack for state (especially with asymmetric routing)

cr0x@server:~$ sudo conntrack -L | grep 10.66.10.23 | head
tcp      6 117 SYN_SENT src=10.66.10.23 dst=10.20.10.50 sport=51422 dport=445 src=10.20.10.50 dst=10.66.10.23 sport=445 dport=51422 [UNREPLIED] mark=0 use=1

Meaning: The gateway sees the outbound attempt, but it’s not getting replies. That narrows the search dramatically.

Decision: Go look at internal firewall policies, return routes, and host firewall on 10.20.10.50.

16) Validate return routes on an internal server (the “works from LAN, not from VPN” classic)

cr0x@server:~$ ip route
default via 10.20.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.50

Meaning: The server’s default gateway is 10.20.10.1. If VPN clients come from 10.66.0.0/16 and 10.20.10.1 doesn’t know how to return,
replies may be black-holed.

Decision: Ensure the internal gateway knows routes back to VPN pools (or SNAT on the VPN gateway—last resort, but sometimes operationally sane).

Fast diagnosis playbook

When a user says “VPN is broken,” they mean one of five different things. Your job is to find the bottleneck in minutes, not hours.
Here’s the order that works in production.

First: identify scope and classify the failure

• One user vs one group vs everyone.
• Authentication failure vs connected but can’t reach vs can reach but no permissions.
• One app vs all internal destinations.

If it’s everyone: stop. You’re looking at gateway health, certificates/keys, routing, or upstream outage.
If it’s one group: suspect group mapping, address pool assignment, firewall rule ordering, or route pushes.
If it’s one user: suspect identity (group membership), client config, or device posture controls.

Second: check the tunnel and the assigned IP

• On gateway: wg show / OpenVPN status file / IPsec SA status.
• On client: interface IP and DNS settings.

Wrong IP range means wrong rights. That’s not a “network bug,” that’s an authorization mapping bug.

Third: test one allowed flow end-to-end

• Pick a known-good destination for that group (e.g., warehouse → WMS HTTPS).
• Test with nc or curl rather than “open a browser and vibe.”
• Watch firewall deny logs while testing.

Fourth: localize the drop

• Gateway sees packet on VPN interface?
• Gateway forwards packet out LAN interface?
• Internal firewall sees and allows?
• Destination host replies?

Fifth: only then touch storage permissions

If the network can’t reach the file server, permissions don’t matter.
If the network reaches the file server but access is denied, now you’re in ACL territory (Samba logs, effective permissions, group mapping).

Common mistakes: symptoms → root cause → fix

1) “Warehouse can see finance shares”

Symptoms: Warehouse user can browse or read finance SMB shares after VPN connect.

Root cause: Network segmentation exists, but the finance share path is accessible from a general file server VLAN; ACL inheritance or “Everyone”/“Domain Users” permissions leaked.

Fix: Put finance shares on a dedicated dataset/share with explicit deny/absence for warehouse groups; verify with getfacl and SMB effective access checks; restrict network paths so only accounting pool can reach TCP/445 on finance file servers.

2) “Accounting can’t reach ERP, but ping works”

Symptoms: ICMP succeeds; application connection fails or times out.

Root cause: Firewall allows ICMP (or it’s not filtered) but blocks TCP/443 or the app port; sometimes MTU issues cause TLS to stall.

Fix: Test with nc -vz to the exact port; review firewall rules for the accounting pool; if TLS stalls, test MTU (ping -M do -s) and clamp MSS at the gateway.

3) “IT can reach servers, but SSH randomly hangs”

Symptoms: TCP connects, then sessions freeze intermittently, especially over mobile networks.

Root cause: PMTUD blocked, causing fragmentation pain; or conntrack table pressure under load.

Fix: Enable MSS clamping on the gateway; check conntrack usage and increase limits if justified; ensure ICMP “fragmentation needed” isn’t blocked internally.

4) “User was moved to accounting, still gets warehouse access”

Symptoms: Directory group change made, but VPN rights unchanged for hours.

Root cause: Group membership cached by the VPN auth layer (RADIUS/LDAP cache) or long-lived VPN sessions not forced to re-auth.

Fix: Reduce auth cache TTL, force re-authentication on group changes, set session lifetimes; operationally: have a “rights changed → disconnect session” runbook.

5) “Everyone gets full routes despite per-group config”

Symptoms: Warehouse clients see internal routes they shouldn’t; traceroute goes places it shouldn’t.

Root cause: Default client config pushes broad routes; per-group overrides not applied or order is wrong.

Fix: Make route pushing per group explicit and test with a clean client profile; treat client configs as code, with review and staged rollout.

6) “VPN connected, but DNS resolves internal names to public IPs”

Symptoms: Users hit the wrong endpoints; SSO loops; app errors that look like auth failures.

Root cause: Split DNS not configured; client still using home/public resolvers; search domains not set.

Fix: Push correct DNS servers and domains for the group; verify with resolvectl; avoid relying on manual DNS settings on endpoints.

7) “Access works for a while then breaks after network changes”

Symptoms: After adding a new subnet or moving an app, one group loses access while others remain fine.

Root cause: Firewall objects/groups not updated; route not advertised; policy code drift between environments.

Fix: Maintain a single source of truth for subnets and policies; add change hooks: when a subnet is introduced, update route pushes and firewall rules together, then validate with connectivity tests.

8) “Finance user can’t open spreadsheets on SMB, but can list directories”

Symptoms: Directory listing works; file open fails with permissions or locking errors.

Root cause: Share-level permissions OK, NTFS/Samba ACLs wrong on files; or SMB signing/encryption requirements mismatch; sometimes opportunistic locking settings bite older clients.

Fix: Check file ACLs and inheritance, not just the top folder; verify Samba config; test with a known-good Windows client; keep SMB security consistent.

Three mini-stories from corporate life

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company consolidated remote access into a single VPN “to simplify support.” Sensible goal.
The network team carved out separate VPN pools for accounting and warehouse and called it done. Also sensible—on paper.
Then a warehouse supervisor opened a ticket: “I can see finance folders. Is that normal?”

The assumption was that if warehouse couldn’t route to FIN-NET, they couldn’t access finance data.
Unfortunately, finance shares weren’t on FIN-NET. They lived on a general-purpose file server reachable from USER-NET,
because “it’s just files” and the file server had been around longer than the segmentation project.
Network segmentation and data placement had drifted apart over the years like two colleagues who stopped talking after a reorg.

The immediate fix was ugly but effective: firewall rule blocking TCP/445 from the warehouse pool to the file server.
That stopped the bleeding but also broke legitimate warehouse file drops, because those were on the same server.
The real fix took a week: create separate Samba shares backed by separate ZFS datasets, move finance data to a finance-only dataset,
and apply AD group-backed ACLs. The warehouse share stayed accessible, finance did not.

The lesson wasn’t “network segmentation is bad.” The lesson was that segmentation without storage enforcement is a suggestion,
and attackers love suggestions.

Mini-story 2: The optimization that backfired

Another place, another “smart” idea: reduce VPN server CPU and simplify routing by SNATing all VPN client traffic to a single gateway IP.
The argument was performance and simplicity: fewer routes needed internally, less state spread across the firewall estate.
It even worked, in the way that a freshly painted wall “works” to hide a crack.

Then audit season arrived. The security team asked a straightforward question: “Which users accessed the finance app subnet last Tuesday?”
With SNAT, internal logs only showed the gateway IP. VPN logs had user identities, sure, but correlating per-flow access required stitching
together session times and guesses about which traffic belonged to which user. It was possible, but it was not defensible.

Operationally, SNAT also made troubleshooting worse. When the WMS app slowed down, app teams blamed the VPN.
The VPN team blamed the app. The firewall team had one source IP for everyone, so they couldn’t isolate noisy clients or see group-based behavior.
The system lost observability, and every incident took longer because truth had to be reconstructed.

They eventually rolled back SNAT and added proper return routes from internal networks to the VPN pools.
CPU went up a little; clarity went up a lot. That’s usually a good trade.

Mini-story 3: The boring but correct practice that saved the day

A company with strict separation between accounting and warehouse had a practice that looked painfully boring: quarterly “access reality checks.”
Not a once-a-year checkbox exercise. Quarterly. A small set of scripted tests ran from three test accounts—one per group—and verified reachability:
can accounting reach ERP? can warehouse reach WMS? can IT reach jump hosts? can warehouse not reach finance SMB?

One Friday, an internal network refresh moved the WMS servers to a new subnet. The change window ended, everyone went home,
and the on-call engineer expected peace. The quarterly test scripts, run as part of post-change validation, immediately failed:
warehouse VPN clients could no longer reach WMS. Accounting and IT were fine.

The root cause was simple: firewall rules were written with explicit old destination subnets, and the new subnet wasn’t added.
Because the validation was automated and group-scoped, the failure was detected before the night shift started scanning pallets.
The fix was a small policy update and a re-run of the tests.

Nothing heroic happened. No war room. No executives. Just a boring practice doing its boring job: preventing drama.

Checklists / step-by-step plan

Step-by-step plan for implementing group-based rights over one VPN

1. Define roles as access policies, not org units.
   Create 3–6 VPN access groups that map to reachable services.
   Avoid “VPN-Employees” turning into “VPN-Everyone-And-Their-Contractor.”
2. Create distinct VPN IP pools per access group.
   This becomes your firewall key and your audit handle.
3. Choose the enforcement boundary.
   Best: enforce at the firewall between VPN and internal segments. Good enough: enforce on the VPN gateway with nftables/iptables. Worst: “we’ll do it in apps.”
4. Push minimal routes and minimal DNS per group.
   If accounting never needs WMS, don’t advertise it. Fewer routes = fewer surprises.
5. Implement default-deny forwarding.
   Then allow explicit flows (source pool → destination subnet/hosts → ports).
6. Log denies (with sane limits) and log admin allows.
   You want enough evidence to debug and audit, not enough to melt disks.
7. Enforce on storage, not just network.
   Separate datasets/shares; apply AD group ACLs; test with real user tokens.
8. Add a jump host for IT admin access.
   Keep management interfaces off-limits directly from random hotel Wi‑Fi.
9. Define session lifetime and re-auth behavior.
   If group membership changes, sessions must refresh in a predictable time window.
10. Write validation tests per group and run them after changes.
    Connectivity tests are cheap. Outages are not.
11. Document the “why” next to the “what.”
    Rule comments should say what business capability is enabled. Otherwise rules multiply like rabbits.
12. Run a quarterly access review that includes technical verification.
    “Review the group list” is not verification. Verification is packets, logs, and ACL checks.

Operational checklist for change windows

• Before change: snapshot/export VPN and firewall configs; confirm rollback path works.
• During change: update routes, firewall objects, and DNS together for impacted apps.
• After change: run per-group reachability tests; confirm denies still deny.
• After change: check logs for unexpected drops/permits from VPN pools.

Security checklist that doesn’t sabotage operations

• MFA for user-based VPN (especially accounting and IT).
• No shared IT admin accounts; separate named accounts for privileged access.
• Break-glass access documented and tested (yes, tested).
• Rotate keys/certs; expire old profiles; revoke promptly on offboarding.
• Restrict lateral movement: VPN clients should not be able to talk to each other unless explicitly required.

FAQ

1) Can I do this with one VPN server, or do I need separate servers per department?

One server is fine if it can assign different IPs/routes based on identity and you enforce policy at a firewall.
Separate servers are sometimes used for political comfort; technically, they’re often unnecessary complexity.

2) Is it better to enforce policy on the VPN gateway or on an internal firewall?

Prefer the internal firewall boundary because it centralizes enforcement and logging for all ingress paths, not just VPN.
Gateway enforcement is acceptable for smaller setups, but it tends to grow into a rule jungle.

3) Do I need separate subnets (VPN pools) per group?

You don’t need it, but you’ll regret not doing it.
Separate pools make policies readable, debugging faster, and audits survivable.

4) What about contractors who need accounting access for a month?

Put them in a time-bound access group with an explicit expiration workflow.
Don’t add them to the main accounting group “temporarily.” Temporary is how you build permanent risk.

5) Should warehouse scanners use the same VPN method as laptops?

Not necessarily. Scanners often work better with device-based identity and locked-down routes.
If scanners are shared, user-based policies won’t map cleanly without extra device management.

6) Is split tunneling acceptable in this model?

Sometimes. If endpoints are managed and you’re minimizing backhaul, split tunnel can be sane.
For IT admin access and finance operations, full tunnel is often safer because you control DNS and egress inspection.

7) Why can’t I just rely on application logins (ERP/WMS) and skip network restrictions?

Because the network is where scanning, exploitation, and lateral movement live.
Apps protect the app; network policy reduces reachable attack surface and limits “oops I connected to the wrong thing.”

8) How do I prove to auditors that warehouse cannot access finance data?

Provide layered evidence: firewall policy showing denies (and logs of attempted access from test accounts),
plus storage ACL evidence showing finance shares deny warehouse groups. Bonus points for repeatable test scripts.

9) What’s the cleanest way to handle IT’s broad needs without giving them “the whole network”?

Use jump hosts and privileged access workflows. IT can reach the jump host; the jump host reaches management networks.
You log it. You control it. You can revoke it without rewriting every firewall rule.

10) How do we avoid policy drift over time?

Treat VPN and firewall policy as code: reviews, staged changes, and automated per-group tests.
Drift is what happens when you treat network policy like a whiteboard.

Conclusion: next steps you can execute

Group-based rights over one VPN isn’t a product feature. It’s a design discipline.
The winning approach is boring: identity → group mapping → distinct IP pools → explicit firewall policy → storage ACL enforcement → logs you can use.
Anything else is theater.

Next steps that move the needle this week:

1. Create (or clean up) three access groups: VPN-Accounting, VPN-Warehouse, VPN-IT. Make membership rules explicit.
2. Assign three VPN address pools and ensure clients land in the correct one every time.
3. Implement default-deny forwarding and write allow rules per pool to only required subnets/ports.
4. Move finance data into its own share/dataset and enforce ACLs with directory groups.
5. Build a tiny validation suite: one test account per group, five connectivity checks, and one negative test (warehouse → finance SMB must fail).
6. Operationalize: log denies, review changes, and make “rights changed → session re-auth” a documented runbook.

Do that, and “one VPN” stops being a security compromise and becomes what it should have been all along: a manageable entry point with controlled access.