[strongSwan] Not Able to Connect

Info infosec at quantum-equities.com
Wed Mar 28 01:00:43 CEST 2018


So using "Usable Examples", exactly as prescribed:

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

        ikev2-pubkey {
                version = 2
                proposals =
aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
                rekey_time = 0s
                pools = primary-pool-ipv4, primary-pool-ipv6
                fragmentation = yes
                dpd_delay = 30s
                # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
                local-1 {
                        certs = cygnus-Cert.pem
                        id = cygnus.darkmatter.org
                }
                remote-1 {
                        # defaults are fine.
                }
                children {
                        ikev2-pubkey {
                        local_ts = 0.0.0.0/0,::/0
                        rekey_time = 0s
                        dpd_action = clear
                        esp_proposals =
aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
                        }
                }
        }
}

# systemctl restart strongswan-swanctl

{Fail}

# journalctl

loading connection 'ikev2-pubkey' failed: invalid value for: proposals,
config discarded

# cat /var/log/charon.log

Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
encryption algorithms can't be contained in the same IKE proposal

So the docs are wrong.

>From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

connections.<conn>.proposals


	default
A proposal is a set of algorithms. For non-AEAD algorithms, this
includes for IKE an encryption algorithm, an integrity algorithm, a
pseudo random function and a Diffie-Hellman group. For AEAD algorithms,
instead of encryption and integrity algorithms, a combined algorithm is
used.
In IKEv2, multiple algorithms of the same kind can be specified in a
single proposal, from which one gets selected. In IKEv1, only one
algorithm per kind is allowed per proposal, more algorithms get
implicitly stripped. Use multiple proposals to offer different
algorithms combinations in IKEv1.
Algorithm keywords get separated using dashes. Multiple proposals may be
separated by commas. The special value /default/ forms a default
proposal of supported algorithms considered safe, and is usually a good
choice for interoperability.


Ok I do not see what the goddamn problem is with this prescribed config,
but let's comment out proposals.

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

        ikev2-pubkey {
                version = 2
        #       proposals =
aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
                rekey_time = 0s
                pools = primary-pool-ipv4, primary-pool-ipv6
                fragmentation = yes
                dpd_delay = 30s
                # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
                local-1 {
                        certs = zeta-Cert.pem
                        id = zeta.darkmtter.org
                }
                remote-1 {
                        # defaults are fine.
                }
                children {
                        ikev2-pubkey {
                        local_ts = 0.0.0.0/0,::/0
                        rekey_time = 0s
                        dpd_action = clear
                        esp_proposals =
aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
                        }
                }
        }
}

# systemctl restart strongswan-swanctl

{Fail}

# journalctl

Mar 27 15:20:30 zeta.darkmtter.org swanctl[64348]: loading connection
'ikev2-pubkey' failed: invalid value for: esp_proposals, config discarded

# cat /var/log/charon.log

Tue, 2018-03-27 15:20 16[CFG] classic and combined-mode (AEAD)
encryption algorithms can't be contained in the same ESP proposal

Well this is bad.

>From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

connections.<conn>.children.<child>.ah_proposals

	
AH proposals to offer for the CHILD_SA. A proposal is a set of
algorithms. For AH, this includes an integrity algorithm and an optional
Diffie-Hellman group. If a DH group is specified, CHILD_SA/Quick Mode
rekeying and initial negotiation uses a separate Diffie-Hellman exchange
using the specified group (refer to /esp_proposals/ for details).
In IKEv2, multiple algorithms of the same kind can be specified in a
single proposal, from which one gets selected. In IKEv1, only one
algorithm per kind is allowed per proposal, more algorithms get
implicitly stripped. Use multiple proposals to offer different
algorithms combinations in IKEv1.
Algorithm keywords get separated using dashes. Multiple proposals may be
separated by commas. The special value /default/ forms a default
proposal of supported algorithms considered safe, and is usually a good
choice for interoperability. By default no AH proposals are included,
instead ESP is proposed.


Why doesn't this work either?  Whatever, comment it out.

The daemon now starts.  But looking at the initiator recommendation from
here:  https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
... they do not have an ikev2-pubkey, which would correspond with the
responder recommended configuration, for my remote mailserver.  But
synthesizing from the next closest thing:

connections {
    ikev2-pubkey {

        version = 2
        remote_addrs = quantum-equities.com
        vips = 0.0.0.0, ::
        local-1 {
 		certs = hydrus-Cert.pem
                id = mail.quantum-equities.com
        }
        remote-1 {
            # The following settings depend on if you've got the CA that issued the
            # responder's certificate or just the certificate.
            # if you've got the CA certificate, put it into /etc/swanctl.d/cacerts/. Also
            # read the notes in the beginning of the page about certificates.
            rightca="aries.darkmatter.org" 
            # if you've only got the responder's certificate
            #  certs = thisisthepathtothecertificate
            # if the remote peer sends a wrong ID, set that wrong ID here or make them fix it.
            # id = remoteIDGoesHere
        }
        children {
            remote_ts = 0.0.0.0/0,::/0
        }
    }

}


Restarting the daemon on the initiator shows no indication in the
responder that any attempt has been made to connect from anyone.

