Below you will find sections like core, backend, advanced, database, statistics, mail, auth, web and webhook.
Each section describes the individual configuration keys, their default values, and a brief explanation of their purpose.
These are the primary configuration options that control fundamental WireGuard Portal behavior. More advanced options are found in the subsequent Advanced section.
admin_useradmin@wgportal.localadmin_passwordwgportal-defaultdisable_admin_userfalsetrue, no admin user is created. This is useful if you plan to manage users exclusively through external authentication providers such as LDAP or OAuth.admin_api_tokeneditable_keystruecreate_default_peerfalsecreate_default_peer_on_creationfalsere_enable_peer_after_user_enabletruedelete_peer_after_user_deletedfalseself_provisioning_allowedfalseimport_existingtruerestore_statetrueConfiguration options for the WireGuard backend, which manages the WireGuard interfaces and peers. The current MikroTik backend is in BETA and may not support all features.
defaultlocallocal, or other backend id's configured in the mikrotik section.local_resolvconf_prefixtun.tun., but some have an empty prefix (e.g., systemd).ignored_local_interfacesThe mikrotik array contains a list of MikroTik backend definitions. Each entry describes how to connect to a MikroTik RouterOS instance that hosts WireGuard interfaces.
Below are the properties for each entry inside backend.mikrotik:
idbackend.default to use this backend as default. The identifier must be unique across all backends and must not use the reserved keyword local.display_nameid will be used as the display name.api_urlhttps://10.10.10.10:8729/rest.api_userapi_passwordapi_verify_tlsfalsefalse to allow self-signed certificates (not recommended for production).api_timeout30s10s, 1m). If omitted, a default of 30 seconds is used.concurrency50 or negative, a sane default of 5 is used.ignored_interfacesdebugfalseFor more details on configuring the MikroTik backend, see the Backends documentation.
Additional or more specialized configuration options for logging and interface creation details.
log_levelinfotrace, debug, info, warn, error.log_prettyfalsetrue, log messages are colorized and formatted for readability (pretty-print).log_jsonfalsetrue, log messages are structured in JSON format.start_listen_port51820start_cidr_v410.11.12.0/24start_cidr_v6fdfd:d3ad:c0de:1234::0/64use_ip_v6trueconfig_storage_pathwg-quick style configuration files will be stored (if you need local filesystem configs).expiry_check_interval15ms, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.rule_prio_offset20000route_table_offset20000api_admin_onlytruetrue, the public REST API is accessible only to admin users. The API docs live at /api/v1/doc.html.limit_additional_user_peers00 means unlimited.Configuration for the underlying database used by WireGuard Portal. Supported databases include SQLite, MySQL, Microsoft SQL Server, and Postgres.
If sensitive values (like private keys) should be stored in an encrypted format, set the encryption_passphrase option.
debugfalsetrue, logs all database statements (verbose).slow_query_threshold100ms) above which queries are considered slow and logged as warnings. If zero, slow query logging is disabled. Format uses s, ms for seconds, milliseconds, see time.ParseDuration. The value must be a string.typesqlitesqlite, mssql, mysql, postgres.dsndata/sqlite.dbuser:pass@tcp(1.2.3.4:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
-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. By default, emails will only be sent to peers that have a valid user record linked. To send emails to all peers that have a valid email-address as user-identifier, set allow_peer_email to true.
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.allow_peer_emailfalsetrue, and a peer has no valid user record linked, but the user-identifier of the peer is a valid email address, emails will be sent to that email address. If false, and the peer has no valid user record linked, emails will not be sent. If a peer has linked a valid user, the email address is always taken from the user record.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_enabledfalsetrue, a new user will be created in WireGuard Portal if not already present.log_user_infofalsetrue, OIDC user data is logged at the trace level upon login (for debugging).log_sensitive_infofalsetrue, sensitive OIDC user data, such as tokens and raw responses, will be 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_enabledfalsetrue, new users are created automatically on successful login.log_user_infofalsetrue, logs user info at the trace level upon login.log_sensitive_infofalsetrue, sensitive OIDC user data, such as tokens and raw responses, will be logged at the trace level upon login (for debugging).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_tlsfalsetrue, use STARTTLS to secure the LDAP connection.cert_validationfalsetrue, 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))
+Below you will find sections like core, backend, advanced, database, statistics, mail, auth, web and webhook.
Each section describes the individual configuration keys, their default values, and a brief explanation of their purpose.
These are the primary configuration options that control fundamental WireGuard Portal behavior. More advanced options are found in the subsequent Advanced section.
admin_useradmin@wgportal.localWG_PORTAL_CORE_ADMIN_USERadmin_passwordwgportal-defaultWG_PORTAL_CORE_ADMIN_PASSWORDdisable_admin_userfalseWG_PORTAL_CORE_DISABLE_ADMIN_USERtrue, no admin user is created. This is useful if you plan to manage users exclusively through external authentication providers such as LDAP or OAuth.admin_api_tokenWG_PORTAL_CORE_ADMIN_API_TOKENeditable_keystrueWG_PORTAL_CORE_EDITABLE_KEYScreate_default_peerfalseWG_PORTAL_CORE_CREATE_DEFAULT_PEERcreate_default_peer_on_creationfalseWG_PORTAL_CORE_CREATE_DEFAULT_PEER_ON_CREATIONre_enable_peer_after_user_enabletrueWG_PORTAL_CORE_RE_ENABLE_PEER_AFTER_USER_ENABLEdelete_peer_after_user_deletedfalseWG_PORTAL_CORE_DELETE_PEER_AFTER_USER_DELETEDself_provisioning_allowedfalseWG_PORTAL_CORE_SELF_PROVISIONING_ALLOWEDimport_existingtrueWG_PORTAL_CORE_IMPORT_EXISTINGrestore_statetrueWG_PORTAL_CORE_RESTORE_STATEConfiguration options for the WireGuard backend, which manages the WireGuard interfaces and peers. The current MikroTik backend is in BETA and may not support all features.
defaultlocallocal, or other backend id's configured in the mikrotik section.local_resolvconf_prefixtun.WG_PORTAL_BACKEND_LOCAL_RESOLVCONF_PREFIXtun., but some have an empty prefix (e.g., systemd).ignored_local_interfacesWG_PORTAL_BACKEND_IGNORED_LOCAL_INTERFACES (comma-separated values)The mikrotik array contains a list of MikroTik backend definitions. Each entry describes how to connect to a MikroTik RouterOS instance that hosts WireGuard interfaces.
Below are the properties for each entry inside backend.mikrotik:
idbackend.default to use this backend as default. The identifier must be unique across all backends and must not use the reserved keyword local.display_nameid will be used as the display name.api_urlhttps://10.10.10.10:8729/rest.api_userapi_passwordapi_verify_tlsfalsefalse to allow self-signed certificates (not recommended for production).api_timeout30s10s, 1m). If omitted, a default of 30 seconds is used.concurrency50 or negative, a sane default of 5 is used.ignored_interfacesdebugfalseFor more details on configuring the MikroTik backend, see the Backends documentation.
Additional or more specialized configuration options for logging and interface creation details.
log_levelinfoWG_PORTAL_ADVANCED_LOG_LEVELtrace, debug, info, warn, error.log_prettyfalseWG_PORTAL_ADVANCED_LOG_PRETTYtrue, log messages are colorized and formatted for readability (pretty-print).log_jsonfalseWG_PORTAL_ADVANCED_LOG_JSONtrue, log messages are structured in JSON format.start_listen_port51820WG_PORTAL_ADVANCED_START_LISTEN_PORTstart_cidr_v410.11.12.0/24WG_PORTAL_ADVANCED_START_CIDR_V4start_cidr_v6fdfd:d3ad:c0de:1234::0/64WG_PORTAL_ADVANCED_START_CIDR_V6use_ip_v6trueWG_PORTAL_ADVANCED_USE_IP_V6config_storage_pathWG_PORTAL_ADVANCED_CONFIG_STORAGE_PATHwg-quick style configuration files will be stored (if you need local filesystem configs).expiry_check_interval15mWG_PORTAL_ADVANCED_EXPIRY_CHECK_INTERVALs, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.rule_prio_offset20000WG_PORTAL_ADVANCED_RULE_PRIO_OFFSETroute_table_offset20000WG_PORTAL_ADVANCED_ROUTE_TABLE_OFFSETapi_admin_onlytrueWG_PORTAL_ADVANCED_API_ADMIN_ONLYtrue, the public REST API is accessible only to admin users. The API docs live at /api/v1/doc.html.limit_additional_user_peers0WG_PORTAL_ADVANCED_LIMIT_ADDITIONAL_USER_PEERS0 means unlimited.Configuration for the underlying database used by WireGuard Portal. Supported databases include SQLite, MySQL, Microsoft SQL Server, and Postgres.
If sensitive values (like private keys) should be stored in an encrypted format, set the encryption_passphrase option.
debugfalseWG_PORTAL_DATABASE_DEBUGtrue, logs all database statements (verbose).slow_query_thresholdWG_PORTAL_DATABASE_SLOW_QUERY_THRESHOLD100ms) above which queries are considered slow and logged as warnings. If zero, slow query logging is disabled. Format uses s, ms for seconds, milliseconds, see time.ParseDuration. The value must be a string.typesqliteWG_PORTAL_DATABASE_TYPEsqlite, mssql, mysql, postgres.dsndata/sqlite.dbWG_PORTAL_DATABASE_DSNuser:pass@tcp(1.2.3.4:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
+encryption_passphraseWG_PORTAL_DATABASE_ENCRYPTION_PASSPHRASEControls how WireGuard Portal collects and reports usage statistics, including ping checks and Prometheus metrics.
use_ping_checkstrueWG_PORTAL_STATISTICS_USE_PING_CHECKSping_check_workers10WG_PORTAL_STATISTICS_PING_CHECK_WORKERSping_unprivilegedfalseWG_PORTAL_STATISTICS_PING_UNPRIVILEGEDfalse, ping checks run without root privileges. This is currently considered BETA.ping_check_interval1mWG_PORTAL_STATISTICS_PING_CHECK_INTERVALs, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.data_collection_interval1mWG_PORTAL_STATISTICS_DATA_COLLECTION_INTERVALs, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.collect_interface_datatrueWG_PORTAL_STATISTICS_COLLECT_INTERFACE_DATAtrue, collects interface-level data (bytes in/out) for monitoring and statistics.collect_peer_datatrueWG_PORTAL_STATISTICS_COLLECT_PEER_DATAtrue, collects peer-level data (bytes, last handshake, endpoint, etc.).collect_audit_datatrueWG_PORTAL_STATISTICS_COLLECT_AUDIT_DATAtrue, logs certain portal events (such as user logins) to the database.listening_address:8787WG_PORTAL_STATISTICS_LISTENING_ADDRESS:8787 or 127.0.0.1:8787).Options for configuring email notifications or sending peer configurations via email. By default, emails will only be sent to peers that have a valid user record linked. To send emails to all peers that have a valid email-address as user-identifier, set allow_peer_email to true.
host127.0.0.1WG_PORTAL_MAIL_HOSTport25WG_PORTAL_MAIL_PORTencryptionnoneWG_PORTAL_MAIL_ENCRYPTIONnone, tls, starttls.cert_validationtrueWG_PORTAL_MAIL_CERT_VALIDATIONtrue, validate the SMTP server certificate (relevant if encryption = tls).usernameWG_PORTAL_MAIL_USERNAMEpasswordWG_PORTAL_MAIL_PASSWORDauth_typeplainWG_PORTAL_MAIL_AUTH_TYPEplain, login, crammd5.fromWireguard Portal <noreply@wireguard.local>WG_PORTAL_MAIL_FROMlink_onlyfalseWG_PORTAL_MAIL_LINK_ONLYtrue, emails only contain a link to WireGuard Portal, rather than attaching the full configuration.allow_peer_emailfalseWG_PORTAL_MAIL_ALLOW_PEER_EMAILtrue, and a peer has no valid user record linked, but the user-identifier of the peer is a valid email address, emails will be sent to that email address. If false, and the peer has no valid user record linked, emails will not be sent. If a peer has linked a valid user, the email address is always taken from the user record.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_length16WG_PORTAL_AUTH_MIN_PASSWORD_LENGTHhide_login_formfalseWG_PORTAL_AUTH_HIDE_LOGIN_FORMtrue, 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_enabledfalsetrue, a new user will be created in WireGuard Portal if not already present.log_user_infofalsetrue, OIDC user data is logged at the trace level upon login (for debugging).log_sensitive_infofalsetrue, sensitive OIDC user data, such as tokens and raw responses, will be 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_enabledfalsetrue, new users are created automatically on successful login.log_user_infofalsetrue, logs user info at the trace level upon login.log_sensitive_infofalsetrue, sensitive OIDC user data, such as tokens and raw responses, will be logged at the trace level upon login (for debugging).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_tlsfalsetrue, use STARTTLS to secure the LDAP connection.cert_validationfalsetrue, 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_missingfalsetrue, any user not found in LDAP (during sync) is disabled in WireGuard Portal.auto_re_enablefalsetrue, users that where disabled because they were missing (see disable_missing) will be re-enabled once they are found again.registration_enabledfalsetrue, new user accounts are created in WireGuard Portal upon first login.log_user_infofalsetrue, 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. Further details can be found in the usage documentation.
urlauthenticationBearer <token>.timeout10s