ISAKMPD.POLICY(5)

📦 in ubuntu jammy

💖 ISAKMPD.POLICY — the policy config file for isakmpd, bestie 💖

okay so real talk, this is the isakmpd.policy manual, section 5 of the file formats manual, and it is lowkey a whole vibe. buckle up, we're gonna go through it together and it's gonna slay. 🦋

✨ NAME ✨

isakmpd.policy — the policy configuration file for isakmpd, no cap.

🌸 DESCRIPTION 🌸

So isakmpd.policy is literally the policy configuration file for the isakmpd daemon — and that daemon is the one managing security association and key management for the ipsec(4) layer of your kernel's networking stack. iconic behavior honestly.

The isakmpd(8) daemon (which, btw, also goes by IKE, short for Internet Key Exchange, iykyk) is the whole reason this exists: it's what you use when two systems need to automatically set up a pair of Security Associations (SAs) so they can talk securely using IPsec. and IKE does all this in two stages, so let's break it down.

Stage one — the first stage — is called Main or Identity Protection Mode. here the two IKE daemons establish a secure link between themselves, fully authenticating each other and establishing key material for encrypting/authenticating future communications between them. this step is typically only performed once for every pair of IKE daemons. one and done, periodt. 💅

Stage two — also called Quick Mode — is where the two IKE daemons create the pair of SAs for the parties that actually want to communicate using IPsec. and those parties can be:

  • the hosts the IKE daemons run on,
  • a host and a network behind a firewall,
  • or two networks behind their respective firewalls.

at this stage, the exact parameters of the SAs get specified (think: algorithms to use, encapsulation mode, lifetime) along with the identities of the communicating parties (hosts, networks, etc.). the reason Quick Mode exists is to allow for fast SA setup, once the more heavy-weight Main Mode has been completed. generally, Quick Mode uses the key material derived from Main Mode to provide keys to the IPsec transforms to be used. alternatively, a new Diffie-Hellman computation may be performed — which significantly slows down the exchange, but at the same time provides Perfect Forward Secrecy (PFS). briefly: this means that even should an attacker manage to break long-term keys used in other sessions (or, specifically, if an attacker breaks the Diffie-Hellman exchange performed during Main Mode), they will not be able to decrypt this traffic. 🛡️ normally though, no PFS is provided — the key material used by the IPsec SAs established as a result of this exchange will be derived from the key material of the Main Mode exchange — which allows for a faster Quick Mode exchange (no public key computations). trade-offs, bestie, trade-offs.

IKE proposals are basically "suggestions" 👀 — from the initiator of an exchange to the responder — about what protocols and attributes should be used on a class of packets. for example, a given exchange may ask for ESP with 3DES and MD5 and AH with SHA1 (applied successively on the same packet), or just ESP with Blowfish and RIPEMD-160. the responder examines the proposals and determines which of them are acceptable, according to policy and any credentials. it's giving ✨negotiation✨.

heads up, the following paragraphs assume some knowledge of the contents of the keynote(4) and keynote(5) man pages. so if you haven't read those yet… bestie, go read those. 🙈

In the KeyNote policy model for IPsec, no distinction is currently made based on the ordering of AH and ESP in the packet. should this change in the future, an appropriate attribute (see below) will be added. noted. 📝

So the goal of security policy for IKE is to determine — based on local policy (provided in the isakmpd.policy file), credentials provided during the IKE exchanges (or obtained through other means), the SA attributes proposed during the exchange, and perhaps other (side-channel) information — whether a pair of SAs should be installed in the system. and yes, that means whether both the IPsec SAs and the flows should be installed. for each proposal suggested by or to the remote IKE daemon, the KeyNote system is consulted as to whether the proposal is acceptable, based on local policy (contained in isakmpd.policy, in the form of policy assertions) and remote credentials (e.g., KeyNote credentials or X509 certificates provided by the remote IKE daemon).