Tue, 2018-03-27 15:26 11[CFG] vici client 1 requests: load-key
Tue, 2018-03-27 15:26 11[CFG] loaded ANY private key
Tue, 2018-03-27 15:26 15[CFG] vici client 1 requests: get-authorities
Tue, 2018-03-27 15:26 07[CFG] vici client 1 requests: get-pools
Tue, 2018-03-27 15:26 12[CFG] vici client 1 requests: get-conns
Tue, 2018-03-27 15:26 15[CFG] vici client 1 requests: load-conn
Tue, 2018-03-27 15:26 15[CFG]  conn ikev2-pubkey:
Tue, 2018-03-27 15:26 15[CFG]   child ikev2-pubkey:
Tue, 2018-03-27 15:26 15[CFG]    rekey_time = 0
Tue, 2018-03-27 15:26 15[CFG]    life_time = 0
Tue, 2018-03-27 15:26 15[CFG]    rand_time = 0
Tue, 2018-03-27 15:26 15[CFG]    rekey_bytes = 0
Tue, 2018-03-27 15:26 15[CFG]    life_bytes = 0
Tue, 2018-03-27 15:26 15[CFG]    rand_bytes = 0
Tue, 2018-03-27 15:26 15[CFG]    rekey_packets = 0
Tue, 2018-03-27 15:26 15[CFG]    life_packets = 0
Tue, 2018-03-27 15:26 15[CFG]    rand_packets = 0
Tue, 2018-03-27 15:26 15[CFG]    updown = (null)
Tue, 2018-03-27 15:26 15[CFG]    hostaccess = 0
Tue, 2018-03-27 15:26 15[CFG]    ipcomp = 0
Tue, 2018-03-27 15:26 15[CFG]    mode = TUNNEL
Tue, 2018-03-27 15:26 15[CFG]    policies = 1
Tue, 2018-03-27 15:26 15[CFG]    policies_fwd_out = 0
Tue, 2018-03-27 15:26 15[CFG]    dpd_action = clear
Tue, 2018-03-27 15:26 15[CFG]    start_action = clear
Tue, 2018-03-27 15:26 15[CFG]    close_action = clear
Tue, 2018-03-27 15:26 15[CFG]    reqid = 0
Tue, 2018-03-27 15:26 15[CFG]    tfc = 0
Tue, 2018-03-27 15:26 15[CFG]    priority = 0
Tue, 2018-03-27 15:26 15[CFG]    interface = (null)
Tue, 2018-03-27 15:26 15[CFG]    mark_in = 0/0
Tue, 2018-03-27 15:26 15[CFG]    mark_out = 0/0
Tue, 2018-03-27 15:26 15[CFG]    inactivity = 0
Tue, 2018-03-27 15:26 15[CFG]    proposals =
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
Tue, 2018-03-27 15:26 15[CFG]    local_ts = 0.0.0.0/0 ::/0
Tue, 2018-03-27 15:26 15[CFG]    remote_ts = dynamic
Tue, 2018-03-27 15:26 15[CFG]    hw_offload = 0
Tue, 2018-03-27 15:26 15[CFG]    sha256_96 = 0
Tue, 2018-03-27 15:26 15[CFG]   version = 2
Tue, 2018-03-27 15:26 15[CFG]   local_addrs = %any
Tue, 2018-03-27 15:26 15[CFG]   remote_addrs = %any
Tue, 2018-03-27 15:26 15[CFG]   local_port = 500
Tue, 2018-03-27 15:26 15[CFG]   remote_port = 500
Tue, 2018-03-27 15:26 15[CFG]   send_certreq = 1
Tue, 2018-03-27 15:26 15[CFG]   send_cert = CERT_SEND_IF_ASKED
Tue, 2018-03-27 15:26 15[CFG]   mobike = 1
Tue, 2018-03-27 15:26 15[CFG]   aggressive = 0
Tue, 2018-03-27 15:26 15[CFG]   dscp = 0x00
Tue, 2018-03-27 15:26 15[CFG]   encap = 0
Tue, 2018-03-27 15:26 15[CFG]   dpd_delay = 30
Tue, 2018-03-27 15:26 15[CFG]   dpd_timeout = 0
Tue, 2018-03-27 15:26 15[CFG]   fragmentation = 2
Tue, 2018-03-27 15:26 15[CFG]   unique = UNIQUE_NO
Tue, 2018-03-27 15:26 15[CFG]   keyingtries = 1
Tue, 2018-03-27 15:26 15[CFG]   reauth_time = 0
Tue, 2018-03-27 15:26 15[CFG]   rekey_time = 0
Tue, 2018-03-27 15:26 15[CFG]   over_time = 0
Tue, 2018-03-27 15:26 15[CFG]   rand_time = 0
Tue, 2018-03-27 15:26 15[CFG]   proposals =
IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024,
IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/CAMELLIA_CCM_16_128/CAMELLIA_CCM_16_192/CAMELLIA_CCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/CAMELLIA_CCM_8_128/CAMELLIA_CCM_8_192/CAMELLIA_CCM_8_256/CAMELLIA_CCM_12_128/CAMELLIA_CCM_12_192/CAMELLIA_CCM_12_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024
Tue, 2018-03-27 15:26 15[CFG]   local:
Tue, 2018-03-27 15:26 15[CFG]    id = cygnus.darkmatter.org
Tue, 2018-03-27 15:26 15[CFG]   remote:
Tue, 2018-03-27 15:26 15[CFG] added vici connection: ikev2-pubkey
Tue, 2018-03-27 15:26 07[CFG] vici client 1 disconnected


So long story short, the reason that no one can get swanctl actually
working is that the docs are chaotic and busted.  I say again:  the docs
and examples do not work for swanctl.  Docs are supposed to make it
possible to get something to function, without the destructive
condescension of frustrated fuctionaries with low self-esteem.  But
apparently some like it this way.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180327/2798a036/attachment-0001.html>


More information about the Users mailing list