VPN Profile Import for the Android VPN Client¶
The app will open
http(s):// URLs to
.sswan files. It also opens any file with a media type of
application/vnd.strongswan.profile (the file extension doesn't matter in that case). The latter should also work for email attachments if the media type is set accordingly.
Whether downloaded files for which the media type is not correct but the extension is
.sswan can be opened depends on the app that starts the Intent. For instance, from Android's default Downloads app it won't work due to the
content:// URLs that do not contain the original file name (it works if the media type was set correctly by the web server), but when e.g. opening the downloaded file from within Chrome's Downloads view it works as these Intents use
file:// URLs that contain the complete file name.
Since 1.9.0 it is possible to browse for profile files via SAF, which should also work if the file extension and/or media type is not correct.
Note that after importing the profile the user is able to edit it freely.
The file format is based on JSON. The expected encoding is UTF-8.
The top-level element in the file is an object that may (or must) contain the following keys. Keys of sub-objects are separated with dots.
|x||uuid||Unique identifier to identify the VPN profile. The format is defined in RFC 4122. Version 4 UUIDs (random-generated) are recommended (may be created with e.g.
If a VPN profile with the same UUID already exists its settings are replaced when the profile is imported.
|x||name||Display name of the profile.|
|x||type||Type of the VPN profile. The following values are currently supported and determine the type of client authentication that's used (the server is always authenticated with a certificate).
ikev2-eap: Username/password-based EAP authentication
ikev2-cert: Certificate authentication
ikev2-cert-eap: Certificate authentication followed by a username/password-based EAP authentication
ikev2-eap-tls: EAP-TLS certificate authentication
ikev2-byod-eap: EAP-TNC with username/password-based EAP authentication
Some of the keys described below are only relevant for certain types.
|x||remote||Object containing information about the server.|
|x||remote.addr||The server's hostname or IP address. If no remote identity is configured this has to be contained as subjectAltName extension in the server certificate.|
|remote.port||Optional server port (default is 500).|
|remote.id||Optional IKE identity of the server. If this is not configured it defaults to remote.addr and no IDr is sent in the IKE_AUTH request.|
|remote.cert||Optional Base64-encoded CA or server certificate. Is imported into the app, not the system keystore. If not set, automatic CA certificate selection is enabled. So it's not necessary, if the server certificate is issued by a CA the client already trusts, or if the PKCS#12-file below contains the complete certificate chain (this might cause warnings on older Android releases, though, see AndroidVPNClient for details).|
|remote.certreq||Whether to send certificate requests for all installed or selected CA certificates. Disabling this may reduce the size of the IKE_AUTH message if the server does not support fragmentation. But it only works if the server doesn't require certificate requests to send back the server certificate. Since 1.9.0.|
|local||Object containing information about the client.|
|local.eap_id||Optional identity/username for EAP authentication. If this is required (for username/password-based EAP authentication) but not configured here, the user is prompted for it when importing the profile. If it is set the user is not able to change it while importing (but may later do so). In both cases the user may optionally enter the password while importing the profile.|
|local.id||Optional IKE identity of the client for certificate authentication. Has to match a subjectAltName contained in the client certificate. Must not be configured if the certificate's subject DN shall be used as client identity.|
|local.p12||Optional Base64-encoded PKCS#12-container with the client certificate and private key and optional certificate chain (the latter might cause warnings on older Android releases, see AndroidVPNClient for details). Not necessary for username/password-based EAP authentication, or if the user already has the certificate/key installed as it may be selected while importing the profile.|
|split-tunneling||Optional object containing split-tunneling settings.|
|split-tunneling.subnets||An array of subnets (in CIDR notation), IP addresses or ranges (IP-IP) to route via VPN. All other traffic is forwarded as if there was no VPN. This is only relevant locally, these subnets are not sent to the server. Since 1.9.0.|
|split-tunneling.excluded||An array of subnets (in CIDR notation), IP addresses or ranges (IP-IP) to exclude from the VPN. Matching traffic is forwarded as if there was no VPN. This is only relevant locally. Since 1.9.0.|
|split-tunneling.block-ipv4||Whether to block IPv4 traffic that's not destined for the VPN. Forces all IPv4 traffic via VPN (traffic that does not match the negotiated traffic selector is then just dropped), so it's basically the same as including
|split-tunneling.block-ipv6||Whether to block IPv6 traffic that's not destined for the VPN. Forces all IPv6 traffic via VPN (traffic that does not match the negotiated traffic selector is then just dropped), so it's basically the same as including
|apps||Optional array of package names (e.g.
|excluded-apps||Optional array of package names (e.g.
|ike-proposal||Optional custom IKE proposal, that is, a list of algorithm identifiers separated by hyphens. For non-AEAD/classic encryption algorithms, an integrity algorithm, a pseudo random function (optional, defaults to one based on the integrity algorithm) and a Diffie-Hellman group are required (e.g. aes256-sha256-ecp256). For combined-mode/AEAD algorithms, the integrity algorithm is omitted but a PRF is required (e.g. aes256gcm16-prfsha256-ecp256). Since 1.9.5|
|esp-proposal||Optional custom ESP proposal, that is, a list of algorithm identifiers separated by hyphens. For non-AEAD/classic encryption algorithms, an integrity algorithm is required, a Diffie-Hellman group is optional (e.g. aes256-sha256 or aes256-sha256-ecp256). For combined-mode/AEAD algorithms, the integrity algorithm is omitted (e.g. aes256gcm16 or aes256gcm16-ecp256). If a DH group is specified IPsec SA rekeying will use a DH key exchange. However, DH groups specified here are not used when the connection is established initially because the keys there are derived from the IKE SA key material. Therefore, any configuration mismatch with the server will only cause errors later during rekeying. Since 1.9.5|
|mtu||Optional MTU to use for the TUN device|
|nat-keepalive||Optional interval for NAT-T keepalive packets. Since 1.9.0.|