How to - Authenticate OneConnect users with IdAuth on Windows Server and Let's Encrypt

Users open Clavister OneConnect, sign in with their normal AD account in a browser, and the VPN comes up. The firewall keeps no VPN users and no VPN passwords. Membership of one AD group decides who may connect.

This guide lets the firewall get its certificate from Let’s Encrypt by itself (ACME). Users see a public certificate everywhere, so client PCs need nothing but OneConnect: no CA to install. The certificate is set to renew by itself.

Which setup? Use this one unless you must use your own CA; for that, use How to - Authenticate OneConnect users with IdAuth on Windows Server and your own CA. This setup needs TCP port 80 free on the firewall’s outside address: Let’s Encrypt checks there that you control the name (the HTTP-01 check, which Let’s Encrypt allows only on port 80). This is one of four guides. The overview, How to - Authenticate OneConnect users with Clavister IdAuth on-premises, compares all four setups.

IdAuth is Clavister’s name for PhenixID Authentication Services; the product screens say PhenixID. The Windows service is called phenixid. In this guide, “the firewall” is your Clavister NetWall. “Reference setup” at the end lists the versions this was tested with.

The firewall and the IdAuth server do all the work. The firewall’s own reverse proxy ends the users’ TLS session with the Let’s Encrypt certificate and passes the sign-in on to IdAuth. PowerShell scripts do the expert parts on the IdAuth server. No other server is needed.

Read this first

Three things must be right in this setup. The scripts and the checks handle them. You only need to know they exist, so that you do not undo them.

1. The firewall and IdAuth use TLS 1.2 between them. Step 4 sets IdAuth's listeners to TLS 1.2.
2. The firewall matches plain group names. AD gives DNs, so IdAuth sends plain names. Step 4 sets that.
3. The firewall must find the IdAuth name on the inside, and only there. OneConnect and the firewall use the same address for IdAuth, IDAUTH_URL. From the internet it leads to the firewall's reverse proxy; from the firewall it must lead to IdAuth itself. If the firewall asks a public DNS server, it gets its own outside address, not IdAuth's. Step 6, check 4.

Two more points: Windows Defender Firewall (Defender in this guide) blocks IdAuth’s ports, and every check on the server itself still passes. Steps 2 and 4 open them, and step 5 narrows the first rule. The firewall checks the name in IdAuth’s certificate, so IdAuth needs a certificate for IDAUTH_NAME. Step 1 makes one.

How the pieces fit:

The same name leads to the firewall from the internet, and to IdAuth from inside. “DNS, two views” in “Before you start” sets that up. PROXY_PORT is 8443: IdAuth’s own HTTPS port, and the same port on the firewall’s outside address.

This guide does not cover these cases. Stop here and get help from your Clavister partner:

• port 80, 443 or PROXY_PORT on the firewall's outside address is already in use (for example by a web server), or old-style IP Rules or rule folders use those ports;
• the firewall already runs a OneConnect server;
• the firewall is an HA pair;
• the domain controller has no LDAPS.

Words you will meet:

Fill in the sheet

The scripts. Download idauth-oidc-scripts-windows.zip to the IdAuth server. It holds the scripts folder that this guide uses. The numbers in the script names are not the step numbers.

Most values below are used in more than one place. Fill in everything now except WAN_IF and LAN_IF: “Before you start” has you run the show commands of step 6, and check 2 shows them. Write them into sheet.txt then.

On the IdAuth server (the Windows Server that will run IdAuth), in PowerShell as administrator, unpack the scripts to C:\Install\scripts and make your own copy of the sheet. If the zip is not in Downloads, change the first line to the folder it is in. Unblock-File is needed because Windows refuses to run scripts that came from the internet:

Expand-Archive $env:USERPROFILE\Downloads\idauth-oidc-scripts-windows.zip C:\Install
Unblock-File C:\Install\scripts\*
cd C:\Install\scripts
copy sheet-example-letsencrypt.txt sheet.txt
notepad sheet.txt

Write your values from the table below into sheet.txt, and save it. Step 6 reads the sheet with fill-sheet.ps1. It refuses a value the firewall script needs that is missing, has a space, or is still an example (the public example addresses or example.com). It cannot check that a value such as 10.0.0.30 or If1 is right for your network: check those yourself.

In the rest of this guide, a name in capitals means “your value from the sheet”. Replace it before you press Enter. Parameter names stay as they are: -Name or -IdauthUrl in PowerShell, DNSServer1= on the firewall. Replace only the value.

Before you start

You need every item below. If one is missing, a later step fails.

Five machines. The firewall, the DC, the IdAuth server, an admin PC on the inside, and a test PC on the internet that does not use your inside DNS (a laptop on a phone hotspot is enough). Step 7 needs the admin PC and the test PC at the same time.

The firewall CLI. Many commands in this guide run on the firewall’s command line. Open it in PowerShell: ssh FW_ADMIN@FW_MGMT_IP, or the address you manage the firewall on. The first time, type yes to the question about the key. The prompt ends in :/>. This guide writes Device:/>; your firewall shows its own name there. If SSH is refused, SSH management is not on for your admin PC: ask whoever set up the firewall.

A router in front of the firewall. If another router or a cloud security group sits in front of it, that device must pass TCP 80 (the Let’s Encrypt check), TCP and UDP 443 (OneConnect) and TCP PROXY_PORT (the sign-in page) to the firewall.

Look at step 6 now. Checks 2 to 5 of step 6 start with show commands, which change nothing. Run only these show commands now, and write down what checks 3 and 4 show; do not type the set lines yet. If check 5 finds port 80, 443 or PROXY_PORT taken, stop: this guide does not cover it.

Firmware. On the firewall CLI, about must show cOS Core 15.00.06 or later. This guide was tested on 15.00.06.10. The per-interface OneConnect certificate came in 15.00.02, and Chain certificates in 15.00.03. Upgrade first.

Licences. IdAuth needs its licence file (license.p12) to open its ports. NetWall needs SSL VPN and the reverse proxy in its licence. On the firewall CLI, license must show a Max SSLVPN Tunnels line above 0, and Reverse Proxy: YES.

IdAuth media from Clavister. phxid_server_windows_x64_<version>.exe and license.p12. Put both in C:\Install on the IdAuth server.

