Building a Zero Trust Network with Access Server OpenVPN: A Step-by-Step Guide

The essence of Zero Trust Network Access (ZTNA) is security model that operates on the mantra of “never trust, always verify.” Unlike traditional VPNs, which might hand you the keys to an entire network once you’re inside, ZTNA is like a super-strict bouncer. It ensures you only get access to the specific apps or resources you’re authorized for, based on who you are, the device you’re using, and the context of your request.

In this guide, we’re diving into how to configure Access Server to embrace ZTNA principles. We’ll cover modern authentication, detailed access policies, network segmentation, and even some cool automation tricks with post-authentication scripts. The goal? To help you create a secure, zero-trust environment that’s both robust and user-friendly. Whether you’re an IT pro or just dipping your toes into networking, we’ll keep things clear, practical, and maybe even a little fun. Let’s get started!

What You’ll Need to Get Started

Before we jump into the nitty-gritty, let’s make sure you’ve got everything ready. Think of this as packing for a camping trip—you don’t want to realize you forgot the flashlight when you’re already in the woods. Here’s what you’ll need:

• Access Server Installed: You should have Access Server up and running, ideally version 2.11.0 or later for the latest features.
• Admin Access: Make sure you can log into the Admin Web UI with administrative privileges.
• Authentication Method: A modern authentication system like SAML, RADIUS, or LDAP is ideal. Bonus points if it supports multi-factor authentication (MFA). If you don’t have an external identity provider (like Okta or Active Directory), don’t worry—local authentication works too.
• Network Setup: A segmented network environment with clearly defined resources (like servers or apps) you want to protect.
• VPN Client: A supported client like OpenVPN Connect for testing your setup.
• Basic Networking Knowledge: Familiarity with concepts like the OSI model, IP addressing, and subnets will make things smoother.

Got all that? Awesome. Let’s lay the groundwork for understanding ZTNA before we start configuring.

The Core of ZTNA: Never Trust, Always Verify

At its heart, ZTNA is about being skeptical—really skeptical. It assumes every access attempt is a potential threat until proven otherwise. Instead of giving users broad access to a network (like traditional VPNs do), ZTNA enforces strict policies for every user and device. Here’s how it works in practice:

1. Verify Every Request: Every time someone tries to access a resource, their identity, device security, and context (like location or time of day) are checked.
2. Limit Access: Users only get to the specific apps or resources they’re authorized for—no wandering into restricted areas.
3. Continuous Monitoring: Policies are enforced throughout the session, not just at login.

To make this happen, you need to map out your environment. Start by documenting:

• Protected Resources: Which applications or servers need to be locked down? Think file servers, databases, or internal web apps.
• User Groups: Who needs access? Group them by roles or departments—say, accounting, sales, or IT.
• Access Conditions: What factors determine access? For example, should users only connect from certain locations or devices?

With this blueprint in mind, we’re ready to configure Access Server to enforce ZTNA principles. Let’s dive into the setup.

Step 1: Setting Up User Authentication

Authentication is the foundation of any zero-trust setup—it’s how you confirm someone is who they say they are. Access Server makes this straightforward through its Admin Web UI. Here’s how to set it up:

1. Log into the Admin Web UI: Open your browser, navigate to the Admin Web UI, and sign in with your admin credentials.
2. Head to Authentication Settings: In the menu, find the “Authentication” section and click “Settings.”
3. Choose Your Authentication Method:
   • SAML, RADIUS, or LDAP: These are great for integrating with external identity providers (IdPs) like Okta, Azure AD, or Duo. You’ll need to provide details like the metadata URL and callback settings. Check your IdP’s documentation for specifics.
   • Local Authentication: If you don’t have an external IdP, you can use Access Server’s built-in local authentication. It’s simpler but still secure, especially with MFA.
4. Enable Multi-Factor Authentication (MFA): This is non-negotiable for zero trust. MFA adds a second layer of verification, like a code from a mobile app (e.g., Google Authenticator or Authy). In the authentication settings, toggle MFA on and configure it per your IdP’s instructions.

Why bother with MFA? Imagine someone steals a user’s password. Without MFA, they’re in. With MFA, they’re stuck unless they also have the user’s phone or token. It’s like locking your door and setting an alarm.

Once authentication is set, you’ve built the first layer of your zero-trust fortress. Now, let’s control who gets to go where.

Step 2: Creating User Groups and Access Policies

Zero trust isn’t just about verifying identity—it’s about ensuring users only access what they need. This is where user groups and access policies come in. By organizing users and defining strict permissions, you can lock down your network like a vault.

Here’s how to do it in Access Server:

1. Create User Groups:
   • In the Admin Web UI, go to the “User Management” or “Groups” section.
   • Create groups based on roles or departments. For example:
     • Accounting: Access to financial software and file servers.
     • Sales: Access to CRM tools and customer databases.
     • IT: Access to admin tools and infrastructure.
   • Assign users to these groups manually or, if you’re using SAML/LDAP, map them automatically (more on that later).
