XAuth Authentication

XAuth is an IKEv1-only feature. For IKEv2 connections, use EAP authentication instead — it is the standardized equivalent and offers stronger security guarantees.

XAuth (Extended Authentication, also called Mode Config Authentication) extends IKEv1/ISAKMP with an additional username/password exchange after the initial IKE Phase 1 negotiation completes. It is widely supported by legacy clients including Cisco VPN Client, Apple’s built-in IPsec client, and many mobile devices.

How XAuth Works

Phase 1 completes using either PSK or public key authentication (Main Mode or Aggressive Mode).
The gateway initiates an XAuth exchange, sending a CFG_REQUEST payload asking for username and password.
The client responds with a CFG_REPLY containing the credentials.
The gateway validates the credentials and sends a CFG_SET acknowledging success or failure.
If successful, IKEv1 Phase 2 (CHILD_SA) negotiation proceeds.

Authentication Modes

Mode	`local auth`	`remote auth`	Description
XAuth (PSK + XAuth)	`psk`	`psk` + XAuth round	PSK Phase 1, then XAuth credentials
Hybrid Mode	`pubkey`	`xauth`	Gateway uses certificate; client uses only XAuth
XAuth + pubkey	`pubkey`	`pubkey` + XAuth round	Both peers use certificates, then XAuth

Basic Configuration

Gateway (XAuth + PSK)
Gateway (Hybrid Mode)
Client

# /etc/swanctl/swanctl.conf
connections {
  ikev1-xauth {
    version = 1

    local_addrs  = 203.0.113.1
    remote_addrs = %any

    # Round 1: PSK
    local {
      auth = psk
      id   = vpn.example.org
    }
    remote {
      auth = psk
      id   = %any
    }

    # Round 2: XAuth (server requests credentials from client)
    local2 {
      auth = xauth
    }

    children {
      rw {
        local_ts  = 0.0.0.0/0
        remote_ts = dynamic
      }
    }
  }
}

secrets {
  ike-psk {
    secret = "PhaseOneSecret!"
  }

  eap-alice {
    id     = alice
    secret = "AliceXAuthPw"
  }
  eap-bob {
    id     = bob
    secret = "BobXAuthPw"
  }
}

connections {
  ikev1-hybrid {
    version = 1

    local_addrs  = 203.0.113.1
    remote_addrs = %any

    # Gateway authenticates with a certificate
    local {
      auth  = pubkey
      certs = serverCert.pem
      id    = vpn.example.org
    }

    # Client authenticates with XAuth only (Hybrid Mode)
    remote {
      auth = xauth
      id   = %any
    }

    children {
      rw {
        local_ts  = 10.0.0.0/8
        remote_ts = dynamic
      }
    }
  }
}

secrets {
  eap-carol {
    id     = carol
    secret = "CarolXAuthPw"
  }
}

connections {
  ikev1-client {
    version = 1

    local_addrs  = %any
    remote_addrs = 203.0.113.1

    local {
      auth    = psk
      id      = [email protected]
      xauth_id = alice
    }
    remote {
      auth = psk
      id   = vpn.example.org
    }

    children {
      rw {
        remote_ts = 0.0.0.0/0
      }
    }
  }
}

secrets {
  ike-psk {
    secret = "PhaseOneSecret!"
  }
  eap-alice {
    id     = alice
    secret = "AliceXAuthPw"
  }
}

Key Configuration Options

local / remote auth Values

Value	Role	Description
`xauth`	local (server)	Server will request XAuth from client
`xauth`	remote (client)	Client will respond to XAuth requests
`xauth-generic`	local	Explicitly use the `xauth-generic` backend
`xauth-pam`	local	Use PAM for credential validation
`xauth-eap`	local	Use EAP/RADIUS backend for validation

xauth_id

The xauth_id option in the local section of a client connection sets the username sent during the XAuth exchange:

local {
  auth     = psk
  xauth_id = alice
}

This allows the IKEv2 identity (id) and the XAuth username to differ — useful when the IKE identity is an IP address or FQDN but the XAuth credential is a username.

XAuth Secrets

