CHARON-CMD(8)

πŸ“¦
version 6.0.7 Β· 4 versions
, in fedora 43, fedora 44

πŸ’– CHARON-CMD πŸ’–

okay bestie, gather round, because we're talking about charon-cmd, the little cutie from the strongSwan family (manual section 8, iykyk) β€” a Simple IKE client, aka your IPsec VPN client. she's giving ✨road warrior✨ energy and honestly? obsessed.


🌸 SYNOPSIS 🌸

charon-cmd --host hostname --identity identity [ options ]

πŸ¦‹ DESCRIPTION πŸ¦‹

so charon-cmd is the program that sets up your IPsec VPN connections using the Internet Key Exchange protocol β€” IKE, and yes she does version 1 AND version 2, versatile queen πŸ‘‘. she supports a whole bunch of different road-warrior scenarios, so whatever your setup is, she probably ate.

Like the IKE daemon charon, charon-cmd has to be run as root (or, more specifically, as a user with the CAP_NET_ADMIN capability). no cap, that's just how it is πŸ’….

Out of all the options below, at least --host and --identity are required. and depending on which authentication profile you picked, you'll also need to hand over credentials with their respective options. no credentials, no vibes, no connection 🫢.

Also! Many of the charon-specific configuration options in strongswan.conf apply to charon-cmd too. For instance, if you wanna configure customized logging to stdout, this snippet right here is the move:

charon-cmd {
     filelog {
          stdout {
               default = 1
               ike = 2
               cfg = 2
          }
     }
}

✨ OPTIONS ✨

  • --help β€” prints usage information plus a short summary of all the available options. your lil cheat sheet fr.
  • --version β€” prints the strongSwan version.
  • --debug level β€” sets the default log level (defaults to 1). level is a number between -1 and 4. wanna get real granular with it? refer to strongswan.conf for the options that let you fine-tune the logging output πŸ’….
  • --host hostname β€” DNS name or IP address to connect to.
  • --identity identity β€” the identity the client uses for the IKE exchange.
  • --eap-identity identity β€” the identity the client uses for EAP authentication.
  • --xauth-username username β€” the username the client uses for XAuth authentication.
  • --remote-identity identity β€” the server identity to expect, defaults to hostname.
  • --cert path β€” trusted certificate, either for authentication or trust chain validation. to provide more than one certificate, just use multiple --cert options, stack 'em up πŸŽ€.
  • --rsa path β€” RSA private key to use for authentication (if a password is required, it will be requested on demand). for other key types, use --priv instead.
  • --priv path β€” private key to use for authentication (if a password is required, it will be requested on demand).
  • --p12 path β€” PKCS#12 file with private key and certificates, to use for authentication and trust chain validation (if a password is required it will be requested on demand).
  • --agent[=socket] β€” use the SSH agent for authentication. if socket isn't specified, it's read from the SSH_AUTH_SOCK environment variable 🌈.
  • --local-ts subnet β€” an additional traffic selector to propose for our side. the requested virtual IP address will always be proposed, periodt.
  • --remote-ts subnet β€” traffic selector to propose for the remote side, defaults to 0.0.0.0/0.
  • --ike-proposal proposal β€” IKE proposal to offer instead of the default. for IKEv1, a single proposal consists of one encryption algorithm, an integrity/PRF algorithm and a DH group. IKEv2 can propose multiple algorithms of the same kind. to specify multiple proposals, just repeat the option.
  • --esp-proposal proposal β€” ESP proposal to offer instead of the default. for IKEv1, a single proposal consists of one encryption algorithm, an integrity algorithm and an optional DH group for Perfect Forward Secrecy rekeying. IKEv2 can propose multiple algorithms of the same kind. to specify multiple proposals, repeat the option.
  • --ah-proposal proposal β€” AH proposal to offer instead of ESP. for IKEv1, a single proposal consists of an integrity algorithm and an optional DH group for Perfect Forward Secrecy rekeying. IKEv2 can propose multiple algorithms of the same kind. to specify multiple proposals, repeat the option.
  • --profile name β€” the authentication profile to use. the list of supported profiles lives in the Authentication Profiles sections right below πŸ‘‡. defaults to ikev2-pub if a private key was supplied, and to ikev2-eap otherwise.

πŸ’œ IKEv2 Authentication Profiles πŸ’œ

  • ikev2-pub β€” IKEv2 with public key client and server authentication.
  • ikev2-eap β€” IKEv2 with EAP client authentication and public key server authentication.
  • ikev2-pub-eap β€” IKEv2 with public key and EAP client authentication (RFC 4739) and public key server authentication.

🧚 IKEv1 Authentication Profiles 🧚

the following authentication profiles use either Main Mode or Aggressive Mode β€” the latter is denoted with a -am suffix, so you'll always know which one you're getting πŸ‘‘

  • ikev1-pub, ikev1-pub-am β€” IKEv1 with public key client and server authentication.
  • ikev1-xauth, ikev1-xauth-am β€” IKEv1 with public key client and server authentication, followed by client XAuth authentication.
  • ikev1-xauth-psk, ikev1-xauth-psk-am β€” IKEv1 with pre-shared key (PSK) client and server authentication, followed by client XAuth authentication. (INSECURE!) β€” like, genuinely, bestie, be careful with this one 😭.
  • ikev1-hybrid, ikev1-hybrid-am β€” IKEv1 with public key server authentication only, followed by client XAuth authentication.

⭐ SEE ALSO ⭐

strongswan.conf(5), ipsec(8)


aaaand that's the whole thing πŸ’– this page is from strongSwan version 6.0.7, dated 2013-06-21 β€” vintage, iconic, still slaying. go set up that VPN, you've got this 🫢✨

πŸ“¦ where this page comes from