isakmpd.policy is simply a flat ascii(7) file containing KeyNote policy assertions, separated by blank lines. and fr fr, note that KeyNote assertions may not contain blank lines. isakmpd.policy is read when isakmpd(8) is first started, and every time it receives a SIGHUP signal. the new policies read will be used for all new Phase 2 (IPsec) SAs established from that point on — even if the associated Phase 1 SA was already established when the new policies were loaded. but plot twist: the policy change will not affect already established Phase 2 SAs. so don't come for the old ones, they're grandfathered in. 💀

For more details on KeyNote assertion format, please see keynote(5). but briefly, KeyNote policy assertions used in IKE have these characteristics:

  • The Authorizer field is typically "POLICY" — but see the examples below, for use of policy delegation.
  • The Licensees field can be an expression of passphrases used for authentication of the Main Mode exchanges, and/or public keys (typically, X509 certificates), and/or X509 distinguished names.
  • The Conditions field contains an expression of attributes from the IPsec policy action set (see below as well as the keynote syntax man page for more details).
  • The ordered return-values set for IPsec policy is "false, true".

For an explanation of these fields and their semantics, see keynote(5).

🎀 the examples, because they eat every time 🎀

okay so, for example, this policy assertion:

Authorizer: "POLICY"
Licensees: "passphrase:foobar" || "x509-base64:abcd==" ||
  "passphrase-md5-hex:3858f62230ac3c915f300c664312c63f" ||
  "passphrase-sha1-hex:8843d7f92416211de9ebb963ff4ce28125932878"
Conditions: app_domain == "IPsec policy" && esp_present == "yes"
            && esp_enc_alg != "null" -> "true";

says that any proposal from a remote host that authenticates using the passphrase "foobar" or the public key contained in the X509 certificate encoded as "abcd==" will be accepted — as long as it contains ESP with a non-null algorithm (i.e., the packet will be encrypted 🔐). and the last two authorizers are the MD5 and SHA1 hashes respectively of the passphrase "foobar". this form may be used instead of the "passphrase:..." one to protect the passphrase as included in the policy file (or as distributed in a signed credential). sneaky but make it secure. 😌

and this policy assertion:

Authorizer: "POLICY"
Licensees: "DN:/CN=CA Certificate"
Conditions: app_domain == "IPsec policy" && esp_present == "yes"
            && esp_enc_alg != "null" -> "true";

is similar to the previous one, but instead of including a complete X509 credential in the Licensees field, only the X509 certificate's Subject Canonical Name needs to be specified. note that the "DN:" prefix is necessary — do not forget it, bestie, I am begging. 🙏

KeyNote credentials have the same format as policy assertions, with one difference: the Authorizer field always contains a public key, and the assertion is signed — and thus its integrity can be cryptographically verified. 🔏 credentials are used to build chains of delegation of authority. they can be exchanged during an IKE exchange, or can be retrieved through some out-of-band mechanism — although ngl, no such mechanism is currently supported in this implementation. see isakmpd.conf(5) on how to specify what credentials to send in an IKE exchange.

Passphrases that appear in the Licensees field are encoded as the string "passphrase:", followed by the passphrase itself (case-sensitive!!). alternatively — and preferably — they may be encoded using the "passphrase-md5-hex:" or "passphrase-sha1-hex:" prefixes, followed by the md5(1) or sha1(1) hash of the passphrase itself, encoded as a hexadecimal string (using lower-case letters only). lowercase only, bestie, we are not yelling in hex. 💅

When X509-based authentication is performed in Main Mode, any X509 certificates received from the remote IKE daemon are converted to very simple KeyNote credentials. the conversion is straightforward:

  • the issuer of the X509 certificate becomes the Authorizer of the KeyNote credential,
  • the subject becomes the only Licensees entry,
  • while the Conditions field simply asserts that the credential is only valid for "IPsec policy" use (see the app_domain action attribute below).

Similarly, any X509 CA certificates present in the directory pointed to by the appropriate isakmpd.conf(5) entry are converted to such pseudo-credentials. this allows you to write KeyNote policies that delegate specific authority to CAs (and the keys those CAs certify, recursively). it's giving delegation trees and honestly? we love to see it. 🌳