2. Define Access Policies:
   • Navigate to the “Access Control” section for each group.
   • Enable user access control by setting it to “Yes.”
   • Specify which resources the group can access:
     • Networks: Define subnets (e.g., 192.168.1.0/24) to allow access to entire network ranges.
     • Services: Use the format network:port:protocol (e.g., 192.168.1.10:80:tcp) for specific apps like web servers.
   • Want users in one group to talk to another? Go to “Allow Access to Groups” and select the relevant group.
   • Need to grant access to specific users outside the group? Use the “Allow Access to Users” section.
3. Save and Update:
   • Click “Save Settings” to store your changes.
   • Hit “Update Running Server” to apply them immediately.

This setup ensures users only reach their authorized resources. For example, an accounting team member can access the payroll app but can’t poke around in the IT department’s servers. It’s like giving everyone their own lane on a highway—no swerving allowed.

Step 3: Supercharging Zero Trust with Post-Authentication Scripts

Now that you’ve got authentication and access policies in place, let’s take things up a notch with post-authentication scripts. These are like little robotic gatekeepers that automate security decisions after a user logs in. They let you enforce dynamic rules based on factors like user attributes, device details, or even location. Here are three powerful ways to use them:

1. Automate Group Mapping

If you’re using SAML, LDAP, or RADIUS, manually assigning users to groups can be a hassle. Post-authentication scripts can do it for you.

• How It Works: The script reads attributes from the authentication response (e.g., a user’s department in LDAP). It then maps the user to the corresponding Access Server group.
• Example: An LDAP user with the attribute department=accounting gets automatically placed in the “Accounting” group with predefined access policies.
• Why It’s Great: No more manual assignments. It saves time and reduces errors, ensuring users only get the access they’re supposed to have.

2. Enforce Device-Based Verification

Zero trust loves devices that are known and trusted. You can use scripts to verify a device’s identity before granting access.

• How It Works: The script captures a device’s unique identifier, like its MAC address or UUID, during login. Access is only granted if the device is registered to the user.
• Example: A user tries to connect from a new laptop. The script checks if the laptop’s UUID is on the approved list. If not, access is denied until the device is registered.
• Why It’s Great: This stops attackers from using stolen credentials on unauthorized devices, adding a hardware-level security check.

3. Implement Location-Based Access

Location matters in zero trust. Scripts can restrict access based on a user’s IP address, blocking logins from unfamiliar places.

• How It Works: The script maintains a list of “safe” IP addresses or ranges for each user. If a login comes from an unrecognized IP, it’s denied.
• Example: A user logs in from the office IP (192.168.1.100) and gets access. If they try from a coffee shop Wi-Fi (203.0.113.5), the script blocks it unless the new IP is approved.
• Why It’s Great: This helps stop phishing attacks or logins from compromised locations, keeping your network secure even if credentials are leaked.

Setting Up Post-Authentication Scripts

Ready to implement these? Here’s the process:

1. Access the Script:
   • You’ll need a Python script tailored to your needs. Access Server supports one post-authentication script at a time, so combine functions (group mapping, device checks, etc.) into a single file if needed.
   • For examples, check OpenVPN’s official documentation online (search for “Access Server post-authentication scripts”). You’ll find sample scripts for things like IP-based restrictions.
2. Install the Script:
   • Log into your server via SSH.
   • Download or create your Python script. For example, to restrict access by IP:
     wget <script-url> -O post_auth.py
   • Edit the script if needed (use nano or vim) to customize rules, like defining safe IPs or group mappings.
   • Save it to the appropriate directory (usually specified in Access Server’s config).
3. Activate the Script:
   • In the Admin Web UI, go to the “Authentication” section and enable post-authentication scripting.
   • Point to your script’s file path.
   • Reload Access Server to apply the changes:
     /usr/local/openvpn_as/scripts/sacli --key "vpn.server.post_auth_script" --value "/path/to/post_auth.py" ConfigPut /usr/local/openvpn_as/scripts/sacli start
4. Test It Out:
   • Log in as a test user (let’s call them Matt).
   • For an IP-based script, the first login registers Matt’s IP. Subsequent logins from that IP should work, but trying from a different IP (say, another machine) should fail.
   • Check the logs to confirm the script’s behavior.

Pro Tip: Structure your script carefully. If you’re combining multiple functions, test each one to ensure they don’t conflict. A poorly written script could accidentally block legitimate users or let threats slip through.

Step 4: Implementing Network Segmentation

Authentication and policies are great, but zero trust also demands a segmented network. Think of it like dividing your house into rooms with locked doors—only authorized people get into specific areas. Access Server offers two main tools for this: NAT (Network Address Translation) and routing. Let’s break them down.

Option 1: NAT (Network Address Translation)

NAT is the default mode in Access Server, and it’s perfect for most zero-trust setups because it’s simple and secure.

• How It Works: NAT translates the VPN client’s IP address into the Access Server’s local private IP when accessing resources. The private network sees traffic as coming from the Access Server, not the client directly.
• Example: A client with IP 10.0.0.2 accesses a web server at 192.168.1.10. The server sees the request as coming from the Access Server’s IP (e.g., 192.168.1.1), not 10.0.0.2.
• Benefits:
  • One-way traffic: Clients can reach resources, but the private network can’t initiate connections to clients.
  • No extra routes needed: The target system treats traffic as local, so you don’t need to mess with gateways.
  • Acts like a firewall, keeping clients safe from direct access by the private network.