The IdAuth server (IDAUTH_IP). Windows Server 2025 with 4 vCPU, 6 GB RAM and 60 GB disk is enough. Other Windows Server versions were not tested. It can stay in a workgroup; it does not need to join the domain. Give it a fixed address. Its answers to the users must go back through this firewall, because the firewall’s reverse proxy keeps each user’s own address: make the firewall its default gateway, or a router whose default route is this firewall. The scripts are in C:\Install\scripts (see “Fill in the sheet”). Every command on the IdAuth server in this guide runs in PowerShell as administrator, in C:\Install\scripts. Check that the server has scp and ssh:

Get-Command scp, ssh

It must list scp.exe and ssh.exe. Windows Server 2025 has them. If one is missing: Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0.

In AD:

• a service account svc-idauth with a password that never expires;
• the group VPN_GROUP, with TEST_USER in it as a direct member. Groups inside the group do not count;
• OTHER_USER, not in the group.

On a DC, or a PC with the AD tools, as a domain admin:

$pw = Read-Host -AsSecureString "Password for svc-idauth"
New-ADUser -Name svc-idauth -SamAccountName svc-idauth -Enabled $true `
  -PasswordNeverExpires $true -AccountPassword $pw -Path "CN=Users,DOMAIN_DN"
New-ADGroup -Name VPN_GROUP -GroupScope Global -Path "CN=Users,DOMAIN_DN"
Add-ADGroupMember -Identity VPN_GROUP -Members TEST_USER

Then check them (if they exist already, only check them):

Get-ADUser svc-idauth -Properties PasswordNeverExpires | Select-Object Name, PasswordNeverExpires
Get-ADGroupMember VPN_GROUP | Select-Object -ExpandProperty SamAccountName
(Get-ADUser OTHER_USER -Properties MemberOf).MemberOf
(Get-ADUser svc-idauth).DistinguishedName

PasswordNeverExpires must be True. The group must list TEST_USER (this lists direct members only). The third command must not show VPN_GROUP. The last command prints your SVC_DN: write it into sheet.txt exactly.

LDAPS on the DC. IdAuth reads AD over LDAPS, port 636. Check it now, on the IdAuth server:

$t = New-Object Net.Sockets.TcpClient("DC_IP", 636)
$s = New-Object Net.Security.SslStream($t.GetStream(), $false, { $true })
$s.AuthenticateAsClient("DC_IP"); $s.RemoteCertificate.Subject; $s.RemoteCertificate.Issuer; $t.Close()

It prints the DC’s certificate name, such as CN=dc1.example.com (this line can be empty), and then the CA that issued it. Write the CA down: “Turn off Trust all” needs it. If it prints an error, stop here: the DC needs a certificate for LDAPS, which is a job for your AD team.

DNS, two views. At your public DNS provider, VPN_NAME points to FW_OUTSIDE_IP. Let’s Encrypt checks exactly this. Inside, IDAUTH_NAME points to IDAUTH_IP. Add the inside record as its own zone, so that it does not touch the rest of your domain. On the DC at DC_IP, the DNS server that the firewall and VPN users ask:

Add-DnsServerPrimaryZone -Name IDAUTH_NAME -ReplicationScope Domain
Add-DnsServerResourceRecordA -ZoneName IDAUTH_NAME -Name "@" -IPv4Address IDAUTH_IP

Both lines print nothing. Check on the IdAuth server: Resolve-DnsName IDAUTH_NAME -Server DC_IP must answer with IDAUTH_IP (an extra SOA row is normal).

From now on every PC that uses this DNS gets the inside address for VPN_NAME. So use OneConnect from outside the office, and run the public check (6c) and step 7 on a PC that does not use your DNS. A phone hotspot is enough. The same holds for a PC while it is connected to the VPN: the VPN gives it the DC as DNS server, so it gets IDAUTH_IP for VPN_NAME. That is expected; OneConnect already knows the firewall’s address.

For Let’s Encrypt, the public name must have no AAAA (IPv6) record, unless that points to this firewall too: Let’s Encrypt tries IPv6 first. If your domain has a CAA record, it must allow letsencrypt.org. Check both on the IdAuth server, against a public DNS server:

Resolve-DnsName VPN_NAME -Type AAAA -Server 1.1.1.1
(Invoke-RestMethod "https://dns.google/resolve?name=<name>&type=CAA").Answer

The first command must show no AAAA row; a lone SOA row means there is none. Windows has no CAA lookup of its own, so the second command asks Google’s public DNS. Run it once for each name from VPN_NAME up to your domain, with that name in place of <name>: for example vpn.example.com, then example.com. The first name that has a CAA record decides, and that record must name letsencrypt.org. No output means no CAA record, which is fine.

The DC must also answer internet names (a Windows DC with forwarders does). The firewall will use it for everything, Let’s Encrypt included. Check on the IdAuth server: Resolve-DnsName www.clavister.com -Server DC_IP must print an address.

Time. The firewall, the IdAuth server and the DC must agree on the time within a minute. The token lives 2 minutes, so a clock that is a few minutes off fails every sign-in. On the IdAuth server and on the DC, w32tm /query /status must show a time server as Source. Local CMOS Clock means no time source. That is the default on the first DC of a new forest (the PDC emulator); other DCs and domain members follow it. Give that DC a source, with your own NTP server in place of time.windows.com if you have one:

w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resync

Then compare the clocks: Get-Date on the Windows servers, time on the firewall CLI (it also shows its time zone). In the same time zone, they must be within a minute of each other.

A backup of the firewall, first. Before you change anything on the firewall, check on the firewall CLI that nothing is pending: show -changes must say There are no changes. (more in step 6, check 1). Then, from your admin PC, in PowerShell:

scp -O FW_ADMIN@FW_MGMT_IP:config.bak fw-before-oidc.bak

Use the address you manage the firewall on, if it is not FW_MGMT_IP. Keep the file in a safe folder: it holds the firewall’s secrets. It is your way back; see “Remove it again” at the end of this guide.

SSH from the IdAuth server to the firewall. Step 6 runs from the IdAuth server. On it:

ssh FW_ADMIN@FW_MGMT_IP

It must show the firewall’s prompt, which ends in :/>. Type exit to leave. If it says Connection timed out, the firewall’s SSH management does not allow this server. Add that from your admin PC, in its SSH session to the firewall:

Device:/> add RemoteManagement RemoteMgmtSSH ssh_idauth Interface=LAN_IF Network=IDAUTH_IP LocalUserDatabase=AdminUsers
Device:/> activate
Device:/> commit

AdminUsers is the firewall’s own admin database. If your admins log in through RADIUS, use the database of your existing SSH line instead (show RemoteManagement RemoteMgmtSSH <name> shows it under AuthSource and LocalUserDatabase). Step 7 removes this line again at the end.

activate starts the new configuration. Then commit must follow within 30 seconds, or the firewall goes back to the old one by itself. This protects you from a change that cuts off your own access. commit answers Committed changes. This pair is used every time in step 6.

A syslog receiver at SYSLOG_IP. It is where you read the firewall’s errors. For the setup and the tests this is enough. Run it on the IdAuth server, in a second PowerShell window as administrator. Keep that window open until the end of step 7; it stops when you close it. The firewall sends nothing to it before step 6b.

New-NetFirewallRule -DisplayName "Syslog from NetWall" -Direction Inbound -Protocol UDP `
  -LocalPort 514 -RemoteAddress FW_MGMT_IP -Action Allow -Profile Any