XAuth credentials are stored in the secrets section under eap or xauth prefixes (they are aliases for one another):

secrets {
  # 'xauth' prefix is an alias for 'eap'
  xauth-alice {
    id     = alice
    secret = "AlicePassword123"
  }

  eap-bob {
    id     = bob
    secret = "BobPassword456"
  }
}

The xauth and eap secret prefixes are interchangeable. Secrets defined under either prefix are used for both XAuth and EAP authentication.

XAuth Backends

strongSwan provides multiple backends for validating XAuth credentials:

xauth-generic

Validates credentials against secrets defined in swanctl.conf (or ipsec.secrets). Best for simple, self-contained deployments.

xauth-pam

Delegates credential validation to Linux PAM. Enables integration with OS user accounts, LDAP, or any PAM-compatible backend.

xauth-eap (via eap-radius)

The eap-radius plugin registers an XAuth backend named radius. Use auth = xauth-radius to forward XAuth credentials to a RADIUS server.

Using xauth-generic

This is the default backend when auth = xauth is configured. Credentials are checked against shared secrets in swanctl.conf:

local2 {
  auth = xauth           # uses xauth-generic by default
  # or explicitly:
  # auth = xauth-generic
}

The server requests XAUTH_USER_NAME and XAUTH_USER_PASSWORD attributes from the client. It then looks up the provided username in the credential manager and performs a constant-time comparison of the password.

Using xauth-pam

local2 {
  auth = xauth-pam
}

Configure the PAM service in strongswan.conf:

# /etc/strongswan.conf
charon {
  plugins {
    xauth-pam {
      pam_service = ipsec   # PAM service name (default: ipsec)
    }
  }
}

Create the corresponding PAM service file at /etc/pam.d/ipsec.

Using xauth-radius

Requires the eap-radius plugin to be loaded and configured:

local2 {
  auth = xauth-radius
}

Configure the RADIUS server in strongswan.conf as described in the EAP-RADIUS documentation.

Comparison with EAP (IKEv2)

Feature	XAuth (IKEv1)	EAP (IKEv2)
Protocol version	IKEv1 only	IKEv2 only
Standardization	Cisco proprietary extension	RFC 3748, RFC 5996
Method negotiation	None (fixed username/password)	Flexible (MD5, MSCHAPv2, TLS, etc.)
Mutual authentication	No (server not authenticated via XAuth)	Yes (with EAP-TLS, EAP-MSCHAPv2)
MSK generation	No	Yes (with most methods)
Multiple rounds	Via IKEv1 Mode Config only	RFC 4739 Multiple Authentication
Recommended for new deployments	No	Yes

If you are deploying a new VPN infrastructure, use IKEv2 with EAP. XAuth support is primarily provided for compatibility with existing clients and legacy infrastructure.

Get Started

Configuration

VPN Scenarios

Authentication

PKI & Certificates

Plugins

Operations

Advanced Topics

XAuth Authentication

How XAuth Works

Authentication Modes

Basic Configuration

Key Configuration Options

local / remote auth Values

xauth_id

XAuth Secrets

XAuth Backends

xauth-generic

xauth-pam

xauth-eap (via eap-radius)

Using xauth-generic

Using xauth-pam

Using xauth-radius

Comparison with EAP (IKEv2)

Build docs developers (and LLMs) love

Get Started

Configuration

VPN Scenarios

Authentication

PKI & Certificates

Plugins

Operations

Advanced Topics

​How XAuth Works

​Authentication Modes

​Basic Configuration

​Key Configuration Options

​local / remote auth Values

​xauth_id

​XAuth Secrets

​XAuth Backends

xauth-generic

xauth-pam

xauth-eap (via eap-radius)

​Using xauth-generic

​Using xauth-pam

​Using xauth-radius

​Comparison with EAP (IKEv2)

Build docs developers (and LLMs) love

How XAuth Works

Authentication Modes

Basic Configuration

Key Configuration Options

local / remote auth Values

xauth_id

XAuth Secrets

XAuth Backends

Using xauth-generic

Using xauth-pam

Using xauth-radius

Comparison with EAP (IKEv2)