encryption_passphraseControls how WireGuard Portal collects and reports usage statistics, including ping checks and Prometheus metrics.
use_ping_checkstrueping_check_workers10ping_unprivilegedfalsefalse, ping checks run without root privileges. This is currently considered BETA.ping_check_interval1ms, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.data_collection_interval1ms, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.collect_interface_datatruetrue, collects interface-level data (bytes in/out) for monitoring and statistics.collect_peer_datatruetrue, collects peer-level data (bytes, last handshake, endpoint, etc.).collect_audit_datatruetrue, logs certain portal events (such as user logins) to the database.listening_address:8787:8787 or 127.0.0.1:8787).Options for configuring email notifications or sending peer configurations via email.
host127.0.0.1port25encryptionnonenone, tls, starttls.cert_validationtruetrue, validate the SMTP server certificate (relevant if encryption = tls).usernamepasswordauth_typeplainplain, login, crammd5.fromWireguard Portal <noreply@wireguard.local>link_onlyfalsetrue, emails only contain a link to WireGuard Portal, rather than attaching the full configuration.WireGuard Portal supports multiple authentication strategies, including OpenID Connect (oidc), OAuth (oauth), Passkeys (webauthn) and LDAP (ldap). Each can have multiple providers configured. Below are the relevant keys.
Some core authentication options are shared across all providers, while others are specific to each provider type.
min_password_length16hide_login_formfalsetrue, the login form is hidden and only the OIDC, OAuth, LDAP, or WebAuthn providers are shown. This is useful if you want to enforce a specific authentication method. If no social login providers are configured, the login form is always shown, regardless of this setting.?all query parameter to the login URL (e.g. https://wg.portal/#/login?all). The oidc array contains a list of OpenID Connect providers. Below are the properties for each OIDC provider entry inside auth.oidc:
provider_namedisplay_namebase_urlhttps://accounts.google.com).client_idclient_secretextra_scopesprofile, email).allowed_domainsfield_mapAvailable fields: user_identifier, email, firstname, lastname, phone, department, is_admin, user_groups.
| Field | Typical OIDC Claim | Explanation |
|---|---|---|
user_identifier | sub or preferred_username | A unique identifier for the user. Often the OIDC sub claim is used because it’s guaranteed to be unique for the user within the IdP. Some providers also support preferred_username if it’s unique. |
email | email | The user’s email address as provided by the IdP. Not always verified, depending on IdP settings. |
firstname | given_name | The user’s first name, typically provided by the IdP in the given_name claim. |
lastname | family_name | The user’s last (family) name, typically provided by the IdP in the family_name claim. |
phone | phone_number | The user’s phone number. This may require additional scopes/permissions from the IdP to access. |
department | Custom claim (e.g., department) | If the IdP can provide organizational data, it may store it in a custom claim. Adjust accordingly (e.g., department, org, or another attribute). |
is_admin | Custom claim or derived role | If the IdP returns a role or admin flag, you can map that to is_admin. Often this is managed through custom claims or group membership. |
user_groups | groups or another custom claim | A list of group memberships for the user. Some IdPs provide groups out of the box; others require custom claims or directory lookups. |
admin_mappingis_admin claim against a regular expression. Alternatively, a regular expression can be used to check if a user is member of a specific group listed in the user_group claim. The regular expressions are defined in admin_value_regex and admin_group_regex.admin_value_regex: A regular expression to match the is_admin claim. By default, this expression matches the string "true" (^true$).admin_group_regex: A regular expression to match the user_groups claim. Each entry in the user_groups claim is checked against this regex.registration_enabledtrue, a new user will be created in WireGuard Portal if not already present.log_user_infotrue, OIDC user data is logged at the trace level upon login (for debugging).The oauth array contains a list of plain OAuth2 providers. Below are the properties for each OAuth provider entry inside auth.oauth:
provider_namedisplay_nameclient_idclient_secretauth_urltoken_urluser_info_urlscopesallowed_domainsfield_mapAvailable fields: user_identifier, email, firstname, lastname, phone, department, is_admin, user_groups.
| Field | Typical Claim | Explanation |
|---|---|---|
user_identifier | sub or preferred_username | A unique identifier for the user. Often the OIDC sub claim is used because it’s guaranteed to be unique for the user within the IdP. Some providers also support preferred_username if it’s unique. |
email | email | The user’s email address as provided by the IdP. Not always verified, depending on IdP settings. |
firstname | given_name | The user’s first name, typically provided by the IdP in the given_name claim. |
lastname | family_name | The user’s last (family) name, typically provided by the IdP in the family_name claim. |
phone | phone_number | The user’s phone number. This may require additional scopes/permissions from the IdP to access. |
department | Custom claim (e.g., department) | If the IdP can provide organizational data, it may store it in a custom claim. Adjust accordingly (e.g., department, org, or another attribute). |
is_admin | Custom claim or derived role | If the IdP returns a role or admin flag, you can map that to is_admin. Often this is managed through custom claims or group membership. |
user_groups | groups or another custom claim | A list of group memberships for the user. Some IdPs provide groups out of the box; others require custom claims or directory lookups. |
admin_mappingis_admin claim against a regular expression. Alternatively, a regular expression can be used to check if a user is member of a specific group listed in the user_group claim. The regular expressions are defined in admin_value_regex and admin_group_regex.admin_value_regex: A regular expression to match the is_admin claim. By default, this expression matches the string "true" (^true$).admin_group_regex: A regular expression to match the user_groups claim. Each entry in the user_groups claim is checked against this regex.registration_enabledtrue, new users are created automatically on successful login.log_user_infotrue, logs user info at the trace level upon login.The ldap array contains a list of LDAP authentication providers. Below are the properties for each LDAP provider entry inside auth.ldap:
provider_nameurlldap://srv-ad01.company.local:389).start_tlstrue, use STARTTLS to secure the LDAP connection.cert_validationtrue, validate the LDAP server’s TLS certificate.tls_certificate_pathtls_key_pathbase_dnDC=COMPANY,DC=LOCAL).bind_usercompany\\ldap_wireguard or ldap_wireguard@company.local).bind_passfield_mapDescription: Maps LDAP attributes to WireGuard Portal fields.
user_identifier, email, firstname, lastname, phone, department, memberof.| WireGuard Portal Field | Typical LDAP Attribute | Short Description |
|---|---|---|
| user_identifier | sAMAccountName / uid | Uniquely identifies the user within the LDAP directory. |
| mail / userPrincipalName | Stores the user's primary email address. | |
| firstname | givenName | Contains the user's first (given) name. |
| lastname | sn | Contains the user's last (surname) name. |
| phone | telephoneNumber / mobile | Holds the user's phone or mobile number. |
| department | departmentNumber / ou | Specifies the department or organizational unit of the user. |
| memberof | memberOf | Lists the groups and roles to which the user belongs. |
login_filter{{login_identifier}} to insert the username. For example: (&(objectClass=organizationalPerson)(mail={{login_identifier}})(!userAccountControl:1.2.840.113556.1.4.803:=2))
login_filter must always be a valid LDAP filter. It should at most return one user. If the filter returns multiple or no users, the login will fail.admin_groupCN=WireGuardAdmins,OU=Some-OU,DC=YOURDOMAIN,DC=LOCAL
sync_interval30m) to synchronize users from LDAP. Empty or 0 disables sync. Format uses s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration. Only users that match the sync_filter are synchronized, if disable_missing is true, users not found in LDAP are disabled.sync_filter(&(objectClass=organizationalPerson)(!userAccountControl:1.2.840.113556.1.4.803:=2)(mail=*))
-disable_missingtrue, any user not found in LDAP (during sync) is disabled in WireGuard Portal.auto_re_enabletrue, users that where disabled because they were missing (see disable_missing) will be re-enabled once they are found again.registration_enabledtrue, new user accounts are created in WireGuard Portal upon first login.log_user_infotrue, logs LDAP user data at the trace level upon login.The webauthn section contains configuration options for WebAuthn authentication (passkeys).
enabledtruetrue, Passkey authentication is enabled. If false, WebAuthn is disabled. Users are encouraged to use Passkeys for secure authentication instead of passwords. If a passkey is registered, the password login is still available as a fallback. Ensure that the password is strong and secure.The web section contains configuration options for the web server, including the listening address, session management, and CSRF protection. It is important to specify a valid external_url for the web server, especially if you are using a reverse proxy. Without a valid external_url, the login process may fail due to CSRF protection.
listening_address:8888:8888 to bind on all interfaces or 127.0.0.1:8888 to bind only on the loopback interface). Ensure that access to WireGuard Portal is protected against unauthorized access, especially if binding to all interfaces.external_urlhttp://localhost:8888site_company_nameWireGuard Portalsite_titleWireGuard Portalsession_identifierwgPortalSessionsession_secretvery_secretcsrf_secretextremely_secretrequest_loggingfalseexpose_host_infofalsecert_filekey_fileThe webhook section allows you to configure a webhook that is called on certain events in WireGuard Portal. A JSON object is sent in a POST request to the webhook URL with the following structure:
{
- "event": "update",
- "entity": "peer",
- "identifier": "the-peer-identifier",
- "payload": {
- // The payload of the event, e.g. peer data.
- // Check the API documentation for the exact structure.
- }
-}
-Further details can be found in the usage documentation.
urlauthenticationBearer <token>.timeout10s