This article explains how to create and apply a Linux VPN Policy that configures enrolled Linux devices to use IPsec/IKEv2 VPN via RADIUS authentication. The policy supports:

RADIUS-backed IPsec VPN using SCEPman for certificate issuance
Traditional manual IPsec configurations (if you choose “manual” instead of “radius”)
Optional OpenVPN profiles for environments that use OpenVPN instead of IPsec

By pushing this policy, you ensure enrolled Linux endpoints automatically receive the correct IPsec configuration, RADIUS/SCEPman settings, and VPN certificates.

Prerequisites

Before creating the policy:

Swif agent installed on your Linux device(s)
Access to your Swif admin console
A working RADIUS + IPsec VPN infrastructure, for example:
- A VPN gateway that supports IKEv2/IPsec with EAP-TLS or certificate-based auth
- A RADIUS server integrated with your VPN gateway
- SCEPman (or equivalent) configured as your certificate authority
The details for SCEPman (Tenant ID, Client ID, Client Secret, API App ID, Service Domain)

Policy Overview

Policy name in Swif: Linux VPN Policy
Policy type: LINUX_VPN_POLICY
Supported platform: Linux
Ownership: Company-owned and BYOD

The policy has two main sections:

openVpnConfigurationList – optional list of OpenVPN profiles
ipsecConfigurationList – list of IPsec VPN configurations
- Each IPsec config can be:
  - configureType: "manual" – manual IPsec (swanctl) configuration
  - configureType: "radius" – RADIUS VPN configuration with SCEPman certificates (focus of this article)

When using RADIUS mode, Swif:

Requests and manages VPN certificates from SCEPman
Writes the required strongSwan/swanctl configuration files
Ensures strongSwan service is enabled and running on the device

Step 1: Create a Linux VPN Policy with RADIUS

In your Swif admin console, create a new policy of type Linux VPN Policy (LINUX_VPN_POLICY).

For a pure RADIUS VPN setup, you can leave openVpnConfigurationList empty and define one or more entries in ipsecConfigurationList with configureType: "radius".

Example RADIUS VPN Policy JSON

Below is a minimal example focused on RADIUS/SCEPman (based on ST‑6666):

{
  "policyName": "Linux VPN Policy",
  "policyType": "LINUX_VPN_POLICY",
  "policy": {
    "openVpnConfigurationList": [],
    "ipsecConfigurationList": [
      {
        "name": "swif-radius",
        "configureType": "radius",
        "radiusConfigurationList": [
          {
            "name": "swif",
            "remoteId": "vpn.example.com",
            "remoteAddrs": "203.0.113.10",
            "scepmanConfiguration": {
              "tenantID": "YOUR_TENANT_ID",
              "clientID": "YOUR_CLIENT_ID",
              "clientSecret": "YOUR_CLIENT_SECRET",
              "scepmanApiAppId": "YOUR_SCEPMAN_API_APP_ID",
              "scepmanServiceDefaultDomain": "YOUR_SCEPMAN_SERVICE_DOMAIN"
            }
          }
        ]
      }
    ]
  }
}

Key fields for RADIUS mode:

ipsecConfigurationList[].name
Human-readable name for this IPsec VPN configuration (for example, swif-radius).
ipsecConfigurationList[].configureType
- "radius" – enables RADIUS VPN configuration mode
- (When "radius" is used, Swif hides the manual IPsec connection fields and only shows the RADIUS-related section.)
radiusConfigurationList[]
List of RADIUS-backed VPN profiles. Required fields include:
- name – Name of the RADIUS/VPN profile (e.g., swif)
- remoteId – Identity of the VPN server used during IKEv2/IPsec handshake.
  This must match the server certificate’s CN or SAN, usually the VPN server FQDN (for example, vpn.example.com).