$u = New-Object Net.Sockets.UdpClient 514
$ep = New-Object Net.IPEndPoint ([Net.IPAddress]::Any, 0)
while ($true) {
  $m = [Text.Encoding]::UTF8.GetString($u.Receive([ref]$ep)); $m; Add-Content C:\Install\fw.log $m
}

The test PC needs OneConnect from the Microsoft Store. See Configure Clavister OneConnect for Windows towards Clavister NetWall, or Install OneConnect without Microsoft store for a PC without the Store.

Step 1 - IdAuth’s certificate

The users never see this certificate; they see the firewall’s Let’s Encrypt certificate. Only the firewall checks this one, when it reads IdAuth’s discovery document on the inside, and it checks that the name in it is IDAUTH_NAME. On the IdAuth server:

.\02-idauth-certs.ps1 -Name IDAUTH_NAME

It makes a certificate for IDAUTH_NAME in the server’s certificate store (friendly name idauth-listener-IDAUTH_NAME), valid for 5 years, and writes its public part to C:\Install\certs\idauth-listener.crt. Step 4 gives it to IdAuth, and step 6 gives the .crt file to the firewall.

Check: the last lines list idauth-listener.crt. Running the script again keeps the same certificate.

Step 2 - Install IdAuth

IdAuth already installed and in use? Skip step 2 and go to step 3.

On the IdAuth server:

.\01-idauth-install.ps1 `
  -Installer C:\Install\phxid_server_windows_x64_7_0_2_10339.exe `
  -LicenseFile C:\Install\license.p12 -AdminUser PORTAL_USER -StartService

Use the real file names. PowerShell first asks AdminPassword: and EncryptionKey:. Then the script asks Type the portal admin password again and Type the encryption key again. A to Z and digits only (no å, ä, ö). Write the key down; a second IdAuth node needs the same one.

The script installs IdAuth, checks the licence, starts the service, and opens TCP 8443 in Defender for every network profile (the rule IdAuth portal 8443). It waits up to two minutes for IdAuth to start. A good run prints listening on 8443 - good, then the portal address. The server.log lines just above it may show a Java stack trace from the first start; if the run prints listening on 8443 - good, that is fine. Step 5 narrows the rule.

If the script stops with an error, use the product’s own installer instead: run the .exe, give it the licence file and the admin account, keep its port at 8443, then run these four lines as administrator:

Set-Service phenixid -StartupType Automatic
New-NetFirewallRule -DisplayName "IdAuth portal 8443" -Direction Inbound -Protocol TCP `
  -LocalPort 8443 -Action Allow -Profile Any
icacls "C:\Program Files\PhenixID\Server\.install4j\response.varfile" /inheritance:r `
  /grant:r "*S-1-5-32-544:F" "*S-1-5-18:F"
Start-Service phenixid

The installer writes the admin password and the encryption key to response.varfile. The icacls line limits that file to Administrators and SYSTEM; 01-idauth-install.ps1 does this for you.

Check: open https://IDAUTH_IP:8443/config/ in a browser on your admin PC. Accept the certificate warning; users never see this page. The login page may be in Swedish. To change it, press the three dots at the top right, and in the panel Inställningar set Språk to English. Then sign in as PORTAL_USER.

IdAuth’s logs are in C:\Program Files\PhenixID\Server\logs\: server.log for start-up, event.log for sign-ins.

Step 3 - Four wizards in IdAuth

All four are under Scenarios: a tab bar at the top and a list of rows on the left, each with a +. Fill in only what is listed. Leave everything else as the wizard has it. Each wizard ends with a summary: press Create there.

If this IdAuth already serves other applications, still create everything new, as below. Do not reuse an existing OpenID Provider.

3a. LDAP connection

Scenarios > Connections > LDAP > +

After the SSL screen, the wizard shows Connection status: Not tested and a blue Test connection link under it. Press it: it must say Connection status: Success (OK when you test the saved connection later). To test again later: Scenarios > Connections > LDAP > AD-LDAPS > Test connection. The wizard also says the account needs read and write access. Read access is enough here (a normal domain user); do not give it more.

Check SSL on the saved connection, not the wizard’s summary: USE SSL/TLS and TRUST ALL ticked.

3b. Authenticator

Scenarios > Authenticators > Dynamic Authenticator > +

Use the Authenticators tab. Do not use Legacy guides: it sets up a client secret, and OneConnect signs in without one.

3c. Relying party

Scenarios > OIDC > Relying party > +

http://127.0.0.1/oneconnect/oauth/
http://[::1]/oneconnect/oauth/
com.clavister.oneconnect://oauth/

These three come from Clavister. Use exactly these.

3d. OpenID Provider

Scenarios > OIDC > OpenID Provider > +

If you typed another address as Base URL, step 4 repairs it.

The three claims. For each claim: tick Show additional configuration parameters (it clears after every Add claim), type the claim name and its Item property name, pick openid under Scopes (nothing is picked at first), leave Include in id_token on, then press Add claim.

Check, on the IdAuth server:

