Skip to content

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

By leveraging an encrypted WireGuard-based peer-to-peer overlay, client connectivity is not only lightning-fast but also context-aware. Beyond strong authentication, AXS One also integrates rigorous security posture checks to ensure that every connecting endpoint meets specific corporate security standards, such as required OS versions or the presence of active antivirus and EDR agents.

Bandwidth Management Concept

Context-Sensitive Help

This document provides system administrators and IT professionals with the procedures required to configure the AXS One VPN server. To assist with the configuration 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.

image

Requirements

Internet Reachability

The AXS One VPN server 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 connect to your AXS One VPN 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 AXS One VPN 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.

The Private CA Approach (Self-Signed)

In the world of Zero Trust Network Access (ZTNA) and modern VPNs, the identity of the gateway is the foundation of the entire connection. While you can use a private CA to sign the server certificate, the industry standard pushes for public, commercial CAs to solve a very specific problem: Universal Trust.

  • Why Public CAs are the Standard: When a server uses a certificate from a public, commercial Certificate Authority (like DigiCert or Let’s Encrypt), it is leveraging a pre-existing "Circle of Trust."
  • Pre-installed Root Stores: Operating systems (Windows, macOS, Linux, iOS, Android) and browsers come with a built-in list of trusted public CAs.
  • Zero-Touch Validation: Because the client already knows and trusts the public CA, it can immediately verify the server's identity without any manual configuration.
  • Security Compliance: Many ZTNA brokers and modern browsers strictly enforce policies like Certificate Transparency (CT) and Revocation checks (OCSP/CRL), which are managed automatically by public CAs but often neglected in private setups.

The Private CA Approach (Self-Signed)

Using a private or self-signed CA is supported, but it changes the deployment from "plug-and-play" to a manual configuration task.

When using a private CA, the client’s device has no idea who that CA is. When the AXS One client attempts to connect, the handshake will fail because it assumes the connection is being intercepted by an attacker (a Man-in-the-Middle attack).

The Requirement: Importing the CA Certificate

To make it work, system administrators must manually bridge that trust gap:

  1. Export the Root CA: System administrators must obtain the Root CA certificate file from the private issuing authority.
  2. Distribute to Clients: This certificate must be imported into the Trusted Root Certification Authorities store on every single end-user device.
  3. Scalability Issues: While this is easy for one person, in an enterprise context, this usually requires an MDM (Mobile Device Management) tool or Group Policy (GPO) to push the certificate to hundreds of machines.

Note: If the client doesn't have the private CA certificate installed, the AXS One VPN client will block the connection entirely to maintain the Zero Trust posture, as an unverified identity is treated the same as a compromised one.

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.

    image

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.

    image

Server Configuration

Connection Settings

  1. Navigate to VPN > AXS One VPN > Server.
  2. Enable the AXS One VPN Server.
  3. Use the default connection settings, as shown in the example below.

    image

Push-to-Client Configuration

  1. Select the Push-to-Client configuration tab.
  2. Adjust the settings to fit your needs.
  3. Proceed to the next tab.

    image

Local Access Server

  1. Select the Local Access Server tab.
  2. Enter the hostname that matches your server certificate and public DNS record.
  3. Select the server certificate that you previously imported.
  4. Specify the connection port for the access server. TCP port 443 is the recommended default.
  5. Save your configuration.

    image

Granting VPN Access

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

Configuration Level Access Scope Implementation Logic
Group Level Bulk Access Enable at this level to grant access to all group members.
User Level Selective Access Only necessary if the user's group lacks access but the individual requires it.
Default State No Access Access is restricted until an administrator explicitly enables one of the above.

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.

    image

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.

    image

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.

    image

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.

    image

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. Update your configuration.

    image

System Status

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

  1. Navigate to System > Status > Services.
  2. Search for axsone.

    image

Client Information

Connection History

The clients page provides a high-level overview of active and past user sessions. It logs the machine name, username, and both internal and external IP addresses, alongside a timestamp for the last connection event.

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

    image

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

    image

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.

  1. Navigate to VPN > AXS One VPN > Client Status.
  2. Click on a machine name to view its connection history.

    image

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.

    image

Server Logs

  1. Navigate to VPN > AXS One VPN > Logs.
  2. Select the desired log type.

    image

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

    image

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.