- remoteAddrs – Comma-separated list of VPN gateway addresses (IP or DNS), e.g. 203.0.113.10 or vpn.example.com
scepmanConfiguration
SCEPman configuration for obtaining client certificates:
- tenantID – Azure AD tenant ID used by SCEPman
- clientID – Azure application (client) ID used by Swif to talk to SCEPman
- clientSecret – Client secret for the above application
- scepmanApiAppId – SCEPman API application ID (e.g., api://...)
- scepmanServiceDefaultDomain – SCEPman base URL domain
  (e.g., app-scepman-yourcompany.azurewebsites.net)

For more background on SCEPman configuration, you can refer to your existing RADIUS Wi‑Fi + SCEPman article:
https://help.swif.ai/en/articles/10694075-how-to-configure-swif-ai-radius-wi-fi-policy-using-scepman-as-the-scep-certificate-provider

Step 2: (Optional) Manual IPsec Configuration

If you want to use manual IPsec configuration instead of RADIUS, you can set:

"configureType": "manual"

When configureType is "manual", the following sub-sections become visible and applicable:

ipsecConnectionList – IKE connection parameters (version, proposals, local/remote addresses and ports, traffic selectors, etc.)
ipsecSecretList – strongSwan secrets (IDs and secrets)
ipsecCACerts – CA certificates to place under /etc/swanctl/x509ca/

These map directly to strongSwan’s swanctl.conf and certificate/secret layout. However, manual configuration is not required for the RADIUS + SCEPman scenario described in this article.

Step 3: Assign the Linux VPN Policy to a Device or Group

In the Swif admin console, go to Policies.
Create or edit a Linux VPN Policy and ensure ipsecConfigurationList is configured with configureType: "radius" as above.
Assign the policy to:
- A specific Linux device, or
- A group / smart group of Linux devices
Save and deploy the policy.

The Swif agent on each Linux endpoint will:

Request a VPN certificate from SCEPman based on the scepmanConfiguration.
Write the appropriate strongSwan/swanctl configuration files.
Ensure the strongSwan service is enabled and running.

Step 4: Verify Certificate and VPN Configuration on Linux

After the policy is applied and the device has checked in, verify that the certificates and strongSwan configuration were correctly deployed.

Check certificates
On the Linux device, verify that the VPN certificate and keys are present under the standard strongSwan directories, for example:
ls /etc/swanctl/x509/ ls /etc/swanctl/x509ca/ ls /etc/swanctl/private/
You should see files like:
- /etc/swanctl/x509/swifteam-xxxx.pem
- /etc/swanctl/x509ca/swifteam-xxxx.pem
- /etc/swanctl/private/swifteam-xxxx.pem
Check strongSwan service status
Confirm that strongSwan is enabled and running:
sudo systemctl status strongswan.service
The service should be active (running). If it is not, review logs and ensure the policy was successfully applied.

Step 5: Validate the VPN Connection (RADIUS)

Once the configuration and certificates are in place:

Trigger or wait for the VPN connection according to your strongSwan configuration / policy behavior.
On the VPN gateway / RADIUS server, confirm:
- The Linux device is authenticating using the SCEPman-issued certificate.
- Authentication and authorization proceed as expected (EAP-TLS or certificate-based).
On the Linux device, you can also check:
sudo swanctl --list-sas
to see if an IKE/Child SA is established, and use your normal tools (e.g., ip a, ip r) to confirm the VPN interface and routes are active.

Field Reference (RADIUS-Specific)

Below is a concise reference for the RADIUS-related fields in LINUX_VPN_POLICY:

Top-level

openVpnConfigurationList (optional)
Array of OpenVPN profiles. Each entry has:
- name – Profile name
- ovpnProfile – OpenVPN configuration content
ipsecConfigurationList (array)
Each entry:
- name (required) – IPsec VPN configuration name
- configureType (required) – "manual" or "radius"
  - When "radius":
    RADIUS-related fields (radiusConfigurationList) are used
    Manual IPsec fields (ipsecConnectionList, certificateProviderList, ipsecCACertList) are hidden
  - When "manual":
    Manual IPsec fields are visible; radiusConfigurationList is hidden

RADIUS configuration

Under each ipsecConfigurationList[] where configureType: "radius":

radiusConfigurationList (array of RADIUS VPN definitions)
- name – Name for this RADIUS VPN config
- remoteId – Identity of VPN server (must match CN or SAN of server certificate; typically FQDN)
- remoteAddrs – Remote VPN gateway address(es), comma-separated
  (IP, DNS name, CIDR, or range depending on your setup)
- scepmanConfiguration (dictionary):
  - tenantID – SCEPman tenant ID
  - clientID – SCEPman client ID
  - clientSecret – SCEPman client secret
  - scepmanApiAppId – SCEPman API application ID
  - scepmanServiceDefaultDomain – SCEPman default service domain

Troubleshooting

If the device does not successfully establish the VPN:

Verify SCEPman configuration
Ensure all SCEPman fields (tenantID, clientID, clientSecret, scepmanApiAppId, scepmanServiceDefaultDomain) are correct and match your Azure / SCEPman setup.
Check certificate files
- Confirm certificates and keys exist in:
  - /etc/swanctl/x509/
  - /etc/swanctl/x509ca/
  - /etc/swanctl/private/
- Ensure the certificate CN/SANs align with what your VPN gateway and RADIUS expect.
Review strongSwan logs
Use journalctl to check strongSwan logs:
sudo journalctl -u strongswan.service -n 200 --no-pager
Look for errors related to:
- Certificate validation
- RADIUS/EAP handshake
- IKE proposal mismatch
Confirm RADIUS and VPN server configuration
- Check that the VPN gateway is configured to use RADIUS and trusts the SCEPman CA.
- Ensure the RADIUS server recognizes and authorizes certificates issued by SCEPman.
Verify Swif agent status
Ensure the Swif agent is running and has the required permissions to:
- Request certificates from SCEPman
- Write to /etc/swanctl/*
- Manage the strongSwan service