• When to Use: Ideal for accessing web servers, file servers, or apps where clients don’t need to be directly reachable.

To set up NAT:

• In the Admin Web UI, go to “VPN Settings” or “Routing.”
• Ensure “NAT” is selected (it’s the default).
• Define the subnets or services clients can access in the access control settings (like we did in Step 2).

Option 2: Routing

Routing is more complex but allows two-way communication between the VPN clients and the private network.

• How It Works: Access Server forwards traffic from the VPN client subnet (e.g., 10.0.0.0/24) directly to the private network (e.g., 192.168.1.0/24) without translation. The private network can also send traffic back to the client subnet.
• Example: A VoIP server at 192.168.1.20 needs to send data to a client at 10.0.0.3. Routing allows this direct communication.
• Setup Requirements:
  • Add a static route on the private network’s default gateway to point to the VPN client subnet via the Access Server.
  • Example: On the gateway, add:
    ip route add 10.0.0.0/24 via <Access-Server-IP>
• Benefits:
  • Enables two-way traffic, which is critical for apps like VoIP or peer-to-peer systems.
  • More flexible for complex network needs.
• When to Use: Choose routing for scenarios where NAT’s one-way restriction breaks things, like VoIP or certain database systems.

To set up routing:

• In the Admin Web UI, go to “VPN Settings” or “Routing.”
• Select “Routing” instead of NAT.
• Specify the client subnet and ensure the private network’s gateway has the static route.

Pro Tip: Stick with NAT unless you specifically need two-way communication. It’s easier to manage and inherently more secure for zero trust because it limits exposure.

Step 5: Monitoring and Fine-Tuning

A zero-trust network isn’t a “set it and forget it” deal. You need to keep an eye on things to ensure policies are working and no one’s sneaking through the cracks. Here’s how to stay on top of it:

1. Check Logs Regularly:
   • Access Server’s logs (found in the Admin Web UI under “Log Reports” or via SSH at /var/log/openvpnas.log) show login attempts, policy enforcement, and script actions.
   • Look for anomalies, like repeated failed logins or access from unusual IPs.
2. Test Policies:
   • Periodically log in as different users to confirm they only access authorized resources.
   • Try breaking things (ethically!)—attempt logins from untrusted IPs or unregistered devices to verify restrictions work.
3. Adjust Policies:
   • As your organization changes (new apps, new teams), update groups and access rules.
   • If a script is too strict (e.g., blocking legit users), tweak its logic or add exceptions.
4. Monitor Performance:
   • Heavy scripting or complex policies can slow things down. Watch for lag in login times or resource access.
   • Optimize scripts by reducing unnecessary checks or caching common queries.

By staying proactive, you’ll keep your zero-trust setup tight and effective.

Why ZTNA Matters (And Why This Setup Rocks)

Let’s zoom out for a second. Why go through all this effort? Traditional VPNs are like giving someone a master key to your house—once they’re in, they can roam freely. ZTNA, on the other hand, is like handing them a single-use ticket to one room, with a guard checking their ID at every step. In today’s world of phishing, ransomware, and remote work, that level of control is critical.

Here’s what makes this Access Server setup so powerful:

• Granular Control: You decide exactly who accesses what, down to the app or subnet.
• Dynamic Security: Scripts adapt permissions based on real-time factors like location or device status.
• Scalability: Whether you have 10 users or 10,000, groups and automation make management easy.
• Flexibility: NAT, routing, and modern authentication mean you can tailor the setup to your needs.

Plus, it’s not just about locking things down—it’s about doing so without making life miserable for users. A well-configured ZTNA setup lets people work securely without jumping through endless hoops.

Troubleshooting Tips

Even the best setups hit snags. Here are common issues and fixes:

• Users Can’t Connect: Check authentication settings. Ensure MFA is configured correctly and IdP details are accurate.
• Access Denied Unexpectedly: Review group policies and script logic. A typo in a subnet or an overzealous script might be the culprit.
• Slow Performance: Simplify scripts or reduce policy complexity. Check server load and consider upgrading hardware if needed.
• Script Errors: Debug by checking logs (/var/log/openvpnas.log). Ensure Python dependencies are installed and the script has proper permissions.

When in doubt, OpenVPN’s documentation and community forums are goldmines for solutions.

Wrapping Up

Congratulations—you’ve just built a zero-trust network with Access Server! From setting up modern authentication to enforcing granular policies, segmenting your network, and automating security with scripts, you’ve created a fortress that’s both secure and practical. Zero trust isn’t about paranoia; it’s about being smart in a world where threats are everywhere. By following the principle of “never trust, always verify,” you’re ensuring your resources stay safe while users get the access they need.

Keep monitoring, testing, and tweaking your setup to stay ahead of risks. And hey, give yourself a pat on the back—you’re not just running a network; you’re running a secure network. That’s something to be proud of.