Event Category Example Log Message Description
Service Lifecycle starting AXS One service The Exit Node daemon is launching and initializing local resources.
System Check system supports advanced routing Verifies kernel capabilities (eBPF) required to route traffic for other clients.
Management Sync connected to the Signal Service stream Confirms the Exit Node has checked in with the Management Server for policy updates.
ICE Negotiation sending offer / received offer The process of allowing external peers to find a path to this Exit Node.
Interface Setup Netbird engine started... 10.255.251.1/24 The virtual WireGuard interface is created on the appliance.
Connection Success connection succeeded with offer session Confirms a peer has successfully shook hands with this Exit Node.
WireGuard Status first wg handshake detected Validates that encrypted data is successfully flowing between a client and the Exit Node.
Health Monitoring Dump stat: Status: Connected A periodic summary of active peer connections and relay usage.

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.

Event Category Example Log Message Description
Database Init using SQLite store engine Initializing the database that stores network policies and peer configurations.
Schema Migration No migration needed for accounts Checks if the database structure matches the current software version.
IdP Integration warmed up IDP cache with 1 entries Synchronizing user identities from the Auth Server to apply access rules.
API Activity request GET /api/users took 4 ms Records administrative changes made via the dashboard or CLI.
Audit Logging "operation":"setupkey.add" A JSON record of state changes (e.g., creating keys) for compliance.
IP Allocation Got ip check if it is reserved: 10.255.251.17 Authorization: Assigning a specific internal VPN IP to a registered peer.
Peer Lifecycle Login request from peer [...] Tracks when a client attempts to join and checks if they are authorized to do so.
Policy Tracking saving peer status [...] is connected: true Updates the dashboard to reflect which peers are currently authorized and online.
Key Management PAT usage in last minute: 1 unique tokens Monitoring the use of Access Tokens for programmatic control.

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.

Operation Description Key Meta-Data Captured
personal.access.token.* Lifecycle of PATs used for API automation. Token name and associated user ID.
network.resource.* Addition or removal of specific network subnets. Resource name, type, and network ID.
network.router.* Changes to routing nodes (Exit Nodes) directing traffic. Peer ID acting as the router.
policy.update Changes to access control rules between client groups. The specific policy name.
setupkey.* Creation/revocation of keys for automated registration. Key type and truncated value.
user.join Triggered when a new IdP user logs in for the first time. Unique account ID and target user ID.
peer.user.add Official registration of a new device/node. FQDN, internal IP, and source IP.
peer.group.add Assigning a peer to a group (defining access levels). Peer FQDN and Group Name.
peer.status.update Real-time connectivity changes (online/offline). Connection status and last seen timestamp.

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.

Event Category Example Log Message Description
System Banner zitadel Startup logs showing version and core TLS/Console configurations.
Service Config External Secure : true Confirms the IdP is correctly recognizing the HTTPS proxy.
Token Verification decrypt access token Validating the JWT (JSON Web Token) provided by a client.
Auth Failure error="invalid token" A security event: an expired or unauthorized attempt to authenticate.
Health Monitoring Health Check URL : .../debug/healthz Verification that the identity service is responsive.

TURN & STUN 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.

Event Type Example Log Message Description
System Init Coturn Version 4.7.0 Hardware and version info during the boot sequence.
Network Config Listener address: 192.168.100.211 The IP/Port where the server listens for STUN/TURN requests.
Security/Cipher TLS 1.3 supported Encryption standards available for the data relay.
Resource Limits max supported TURN Sessions: 2000 The maximum capacity for simultaneous relayed connections.
Session Usage rp=1, rb=20, sp=1, sb=40 Bandwidth metrics (packets/bytes received and sent).
Session Closure reason: allocation watchdog... Termination of a session due to inactivity or client disconnect.

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

Event Type Details Captured Description
Service Start running HTTP server... The server is ready to facilitate "matchmaking" between peers.
Peer Registration registering new peer A client has connected to the Signal server to announce its presence.
Peer Identification peer registered [Key...] The server identifies the peer via its public key to route signaling data to it.
Peer Connected streamID 177381... A persistent WebSocket is open; the peer can now receive "where are you" requests.
Stream Closing peer stream closing The signaling link is cut (e.g., app closed or lost Wi-Fi).
Peer Deregistered peer deregistered [Key...] The peer is removed from the "active" list and is now unreachable for signaling.

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