For more details on KeyNote assertion format, see keynote(5). (yes again, it's that important, go read it.)

🦋 the action set, aka the ✨lore✨ 🦋

Information about the proposals, the identity of the remote IKE daemon, the packet classes to be protected, etc. are encoded in what is called an action set. the action set is composed of name-value attributes, similar in some ways to shell environment variables. these values are initialized by isakmpd before each query to the KeyNote system, and can be tested against in the Conditions field of assertions. see keynote(4) and keynote(5) for more details on the format and semantics of the Conditions field.

note that assertions and credentials can make references to non-existent attributes without catastrophic failures. access may be denied, depending on the overall structure, but it will not be accidentally granted. phew. 😮‍💨 one reason for credentials referencing non-existent attributes is that they were defined within a specific implementation or network only.

In the following attribute set, IPv4 addresses are encoded as ASCII strings in the usual dotted-quad format. however, all quads are three digits long. for example, the IPv4 address 10.128.1.12 would be encoded as 010.128.001.012. similarly, IPv6 addresses are encoded in the standard x:x:x:x:x:x:x:x format, where the x's are the hexadecimal values of the eight 16-bit pieces of the address — and all x's are four digits long. for example, the address 1080:0:12:0:8:800:200C:417A would be encoded as 1080:0000:0012:0000:0008:0800:200C:417A. zero-padding is the moment, periodt. ⭐

The following attributes are currently defined:

  • app_domain — always set to IPsec policy.
  • doi — always set to ipsec.
  • initiator — set to yes if the local daemon is initiating the Phase 2 SA, no otherwise.
  • phase_1 — set to aggressive if aggressive mode was used to establish the Phase 1 SA, or main if main mode was used instead.
  • pfs — set to yes if a Diffie-Hellman exchange will be performed during this Quick Mode, no otherwise.
  • ah_present, esp_present, comp_present — set to yes if an AH, ESP, or compression proposal was received respectively, no otherwise.
  • ah_hash_alg — one of md5, sha, ripemd, sha2-256, sha2-385, sha2-512, or des, based on the hash algorithm specified in the AH proposal. this attribute describes the generic transform to be used in the AH authentication.
  • esp_enc_alg — one of des, des-iv64, 3des, rc4, idea, cast, blowfish, 3idea, des-iv32, rc4, null, or aes, based on the encryption algorithm specified in the ESP proposal.
  • comp_alg — one of oui, deflate, lzs, or v42bis, based on the compression algorithm specified in the compression proposal. 💖
  • ah_auth_alg — one of hmac-md5, hmac-sha, des-mac, kpdk, hmac-sha2-256, hmac-sha2-385, hmac-sha2-512, or hmac-ripemd. Based on the authentication method specified in the AH proposal. ✨
  • esp_auth_alg — one of hmac-md5, hmac-sha, des-mac, kpdk, hmac-sha2-256, hmac-sha2-385, hmac-sha2-512, or hmac-ripemd, based on the authentication method specified in the ESP proposal. 🦋
  • ah_life_seconds, esp_life_seconds, comp_life_seconds — set to the lifetime of the AH, ESP, and compression proposal, in seconds. If no lifetime was proposed for the corresponding protocol (e.g., there was no proposal for AH), the corresponding attribute will be set to zero. Not zero as in cool, zero as in nothing. 😭
  • ah_life_kbytes, esp_life_kbytes, comp_life_kbytes — set to the lifetime of the AH, ESP, and compression proposal, in kbytes of traffic. If no lifetime was proposed for the corresponding protocol (e.g., there was no proposal for AH), the corresponding attribute will be set to zero. Again. 💀
  • ah_encapsulation, esp_encapsulation, comp_encapsulation — set to tunnel or transport, based on the AH, ESP, and compression proposal. Choose your encapsulation era. 🚇
  • ah_ecn, esp_ecn, comp_ecn — set to yes or no, based on whether ECN was requested for the IPsec tunnel. ECN said yes? Then yes. 🌈
  • comp_dict_size — specifies the log2 maximum size of the dictionary, according to the compression proposal. log2 bestie 📚
  • comp_private_alg — set to an integer specifying the private algorithm in use, according to the compression proposal. 🔢
  • ah_key_length, esp_key_length — the number of key bits to be used by the authentication and encryption algorithms respectively (for variable key-size algorithms). 🔑
  • ah_key_rounds, esp_key length — the number of rounds of the authentication and encryption algorithms respectively (for variable round algorithms). Yes, esp_key length with a space. We don't fix typos here, we preserve them. 🙈
  • ah_group_desc, esp_group_desc, comp_group_desc — the Diffie-Hellman group identifier from the AH, ESP, and compression proposal, used for PFS during Quick Mode (see the pfs attribute above). If more than one of these attributes are set to a value other than zero, they should have the same value (in valid IKE proposals). Valid values are 1 (768-bit MODP), 2 (1024-bit MODP), 3 (155-bit EC), 4 (185-bit EC), and 5 (1536-bit MODP). Slay. 👑
  • phase1_group_desc — the Diffie-Hellman group identifier used in IKE Phase 1. Takes the same values as ah_group_desc. Same energy, different phase. 💅
  • remote_filter_type, local_filter_type, remote_id_type — set to IPv4 address, IPv4 range, IPv4 subnet, IPv6 address, IPv6 range, IPv6 subnet, FQDN, User FQDN, ASN1 DN, ASN1 GN, or Key ID, based on the Quick Mode Initiator ID, Quick Mode Responder ID, and Main Mode peer ID respectively. So many types, so little time. 🎀
  • remote_filter_addr_upper, local_filter_addr_upper, remote_id_addr_upper — when the corresponding filter_type is IPv4 address or IPv6 address, these contain the respective address. For IPv4 range or IPv6 range, they contain the upper end of the address range. For IPv4 subnet or IPv6 subnet, they contain the highest address in the specified subnet. Upper, upper, upper. 📈
  • remote_filter_addr_lower, local_filter_addr_lower, remote_id_addr_lower — when the corresponding filter_type is IPv4 address or IPv6 address, these contain the respective address. For IPv4 range or IPv6 range, they contain the lower end of the address range. For IPv4 subnet or IPv6 subnet, they contain the lowest address in the specified subnet. Lower, lower, lower. 📉
  • remote_filter, local_filter, remote_id — when the corresponding filter_type specifies an address range or subnet, these are set to the upper and lower part of the address space separated by a dash (-) character (if the type specifies a single address, they are set to that address).

For FQDN and User FQDN types, these are set to the respective string. For Key ID, these are set to the hexadecimal representation of the associated byte string (lower-case letters used) if the Key ID payload contains non-printable characters. Otherwise, they are set to the respective string.

For ASN1 DN, these are set to the text encoding of the Distinguished Name in the payload sent or received. The format is the same as that used in the Licensees field. Iconic. 🌟

  • remote_filter_port, local_filter_port, remote_id_port — set to the transport protocol port. Simple as that. 🚪
  • remote_filter_proto, local_filter_proto, remote_id_proto — set to etherip, tcp, udp, or the transport protocol number, depending on the transport protocol set in the IDci, IDcr, and Main Mode peer ID respectively. Protocol vibes. 🌐
  • remote_negotiation_address — set to the IPv4 or IPv6 address of the remote IKE daemon. Where the remote at? 📡
  • local_negotiation_address — set to the IPv4 or IPv6 address of the local interface used by the local IKE daemon for this exchange. Home base. 🏠
  • GMTTimeOfDay — set to the UTC date/time, in YYYYMMDDHHmmSS format. UTC o'clock. ⏰
  • LocalTimeOfDay — set to the local date/time, in YYYYMMDDHHmmSS format. Local time bestie. 🕰️

✨ FILES ✨

  • /etc/isakmpd/isakmpd.policy — the default isakmpd policy configuration file. The main character. 👑
  • /usr/share/ipsec/isakmpd/policy — a sample isakmpd policy configuration file. For inspo. 🌸

✨ EXAMPLES ✨

Okay bestie, this is the part where it all clicks, I promise. 💖 Here are some real live policy assertions you can literally copy-paste into your own policy file. Let's go one by one.

Example the first: the bare minimum 🎀

Authorizer: "POLICY"
Comment: This bare-bones assertion accepts everything

That's it. That's the whole thing. POLICY authorizing everything, no conditions, no nothing. It's giving "yes ma'am, come on in". 💅

Example two: shared-secret + real encryption 🔐

Authorizer: "POLICY"
Licensees: "passphrase-md5-hex:10838982612aff543e2e62a67c786550"
Comment: This policy accepts anyone using shared-secret
         authentication using the password mekmitasisgoat,
         and does ESP with some form of encryption (not null).
Conditions: app_domain == "IPsec policy" &&
            esp_present == "yes" &&
            esp_enc_alg != "null" -> "true";

So what's happening: this one accepts anyone using shared-secret authentication with the password mekmitasisgoat, and it only does ESP with some form of encryption — not null, absolutely not, we do not do plaintext in this house. 🚫 The conditions check that app_domain == "IPsec policy", that esp_present == "yes", and that esp_enc_alg != "null", and then arrow "true". Slay.

Example three: delegating like a boss 👑

Authorizer: "POLICY"
Licensees: "subpolicy1" || "subpolicy2"
Comment: Delegate to two other sub-policies, so we
         can manage our policy better. Since these subpolicies
         are not "owned" by a key (and are thus unsigned), they
         have to be in isakmpd.policy.
Conditions: app_domain == "IPsec policy";

This one delegates to two other sub-policies — "subpolicy1" OR "subpolicy2" — so you can manage your policy better. And here's the important bit, don't skip it: since these subpolicies are not "owned" by a key (and are thus unsigned), they have to be in isakmpd.policy. No cap. 🫶

Example four: subpolicy1 doing its thing 🌸

KeyNote-Version: 2
Licensees: "passphrase-md5-hex:9c42a1346e333a770904b2a2b37fa7d3"
Conditions: esp_present == "yes" -> "true";
Authorizer: "subpolicy1"

Note the KeyNote-Version: 2 up top — and yes, it's capitalized like that here. "subpolicy1" only accepts when esp_present == "yes", then "true". Simple, clean, iconic. ✨

Example five: subpolicy2, the picky one 🦋

Conditions: ah_present == "yes" ->
               {
                   ah_auth_alg == "md5" -> "true";
                   ah_auth_alg == "sha" &&
                   esp_present == "no" -> "true";
               };
Licensees: "passphrase:otherpassword" ||
   "passphrase-sha1-hex:f5ed6e4abd30c36a89409b5da7ecb542c9fbf00f"
Authorizer: "subpolicy2"

Bestie look at this nested block, it's giving main character energy. 🌈 "subpolicy2" fires up when ah_present == "yes", and then inside the braces: if ah_auth_alg == "md5" → "true", OR if ah_auth_alg == "sha" and esp_present == "no" → "true". Two licensees here, joined with ||: "passphrase:otherpassword" and "passphrase-sha1-hex:f5ed6e4abd30c36a89409b5da7ecb542c9fbf00f". Two keys, one subpolicy, we love to see it. 💜

Example six: delegating to a CN 🧚

keynote-version: 2
comment: this is an example of a policy delegating to a CN.
authorizer: "POLICY"
licensees: "DN:/CN=CA Certificate/emailAddress=ca@foo.bar.com"

(And yeah, lowercase keynote-version / comment / authorizer / licensees here — the field names are flexible like that, iykyk.) This is an example of a policy delegating to a CN, with the DN spelled out as "DN:/CN=CA Certificate/emailAddress=ca@foo.bar.com". 💖

Example seven: delegating to a key 🔑

keynote-version: 2
comment: This is an example of a policy delegating to a key.
authorizer: "POLICY"
licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\
            FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\
            NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\
            m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5\
            MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\
            GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\
            dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\
            QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/\
            3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds\
            PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k\
            MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\
            DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH\
            jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP\
            ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH\
            d1Pn17LbJC1ZVRNjR5"
conditions: app_domain == "IPsec policy" && doi == "ipsec" &&
        pfs == "yes" && esp_present == "yes" && ah_present == "no" &&
        (esp_enc_alg == "3des" || esp_enc_alg == "aes") -> "true";

This is an example of a policy delegating to a key — a whole big base64 X.509 cert as the licensees value (yes those trailing backslashes are line continuations, keep them exactly as-is, they're load-bearing 🙈). The conditions check: app_domain == "IPsec policy" && doi == "ipsec" && pfs == "yes" && esp_present == "yes" && ah_present == "no" && (esp_enc_alg == "3des" || esp_enc_alg == "aes") → "true". PFS on, ESP on, AH off, and only 3des or aes for the encryption. Periodt. 👑

Example eight: a credential with a signature 💀

keynote-version: 2
comment: This is an example of a credential, the signature does
         not really verify (although the keys are real).
licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\
            FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\
            NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\
            m91cC5jby51azAeFw05OTEwMTEyMzA2MjJaFw05OTExMTAyMzA2\
            MjJaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\
            GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\
            dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\
            QDaCs+JAB6YRKAVkoi1NkOpE1V3syApjBj0Ahjq5HqYAACo1JhM\
            +QsPwuSWCNhBT51HX6G6UzfY3mOUz/vou6MJ/wor8EdeTX4nucx\
            NSz/r6XI262aXezAp+GdBviuJZx3Q67ON/IWYrB4QtvihI4bMn5\
            E55nF6TKtUMJTdATvs/wIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\
            MaQOSkaiR8id0h6Zo0VSB4HpBnjpWqz1jNG8N4RPN0W8muRA2b9\
            85GNP1bkC3fK1ZPpFTB0A76lLn11CfhAf/gV1iz3ELlUHo5J8nx\
            Pu6XfsGJm3HsXJOuvOog8Aean4ODo4KInuAsnbLzpGl0d+Jqa5u\
            TZUxsyg4QOBwYEU92H"
authorizer: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\
             FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\
             NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\
             m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5\
             MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\
             GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\
             dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\
             QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/\
             3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds\
             PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k\
             MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\
             DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH\
             jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP\
             ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH\
             d1Pn17LbJC1ZVRNjR5"
       conditions: app_domain == "IPsec policy" && doi == "ipsec" &&
                   pfs == "yes" && esp_present == "yes" && ah_present == "no" &&
                   (esp_enc_alg == "3des" || esp_enc_alg == "aes") -> "true";
       Signature: "sig-x509-sha1-base64:ql+vrUxv14DcBOQHR2jsbXayq6T\
                   mmtMiUB745a8rjwSrQwh+KIVDlUrghPnqhSIkWSDi9oWWMbfg\
                   mkdudZ0wjgeTLMI2NI4GibMMsToakOKMex/0q4cpdpln3DKcQ\
                   IcjzRv4khDws69FT3QfELjcpShvbLrXmh1Z00OFmxjyqDw="

Okay so read the comment first, it matters: this is an example of a credential, and the signature does not really verify — although the keys are real. So don't sit there debugging why the signature check fails, it's supposed to, it's a demo. 😭 The conditions are the exact same as the previous example, and the Signature value is the "sig-x509-sha1-base64:..." blob with those continuation backslashes. 💅

👀 SEE ALSO

Go read the friends. They're all part of the same friend group. 🫶

🐛 BUGS

A more sane way of expressing IPv6 address ranges is needed. That's the whole bug report. It's a real one. If you've ever tried to write IPv6 ranges in here you know. 🫠

And that's the whole page, bestie!! 🎀 You made it all the way through. This one's from the Debian crew, dated June 15, 2002 — yes, 2002, it's vintage, it's an heirloom, and it's still ISAKMPD.POLICY(5). Go configure something iconic with it. 💖✨🦋

📦 where this page comes from