AXS One VPN Server

Introduction

About AXS One

AXS One is a next-generation secure access solution built upon the high-performance WireGuard architecture. Unlike traditional VPNs that provide broad, perimeter-based network entry, AXS One adopts a Zero Trust Network Access (ZTNA) model, operating on the principle of "never trust, always verify", requiring an explicit trust approval by a system administrator before any endpoint can establish a connection.

By leveraging an encrypted WireGuard-based peer-to-peer overlay, client connectivity is not only lightning-fast but also context-aware. Beyond strong authentication and administrator authorization, AXS One also integrates rigorous security posture checks to ensure that every admin-approved endpoint meets specific corporate security standards.

Context-Sensitive Help

This document provides system administrators and IT professionals with the required steps to set up a minimal, basic configuration of the AXS One VPN server. To assist with the setup process, context-sensitive help is available directly within the interface; simply click the blue i icon located next to any configuration field for detailed descriptions and requirements.

Connectivity Modes

By default, management and configuration traffic between AXS One clients and the AXS Guard appliance is securely proxied through the AXS Guard Cloud (Appliance Proxy). This means no public certificate, public DNS record, or direct Internet reachability is required on the appliance for this purpose.

Alternatively, system administrators can enable the Local Access Server, which allows management and configuration traffic to be routed directly to the appliance instead of routing it through the AXS Guard Cloud. This is entirely optional. If enabled, the Local Access Server Requirements apply.

Local Access Server Requirements

Internet Reachability

The AXS One VPN server and its subcomponents must be reachable from the public Internet to allow remote peers to establish a tunnel. This requires that the server is accessible via a routable public IP address.

Public DNS Record

To allow users to establish a VPN connection via the local access server, you need a public DNS record (A record) that points to the server's public IP address. Refer to your DNS provider's documentation for specific instructions on creating an A record.

Server Certificate

The domain name of the access server must be secured by a valid certificate signed by a recognized commercial Certificate Authority (CA). Please note that the AXS One VPN client will, by default, reject self-signed certificates or those issued by an untrusted CA.

Pre-Configuration

Feature Activation

1. Log in to your AXS Guard appliance.
2. Navigate to Feature Activation > VPN.

3. Enable the AXS One VPN feature and update your configuration.

   

Certificate Import

1. Navigate to PKI > Certificates.
2. Click on the Import button to import your server certificate.

3. Enter the required information and click on the Save button.

   

Server Configuration

Connection Settings

1. Navigate to VPN > AXS One VPN > Server.
2. Enable the AXS One VPN Server.
3. Enable Trusted Clients for strict posture checks (recommended).
4. Enter the Outgoing IP for your organization.

5. Use the default connection settings, as shown in the example below.

   

6. Under VPN Client Properties, review the following fields:

   Field	Description
   Management URL	Read-only field showing the URL that must be configured on AXS One clients to reach the management server. Its value depends on whether the Local Access Server is enabled: with the default Appliance Proxy mode, this is https://<license-number>.axsone.axsguard.cloud; if the Local Access Server is enabled, this shows the hostname (FQDN) configured there instead.
   IP Range	The private IP subnet used to assign internal VPN addresses to connecting clients. Use a private range outside any existing subnet which is in use. Each client is assigned a unique IP address from this range, so its size determines the maximum number of clients that can be configured. Once an address has been assigned to a client, it remains reserved for that client only, whether or not the client is currently connected.

Push-to-Client Configuration

1. Select the Push-to-Client configuration tab.
2. Add the networks that should be reachable through the VPN, using the CIDR notation.

3. Proceed to the next tab.

   

Local Access Server

1. Select the Local Access Server tab.
2. Enable the local access server.
3. Enter the hostname that matches your server certificate and public DNS record.
4. Select the server certificate that you previously imported.
5. Enter the desired Access Server Port .

6. Save your configuration.

   

GeoIP Restrictions

About

Since the AXS One Local Access Server must be reachable from the public Internet (see Internet Reachability), its exposed Access Server Port is a potential target for scanning, brute-force attacks and other exploitation attempts originating from anywhere in the world.

To reduce this attack surface, it is recommended to restrict inbound access to the AXS One Local Access Server port to countries or regions where your organization has legitimate remote users, such as home offices, traveling employees, or branch locations. Connection attempts from all other regions should be blocked before they ever reach the authentication or posture-check layer.

This is achieved using the AXS Guard GeoIP filtering feature.

Recommended Approach

Rather than applying a global GeoIP filter, which blocks traffic system-wide across all AXS Guard services, it is recommended to scope the restriction specifically to the AXS One VPN server endpoint using a granular GeoIP configuration. This avoids unintentionally restricting other publicly-reachable services, such as mail or the reverse proxy, that may need to remain accessible from a broader set of regions.

To configure a granular GeoIP restriction for AXS One:

1. Navigate to Firewall > Rules > Towards.
2. Click Add New to create a custom rule.
3. Configure the rule as follows:
   • Device In: Internet
   • Destination Port: the Access Server Port that you configured for AXS One.
   • Source List: select the GeoIP list(s) corresponding to the countries or regions that should be allowed.
   • Target: Accept
4. Save the rule, then add it to a static policy positioned above the default deny policy (e.g. stat-int). See Reordering Static Policies for guidance on rule and policy order.
5. Update your configuration.

