[strongSwan] Not Able to Connect

Andreas Steffen andreas.steffen at strongswan.org
Wed Mar 28 11:21:23 CEST 2018


Hi,

as your log explicitly says:

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

Thus instead of

esp_proposals =
> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default

you must define

esp_proposals =
  aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default

Regards

Andreas

On 28.03.2018 01:00, Info wrote:
> 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.
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==


More information about the Users mailing list