(curl.exe -sk https://127.0.0.1:8443/TENANT/.well-known/openid-configuration | ConvertFrom-Json).issuer

Type curl.exe, not curl: in Windows PowerShell, curl is another command. -k accepts IdAuth’s own certificate for this check; step 4 gives IdAuth the right one. It prints the issuer. IDAUTH_URL/TENANT is right, and another address is fine too: step 4 fixes it. An error means a wizard is not finished.

Step 4 - The settings outside the wizards

Up to thirteen more settings are needed. One script sets all of them. In IdAuth’s configuration it changes only the oneconnect relying party, the OpenID Provider that allows it, that provider’s authenticator (it adds one processing step), a second listener on PLAIN_PORT, and the certificate on port 8443, with a keystore for it. It also sets IdAuth’s listeners to TLS 1.2, opens PLAIN_PORT in Defender for public addresses only, and makes IdAuth’s config folder readable by administrators only: it holds the key of IdAuth’s certificate.

If IdAuth’s own files need a change, the script stops IdAuth, makes the changes and starts IdAuth again, so sign-ins stop for about a minute. If other applications use this IdAuth, do it in a maintenance window, and read the next paragraph first.

Shared IdAuth only. If other applications use this IdAuth, first run the line below with -DryRun added, and read every CHANGE line. Four things also reach them: TLS 1.2 and the new certificate on port 8443; step 5, which limits port 8443 to the firewall and your admin PC (add the networks their users come from); and the firewall’s reverse proxy, which publishes every sign-in page and OIDC endpoint of this IdAuth to USERS_SRC, not only TENANT.

Close every IdAuth portal tab first. An old tab can later save the old settings back. Then, on the IdAuth server:

.\07-idauth-fixup.ps1 -IdauthUrl IDAUTH_URL -PlainPort PLAIN_PORT

The script prints one line per setting. ok means it was already right. CHANGE means it set it. It backs up every file first (*.bak-<time>), and a second run says Nothing to change.

Check. The script checks its own work at the end and must print All checks passed. after these lines:

• issuer: IDAUTH_URL/TENANT;
• PKCE methods: S256;
• admin portal on PLAIN_PORT: 404: the admin portal is not on the plain port;
• certificate on 8443: CN=IDAUTH_NAME ... (Tls12).

If IdAuth does not come up, the script says so after about two and a half minutes (ERROR IdAuth does not listen on both ...), or stops with a red error from Start-Service. Read server.log, then put the files back. <time> is the time from the script’s line Backups: *.bak-<time>:

$t = "<time>"
cd "C:\Program Files\PhenixID\Server\config"
Stop-Service phenixid
Get-ChildItem "*.bak-$t" | ForEach-Object { Copy-Item $_.FullName $_.FullName.Replace(".bak-$t", "") -Force }
Start-Service phenixid
cd C:\Install\scripts

Step 5 - The Defender rule and the inside name

Port 8443 on the IdAuth server also serves the admin portal. Only your admin PC and the firewall need it: the firewall reads IdAuth’s discovery document there. Narrow the rule from step 2 to those two. On the IdAuth server:

$r = "IdAuth portal 8443"
if (Get-NetFirewallRule -DisplayName $r -ErrorAction SilentlyContinue) {
  Set-NetFirewallRule -DisplayName $r -RemoteAddress FW_MGMT_IP,ADMIN_PC_IP
} else {
  New-NetFirewallRule -DisplayName $r -Direction Inbound -Protocol TCP -LocalPort 8443 `
    -Action Allow -Profile Any -RemoteAddress FW_MGMT_IP,ADMIN_PC_IP
}
Get-NetFirewallPortFilter | Where-Object LocalPort -eq 8443 | Get-NetFirewallRule |
  Where-Object { $_.Enabled -eq 'True' -and $_.Direction -eq 'Inbound' } | Select-Object DisplayName

Put your admin PC’s address in place of ADMIN_PC_IP. A subnet such as 10.0.0.0/24 is fine if your admin PCs get their address by DHCP. The last command must list only IdAuth portal 8443. If other applications use this IdAuth on 8443, do not cut them off: add the networks their users come from, and check that the rule lets in FW_MGMT_IP.

PLAIN_PORT was opened by step 4 for public addresses only (the rule IdAuth sign-in PLAIN_PORT (NetWall reverse proxy)). The firewall’s reverse proxy keeps each user’s own address, so the rule cannot name the firewall. Instead, it refuses private addresses. No inside machine with a private address can use the plain port directly.

Check the inside name, on the IdAuth server:

Resolve-DnsName IDAUTH_NAME -Server DC_IP

It must answer with IDAUTH_IP (an extra SOA row is normal). That is what the firewall will get in step 6.

Step 6 - The firewall

Step 6 runs on the IdAuth server. You now use three PowerShell windows there: the syslog receiver, SSH to the firewall, and one for the server’s own commands, in C:\Install\scripts.

Before you run anything: five checks

The backup. You took it in “Before you start”. If anyone has changed the firewall since then, take a new one the same way. A new backup also holds the SSH line from “Before you start”; after a restore from it, delete that line again (end of step 7).

The firewall script only adds objects, and every object it adds starts with oc. It does not change interfaces, routes, existing rules or the management certificate. Checks 3 and 4 below may change two global settings; write the old values down. The script cannot know these five things. Check them in an SSH session to FW_MGMT_IP.

1. Nothing is pending.

Device:/> show -changes

It must say There are no changes. The single line One or more indexed objects have been moved. is also fine. If objects are listed, someone has unsaved work: ask them first. Then activate and commit, or throw it away with reject -all. Tell the other admins not to change anything until step 6 is done.

2. Interface names. show Interface Ethernet lists them (show Interface lists every kind of interface, most of them empty). The outside one is the one your internet line is on. Put the outside one in WAN_IF and the inside one in LAN_IF in sheet.txt. Then check the outside address object:

Device:/> show Address IP4Address InterfaceAddresses/If1_ip

Use your WAN_IF in place of If1. It must print an object. If it prints none, your outside interface is not a plain Ethernet interface with its own address object. The guide was not tested that way; get help. With DHCP on the outside interface (usual in a cloud), Address is 0.0.0.0 and ActiveAddress shows the real address. That is fine.

3. The WebUI ports. show Settings RemoteMgmtSettings. OneConnect needs 443, Let’s Encrypt needs 80 (it checks there that you control the name), and the sign-in page needs PROXY_PORT, even if no rule lets anyone reach the WebUI there. Move each port that is in the way, and write down the old values:

Device:/> set Settings RemoteMgmtSettings WWWSrv_HTTPSPort=4443
Device:/> set Settings RemoteMgmtSettings WWWSrv_HTTPPort=8080
Device:/> activate
Device:/> commit

Run the first line if WWWSrv_HTTPSPort is 443 or PROXY_PORT, and the second if WWWSrv_HTTPPort is 80 or PROXY_PORT. Pick free ports, and not PROXY_PORT. Tell the other admins the new ports. If you reach the WebUI through a router or a cloud security group, open the new port there too. Do that before you type activate: commit must follow within 30 seconds.

4. The firewall’s own DNS. The firewall must resolve IDAUTH_NAME to IDAUTH_IP, and it must never ask a public DNS server instead. show DNS lists its servers. Write them down. Then use the DC only:

Device:/> set DNS DNSServer1=DC_IP DNSServer2="" DNSServer3=""
Device:/> activate
Device:/> commit

A second DC is fine as DNSServer2; a public server is not. With a public server in the list, the firewall can get its own outside address for IDAUTH_NAME. It then reaches its own reverse proxy instead of IdAuth, and discovery fails.

This changes name lookups for the whole firewall: rules with names, IPsec peers, NTP and log servers given by name, updates, the licence and Let’s Encrypt. If your configuration uses names, check that the DC answers them the same way as your old servers.

Then check:

Device:/> ping IDAUTH_NAME
Sending 1 4-byte ICMP ping to 10.0.0.30 from 10.0.0.1
Device:/> ping www.clavister.com

The first line of the first ping must show IDAUTH_IP. The second ping must show an address: the firewall still finds internet names, which Let’s Encrypt needs. The ping answers themselves do not matter. If the first ping shows another address, the firewall still has an old answer: dns -flush, then ping again. The real proof is oidc in 6c.

5. The outside address is free. OneConnect needs TCP and UDP 443 on FW_OUTSIDE_IP, Let’s Encrypt needs TCP 80 (it checks there that you control the name), and the sign-in page needs PROXY_PORT.

Device:/> show IPRule
Device:/> show IPPolicy
Device:/> show Interface OneConnectInterface

What to look for:

• show IPRule: on an older configuration it lists the old-style IP rules too. On a configuration made on 15.x it answers Invalid object type, which is fine.
• show IPPolicy: it lists IP policies and reverse proxy policies. On an empty rule set it prints a list of types, then There is no object of the type IPPolicy., which is fine.
• In both lists, look for entries with source interface WAN_IF or any that allow, forward (SAT) or reverse-proxy traffic to the outside address on port 80, 443 or PROXY_PORT. Services such as http, https, http-all or all_services cover those ports; for a service with another name, show Service ServiceTCPUDP <name> shows its ports. Such an entry means the port is taken, and this guide does not cover that.
• A Deny entry, such as a closing deny-all, is fine: 6c puts the new entries above it. A Deny for port 80 does not stop Let's Encrypt either.
• show Interface OneConnectInterface must say There is no object of the type OneConnectInterface.

6a. The certificates

Let’s Encrypt. On the firewall:

Device:/> add ACMEAccount oc_acme Email=ACME_EMAIL AcceptTerms=Yes
Device:/> cc ACMEAccount oc_acme
Device:/oc_acme> add ACMECertMgmt oc_cert Domains=VPN_NAME
Device:/oc_acme> cc
Device:/> activate
Device:/> commit

AcceptTerms=Yes accepts the Let’s Encrypt subscriber agreement. Read it first; it is on letsencrypt.org. The firewall then asks Let’s Encrypt for a certificate. Let’s Encrypt checks that you control VPN_NAME by fetching a file from the firewall on port 80 (the HTTP-01 check; Let’s Encrypt allows no other port for it). The firewall answers that by itself; no rule is needed. Wait a minute, then:

Device:/> acme -num=5
Device:/> show Certificate

• acme -num=5 must show oc_cert with a date under Validity and the status Downloaded or Issued. It usually takes less than a minute.
• show Certificate must list oc_cert with type Chain. A + in front of it means it is not saved yet; the activate and commit below save it.
• It is set to renew by itself 30 days before it expires; acme -show oc_acme/oc_cert shows the date.
• If acme fails, fix the cause before you try again, and ask your Clavister partner how to start a new try. Let's Encrypt limits failed tries and repeat certificates (letsencrypt.org/docs/rate-limits): at most 5 certificates for the same name in 7 days. Every new setup orders one, and so does every restore of a saved configuration that holds oc_cert.

IdAuth’s certificate, for the firewall only. On the IdAuth server:

scp -O C:\Install\certs\idauth-listener.crt "FW_ADMIN@FW_MGMT_IP:certificate/oc_idauth_cert"

It asks for the firewall password and prints nothing when it works. Ignore the exit code of scp; show Certificate is the proof. -O selects the SCP protocol that the firewall uses.

On the firewall:

Device:/> show Certificate
Device:/> activate
Device:/> commit

show Certificate must list oc_cert with type Chain and oc_idauth_cert with type Remote. The activate and commit save them, so that a reject -all in 6b cannot remove them.

6b. The objects

If you already send the firewall log to a syslog server, you may delete the oc_log line from 03-netwall-letsencrypt.sgs first. You then find the firewall’s messages in your own log server, not in C:\Install\fw.log, and you leave out delete LogReceiverSyslog oc_log in “Remove it again”.

On the IdAuth server:

.\fill-sheet.ps1 sheet.txt 03-netwall-letsencrypt.sgs oidc.sgs
scp -O oidc.sgs "FW_ADMIN@FW_MGMT_IP:script/oidc.sgs"

fill-sheet.ps1 prints the values that go into the firewall script (the firewall does not need the others). Read them once. scp prints nothing; ignore its exit code, as in 6a. On the firewall, script must list oidc.sgs. If scp says Permission denied, a script with that name is already on the firewall (or the password was wrong): run script -remove -name=oidc.sgs on the firewall and upload again.

On the firewall:

Device:/> script -execute -name=oidc.sgs
Device:/> activate
Device:/> commit

script -execute ends with There are no errors. when every line worked. You type activate yourself, after the script. When commit has answered, delete the file from the firewall:

Device:/> script -remove -name=oidc.sgs

It is not needed any more. A file left there blocks the next upload, and running it by mistake runs old values.

If a line fails, the run stops at that line and does nothing after it. Do not run the file again: it would stop at line 1 with already exists. Instead:

Device:/> reject -all
Device:/> script -remove -name=oidc.sgs

Then fix the value in sheet.txt, fill, upload and run again.

What the script creates: the log receiver oc_log, address and service objects, the OIDC provider oc_idauth, the user group oc_vpn_group, the OneConnect server oc-vpn with the Let’s Encrypt certificate and split tunnel, the reverse proxy policy oc-publish-idauth, and three IP policies for VPN users.

The reverse proxy policy is the part that replaces a separate proxy server. It has two halves:

• the policy oc-publish-idauth catches HTTPS on PROXY_PORT of the outside address, from USERS_SRC;
• its map, for the name IDAUTH_NAME, ends the TLS session with oc_cert (Protocol=HTTPS_to_HTTP) and passes the request on in plain HTTP to IDAUTH_IP, port PLAIN_PORT.

The firewall itself does not use this policy. It reads IdAuth directly on the inside, over TLS, and checks IdAuth’s certificate against oc_idauth_cert: that is the OIDC provider oc_idauth, with VerifyProviderCertificate=Yes RootCertificates=oc_idauth_cert.

6c. Rule order, then the checks

The four new entries land at the end of the rule set, below any deny-all. Move them to the top. Run these lines in exactly this order, last rule first:

Device:/> set IPPolicy oc-vpn-deny Index=1
Device:/> set IPPolicy oc-vpn-to-lan Index=1
Device:/> set IPPolicy oc-vpn-dns Index=1
Device:/> set ReverseProxyPolicy oc-publish-idauth Index=1
Device:/> activate
Device:/> commit

Each move puts an entry at the top, so the one moved last ends up first. At the top they cannot be overridden by a broader rule of yours. They do not change your other traffic: three match only traffic from the VPN, and the reverse proxy matches only PROXY_PORT on the outside address, which check 5 found free.

If your rule set starts with drop rules for internet traffic (geo-blocking, block lists), keep oc-publish-idauth below them. Then do it in this order instead: show IPPolicy, note the index N of the first entry below your drop rules, run set ReverseProxyPolicy oc-publish-idauth Index=N, and then only the three set IPPolicy lines. The check below then shows the three VPN entries, your drop rules, then oc-publish-idauth.

Then check:

Device:/> show IPPolicy

The first four must be oc-publish-idauth (type RevProxy), oc-vpn-dns, oc-vpn-to-lan and oc-vpn-deny, in that order. The table cuts the names short (oc-pu..., oc-vp...), so read the other columns: first RevProxy, then Allow to oc_dc_dns, Allow to oc_lan_net (shown as oc_lan...), and Deny to all-nets.

Device:/> oidc -refresh
Device:/> oidc

Expect Status : Discovery completed and Loaded keys of 1 or more.

Device:/> userauth -privilege

Expect a line like "VPN_Employees" 13: your group name and its length.

The public check. On a PC on the internet that does not use your inside DNS (a phone hotspot is enough), open https://IDAUTH_NAME:PROXY_PORT/TENANT/.well-known/openid-configuration in a browser. It must open with no certificate warning and show a JSON page with an "issuer" line. The certificate is from Let’s Encrypt. The test PC’s public address must be inside USERS_SRC.

Step 7 - The client

Copy 04-windows-client.ps1 from C:\Install\scripts to C:\temp on the test PC (create the folder if it is not there), any way you like: it is not secret. There is no CA file to copy. On the PC, signed in as the user who will use OneConnect, open a normal PowerShell, not as administrator: OneConnect must start as that user, to take the profile link and show the right status. Then:

cd C:\temp
powershell -ExecutionPolicy Bypass -File .\04-windows-client.ps1 -VpnName "Company VPN" -Server VPN_NAME

-ExecutionPolicy Bypass is needed because a Windows PC does not run scripts by default. The script checks the sign-in page and must print Sign-in address https://VPN_NAME:8443/ answers, and this PC trusts its certificate. Then OneConnect opens with the profile filled in. Press Save. If no profile window opens, close OneConnect completely and run the script again.

In OneConnect, press the small arrow under the logo and pick Company VPN. Connect stays grey until a profile is picked. Then press Connect.

A browser opens on the IdAuth sign-in page. The page is in Swedish: Användarnamn is the user name, Lösenord the password, and LOGGA IN signs in. Sign in at once as TEST_USER: the user name only, as in jdoe, and the AD password. The browser then shows Authentication complete. Close it. OneConnect waits about two minutes for the sign-in (measured in the lab): if the browser shows 127.0.0.1 refused to connect after you signed in, that time had run out. Press Connect again and sign in at once.

OneConnect then shows Connected.

Check on the firewall:

Device:/> userauth -list

Expect TEST_USER, an address from VPN_POOL, interface oc-vpn, and VPN_GROUP under Privileges.

Check on the PC, in PowerShell:

Resolve-DnsName IDAUTH_NAME -Server DC_IP
Test-NetConnection DC_IP -Port 445

The first must answer with IDAUTH_IP (an extra SOA row is normal): DNS works through the VPN. The second must say TcpTestSucceeded : True if DC_IP is in LAN_NET and 445 is in VPN_PORTS. Only LAN_NET goes through the VPN; the PC’s internet traffic does not.

The refusal test. In OneConnect press Disconnect. Close every browser window, so the old sign-in is gone (if Edge offers Restore pages, do not restore them). Press Connect and sign in as OTHER_USER.

The browser still says Authentication complete: IdAuth accepted the password. Then OneConnect shows Connection failed and You are not authorized to log in. On the IdAuth server, Select-String user_group_disallow C:\Install\fw.log finds the firewall’s reason. That is the group rule working. If OTHER_USER gets in, check userauth -privilege again.

The firewall log also shows oc-vpn-deny drops of Windows broadcast and multicast from connected PCs (UDP 137 and 1900, IGMP), and TTLOnLowMulticast drops of mDNS and WS-Discovery. That is normal.

Remove the SSH line if you added one in “Before you start”. Do it from your admin PC, not from the IdAuth server, whose session this line allows:

Device:/> delete RemoteManagement RemoteMgmtSSH ssh_idauth
Device:/> activate
Device:/> commit

The setup is done.

Remove it again

There are two ways back. Use one of them, not both.

The backup. It puts back the whole configuration from when you took it, the WebUI ports and DNS servers included. It also undoes every change anyone made after the backup. Run this from your admin PC, in PowerShell, in the folder that holds fw-before-oidc.bak. Use the address you manage the firewall on, if it is not FW_MGMT_IP:

scp -O fw-before-oidc.bak FW_ADMIN@FW_MGMT_IP:

Ignore the exit code of scp. The firewall loads the file as pending changes: show -changes lists many objects. Then, on the firewall, activate and commit. After commit the WebUI is on its old ports again, so a browser on a moved port loses its session. If the backup is from after you added the SSH line, delete that line again, as at the end of step 7.

The delete list. It removes only what this guide added. From your admin PC, on the firewall, in this order (the things that use an object first):

Device:/> delete IPPolicy oc-vpn-deny
Device:/> delete IPPolicy oc-vpn-to-lan
Device:/> delete IPPolicy oc-vpn-dns
Device:/> cc ReverseProxyPolicy oc-publish-idauth
Device:/1(oc-publish-idauth)> delete ReverseProxyProfileMap 1
Device:/1(oc-publish-idauth)> cc
Device:/> delete ReverseProxyPolicy oc-publish-idauth
Device:/> delete Interface OneConnectInterface oc-vpn
Device:/> delete OIDCProvider oc_idauth
Device:/> delete UserGroup oc_vpn_group
Device:/> delete Service ServiceTCPUDP oc_svc_idauth
Device:/> delete Service ServiceTCPUDP oc_svc_allowed
Device:/> delete Address IP4Address oc_lan_net
Device:/> delete Address IP4Address oc_idauth_ip
Device:/> delete Address IP4Address oc_dc_dns
Device:/> delete Address IP4Address oc_pool
Device:/> delete Address IP4Address oc_inner
Device:/> delete Address IP4Address oc_users_src
Device:/> delete LogReceiverSyslog oc_log
Device:/> delete Certificate oc_idauth_cert
Device:/> cc ACMEAccount oc_acme
Device:/oc_acme> delete ACMECertMgmt oc_cert
Device:/oc_acme> cc
Device:/> delete ACMEAccount oc_acme
Device:/> delete Certificate oc_cert
Device:/> activate
Device:/> commit

If show RemoteManagement RemoteMgmtSSH still lists ssh_idauth, delete it as at the end of step 7. Then put back the WebUI ports and DNS servers you wrote down in checks 3 and 4. Leave out what you did not change, and write an empty old value as "":

Device:/> set Settings RemoteMgmtSettings WWWSrv_HTTPSPort=<old HTTPS port> WWWSrv_HTTPPort=<old HTTP port>
Device:/> set DNS DNSServer1=<old 1> DNSServer2=<old 2> DNSServer3=<old 3>
Device:/> activate
Device:/> commit
Device:/> show -changes

show -changes must say There are no changes. After this the WebUI is on its old ports again. If script (it lists the uploaded scripts) still shows oidc.sgs, also run script -remove -name=oidc.sgs.

After either way, on the IdAuth server, remove these two Defender rules:

Remove-NetFirewallRule -DisplayName "IdAuth sign-in PLAIN_PORT (NetWall reverse proxy)"
Remove-NetFirewallRule -DisplayName "Syslog from NetWall"

On each PC, delete the OneConnect profile: the list icon in OneConnect’s title bar, the pencil next to Company VPN, then Delete. On the IdAuth server, close the syslog receiver window (that stops it), then delete C:\Install\fw.log (the firewall log, with user names) and C:\Install\certs if you keep nothing of this setup.

These stay; remove them by hand if you want:

• the inside DNS zone. While it stays, PCs that use your DNS get IDAUTH_IP for VPN_NAME. Remove-DnsServerZone -Name IDAUTH_NAME -Force on the DNS server removes it;
• the AD objects, if this guide created them. Remove-ADUser svc-idauth and Remove-ADGroup VPN_GROUP remove them; both ask you to confirm;
• IdAuth with the settings of step 4. It still listens on PLAIN_PORT, but Defender now blocks it. To undo step 4 only, put back its *.bak-<time> files as described in step 4;
• IdAuth's own certificate idauth-listener-IDAUTH_NAME in the server's store;
• the Defender rule IdAuth portal 8443 of step 2, narrowed in step 5;
• after "Turn off Trust all", the DC's CA in IdAuth's trust store (alias dc-ldaps-ca).

Before you go live

• The sign-in page is a password prompt for your AD, on the internet. Anyone in USERS_SRC can try passwords there, and failed tries can lock accounts. If all users come from known networks, narrow USERS_SRC to them (set Address IP4Address oc_users_src Address=<range>, then activate and commit). Most users at home need 0.0.0.0/0; then your AD lockout policy and MFA in IdAuth (not tested here) are the protection.
• The hop from the firewall to PLAIN_PORT is plain HTTP, passwords and tokens included, on your inside network. The Defender rule lets in only public source addresses, so inside machines with private addresses cannot use the plain port directly. Users who reach the outside address from a private address, for example over a site-to-site VPN, are refused too. A DMZ interface for the IdAuth server would keep the hop off the user network; that was not tested.
• TLS 1.2 on IdAuth. Step 4 sets every IdAuth listener to TLS 1.2, the version the firewall and IdAuth use. Other applications on this IdAuth get TLS 1.2 too.
• Port 80 and the WebUI. Every renewal repeats the Let's Encrypt check on port 80. Keep the WebUI off 80 and do not publish anything else on 80 of the outside address.
• Every new VPN session needs IdAuth. Tunnels that are up should stay up; that was not tested. Plan a second IdAuth node, or a second way in.
• Removing a user from VPN_GROUP works at the next sign-in. It should not end a running tunnel (not tested). IdAuth also issues refresh tokens for 24 hours and remembers sign-ins (Allow SSO). If "disable the account and access is gone" must be true, shorten the refresh token lifetime and turn off Allow SSO, on the OpenID Provider edit page in IdAuth.
• What must keep running: the phenixid service on the IdAuth server, and the DC: IdAuth reads AD there, and the firewall and VPN users use it for DNS.
• Trust all (step 3a) must be off in production. With it on, IdAuth accepts any DC certificate, so a machine that pretends to be the DC gets the users' passwords. See "Turn off Trust all" below.
• The sign-in page opens in Swedish. Each user can switch it once: the settings button at the top right of the page (Inställningar), then Språk > English. The browser remembers it.
• The firewall log. oc_log sends the whole firewall log to SYSLOG_IP. Point it at your real log server, or delete LogReceiverSyslog oc_log. Then remove the Defender rule Syslog from NetWall on the IdAuth server.
• The firewall's DNS server is now the DC (check 4). It looks up every name there, IDAUTH_NAME included. Add a second DC as DNSServer2. The inside zone from "DNS, two views" is stored in AD, so every DC of the domain that runs DNS has it.
• Renewals. The Let's Encrypt certificate is set to renew by itself. The first renewal is after 60 days and was not tested for this guide. Renewals run only in the account's time window, 22:00 to 23:00 by default (CertRenewTimeStart, CertRenewTimeStop). acme -show oc_acme/oc_cert gives the earliest renewal time; the renewal runs in the first window after it. Check acme -num=5 the morning after. If show -changes then lists oc_cert, activate and commit; do not reject -all it. Restoring a saved configuration makes the firewall order a new Let's Encrypt certificate at once.
• IdAuth's certificate lasts 5 years. In its last 30 days, run step 1 again exactly as before, without -Force. It then makes a new certificate and prints what to do next: step 4, then upload idauth-listener.crt to oc_idauth_cert as in 6a, activate and commit. From step 4 until the upload is committed, oidc shows Discovery retry and nobody can start a VPN session: do it in a quiet hour. The SSH line from "Before you start" is gone by then: add it again for the upload and delete it after. The script counts a certificate with 30 days or less left as ending; run earlier, it changes nothing. Put the date in a calendar.
• After any later change in the IdAuth portal, and after every IdAuth upgrade, run step 4 again and read its checks. It restarts IdAuth only if IdAuth's own files need a change.
• The IdAuth server holds keys. phenix-store.json in C:\Program Files\PhenixID\Server\config holds the key of IdAuth's certificate, which the firewall trusts, and step 4 leaves *.bak-<time> copies of it there. Step 4 makes that folder readable by administrators only. Use this server for IdAuth only, give no one else administrator rights on it, and delete old backups you no longer need.
• Rolling out to many PCs. Nothing needs to go to the PCs but OneConnect and the profile. The profile is set up in the user's own, normal (not administrator) session, with a click on Save, not as SYSTEM. Do not e-mail profile links: a link that sets up a VPN looks like phishing. Edge offers to save the AD password on the sign-in page; turn that off by policy (PasswordManagerEnabled) if you do not want AD passwords in browsers. Rollout was not tested.

Turn off Trust all. IdAuth checks the DC against the Java trust store it ships with, not against Windows. Give it the certificate of the CA that issued the DC’s LDAPS certificate. The LDAPS check in “Before you start” printed that CA. With a one-level AD CS it is the AD CS root CA, and any domain-joined PC has it. If your AD CS has an issuing CA below the root, export that one: it is in Cert:\LocalMachine\CA instead of Cert:\LocalMachine\Root. Use a part of the name that matches only one CA. A domain-joined PC lists the CA twice (it comes from two stores), so the line takes the first. Run it on the DC or a domain-joined PC, not on a workgroup IdAuth server. It writes dc-ca.cer in the current folder.

Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*<the DC's CA name>*" |
  Select-Object -First 1 | Export-Certificate -FilePath .\dc-ca.cer

Copy dc-ca.cer to C:\Install on the IdAuth server. There, in PowerShell as administrator:

& "C:\Program Files\PhenixID\Server\jre\bin\keytool.exe" -importcert -cacerts -storepass changeit `
  -noprompt -file C:\Install\dc-ca.cer -alias dc-ldaps-ca
Restart-Service phenixid

It must say Certificate was added to keystore. changeit is the standard password of that trust store. The portal answers again about a minute after the restart. Then in the IdAuth portal: Scenarios > Connections > LDAP > AD-LDAPS, untick Trust all, press Save, then Test connection: it must say Connection status: OK. Close the portal tab, run step 4 again, and connect once more as in step 7. An IdAuth upgrade may bring a new trust store: test the connection after every upgrade, and if it says Failure, run the two lines above again. If the first test says Failure, tick Trust all again and press Save, so that users can sign in. Most likely dc-ca.cer is not the CA that the LDAPS check printed.

Keep IdAuth and the DC on a server network, not on the network of users’ PCs. With Trust all off, IdAuth accepts a DC certificate that a CA in its trust store signed: the DC’s CA, or one of the public CAs that Java trusts. Host can stay DC_IP.

If it does not work

Find the first row that matches what you see. Do what it says. Then go back to the check you were on. The syslog from “Before you start” is the fastest way to see the reason. OneConnect’s own log is on the PC: run the Get-ChildItem ... line that 04-windows-client.ps1 prints at the end, as the user who runs OneConnect. It shows the newest matches with their time; ignore those from before your last try.

The scripts

All in scripts. Each one explains itself at the top. The numbers in the names are not the step numbers, and there is no 05 or 06 in this setup.

03-netwall-own-ca.sgs and sheet-example-own-ca.txt belong to the own-CA setup. Ignore them here.

Reference setup

Tested on cOS Core 15.00.06.10 (a NetWall virtual firewall in a public cloud, behind NAT), Clavister IdAuth 7.0.2 on Windows Server 2025 with Windows Defender Firewall on, Samba AD, and OneConnect 3.15.4 on Windows 11. No other server. All seven steps were followed as written, from an empty Windows Server, twice: once by the author, and once by a tester who had not seen the guide and had no other help. Both times a member of VPN_GROUP connected and reached only LAN_NET on VPN_PORTS, and a user outside the group was refused. In the tester’s run, Let’s Encrypt’s staging service stood in for the real one, because the weekly limit of 5 certificates for the name was used up. The delete list in “Remove it again” was tested in the author’s run, and the backup in the own-CA run on the same firewall. “Turn off Trust all” was tested on this setup: Test connection said OK and a user signed in; without the CA it said Failure. The AD and DNS commands and “Turn off Trust all” were also run against Windows Server 2025 AD with an AD CS root CA, in a run of the own-CA guide.

In the lab, test tools did the typing: the firewall commands went over SSH from an admin machine, a browser robot filled in the IdAuth wizards with the values shown, and 01-idauth-install.ps1 got its passwords from a wrapper instead of its prompts. None of these tools is part of the setup.

Not tested: an IdAuth that already serves other applications; a firewall with the public address directly on its outside interface; an AD CS with an issuing CA below the root; admins who log in through RADIUS; old IP Rules or rule folders; MFA; an HA firewall; mobile clients; more than one user at a time; rollout to many PCs; the renewals in “Before you go live”, including the automatic renewal of the Let’s Encrypt certificate; what running tunnels do when IdAuth stops or a user leaves VPN_GROUP; putting back the backups of step 4; a new sign-in while the tunnel is still up (for example after sleep); Windows Server versions other than 2025; cOS Core versions other than 15.00.06.

Related articles