Connection attempts to the AXS One server from countries not included in the source list will be dropped by the system's default zero-trust policy, without ever reaching the authentication server.

Granting VPN Access

User access to AXS One is not granted by default; system administrators must explicitly enable access for each user or group.

Group-level Access

1. Navigate to Users & Groups > Groups.
2. Select the appropriate group.
3. Select the VPN tab and enable the AXS One VPN option.

4. Update your configuration.

   

User-level Access

1. Navigate to Users & Groups > Users.
2. Select the appropriate user.
3. Select the VPN tab and set the AXS One VPN option to on (select group configuration if the user's group already has access).

4. Update your configuration.

   

Firewall & Application Control

In a secure VPN architecture, firewall and application control policies serve as crucial mechanisms for enforcing the Principle of Least Privilege (PoLP). Rather than granting broad network access, these controls restrict remote users to the specific IP addresses, ports, services and verified applications that are essential to their roles. System administrators should implement appropriate firewall and application control policies to eliminate unnecessary lateral movement and reduce the attack surface. This allows potential threats to be contained within a narrow, monitored channel should an incident arise.

Group-level Settings

1. Navigate to Users & Groups > Groups.
2. Select the appropriate group.
3. Select the VPN tab to add the appropriate firewall and application control policies.

4. Update your configuration.

   

User-level Settings

1. Navigate to Users & Groups > Users.
2. Select the appropriate user.
3. Select the VPN tab to configure user-specific firewall and application control policies (for example, to override the user's default group policies when custom access is required).

4. Update your configuration.

   

User Authentication Policy

1. Navigate to Authentication > Services.
2. Click on the AXS One VPN service.
3. Configure the appropriate authentication policy (2FA is highly recommended).
4. Make sure to enable brute-force attack protection.

5. Update your configuration.

   

System Status

From the Services page, system administrators can verify the health of individual AXS One VPN server components and use the Restart function for troubleshooting or maintenance.

1. Navigate to System > Status > Services.

2. Search for axsone.

   

Clients

The clients page provides a high-level overview of active and past user sessions. It logs the machine name, username, internal and external IP addresses, and a timestamp for the last connection event. Additionally, it mentions whether clients are trusted or not.

Trusting a Client

With trusted clients enabled, system administrators must explicitly trust endpoints before they can connect to the corporate network. This can only be done after a user successfully establishes a connection with the AXS One client. Trust only needs to be granted once per new client, on its first connection attempt. After initial approval, the client can freely reconnect anytime without admin intervention.

1. Navigate to VPN > AXS One VPN > Clients.

   

2. Click on the name of the machine to be trusted.

   

3. Click on the Trust Client button.

   

4. Click OK to confirm.

   

Connection History

1. Navigate to VPN > AXS One VPN > Clients.

   

2. Click on a machine name to view its connection history.

   

Client Status

The client status page provides real-time monitoring of active sessions, specifically highlighting the status column to confirm successful connectivity. A green connected status indicates an active, healthy link between the client and the server.

Authentication Status

The authentication status page allows administrators to view all active users and log them out remotely.

1. Navigate to Authentication > Status > Authenticated Users > Firewall, Proxy & VPN.

2. Click on the logout link to log out a user.

   

Server Logs

1. Navigate to VPN > AXS One VPN > Logs.

2. Select the desired log type.

   

3. Click on the appropriate date to inspect the logs.

   

Client Summary

Parsed logs containing a summary of the client login, connect, disconnect flow. These logs are aggregated from the different AXS One VPN subservices, filtered and parsed to show the most important steps in the login, connect, disconnect flow for each client.

The following log actions can occur:

Normal connection flow

A normal connection flow looks like this:

A new connection will always first be relayed while the Gateway server searches for a direct VPN tunnel path to the client.

Gateway Server

The Gateway Server is a specialized AXS One client running on the appliance, configured as an Exit Node. While it functions as a client, it is the central hub allowed to connect to all other clients. These logs document the connection setup phase specifically for this node. They are the primary tool for verifying if external clients are successfully establishing a path to the Exit Node.

WireGuard

Parsed WireGuard logs. These logs contain VPN tunnel updates for connected AXS One VPN clients.

Management Server

The Management Server acts as the Control Plane and Authorization Engine. It does not perform authentication (that is handled by the Authentication Server), but it dictates Authorization: telling clients which peers they are allowed to see, providing their WireGuard configurations, and managing network policies.

Audit Events

The audit event logs provide a high-fidelity, JSON-structured record of every significant administrative and state change. While Management logs show background processes, audit logs focus on the "Who, What, and When" for security monitoring.

Authentication Server

Powered by Zitadel, this is the Identity Provider (IdP). These logs focus strictly on the Identity Layer—ensuring that the user or machine is who they claim to be before the Management server grants them access.

TURN Server

The TURN server acts as a relay for traffic when firewalls prevent a direct connection. Critically, it also provides STUN (Session Traversal Utilities for NAT) services, allowing clients to discover their own public-facing IP addresses to facilitate direct connections.

Signal Server

The Signal Server is the "matchmaker." It uses WebSockets to help peers exchange connection metadata (IPs and ICE candidates). While it identifies peers by their keys to route signals, it does not manage WireGuard keys (that is the Management Server's job).

Support

If you encounter a problem

If you encounter any issues with AXS One VPN, don't hesitate to reach out to our technical support department.

Contact Information

(+32) 15-504-400
support@axsguard.com