[strongSwan] Help with connecting to a cisco VPN system.

Ben Greear greearb at candelatech.com
Thu Jul 18 15:00:48 CEST 2019


On 7/17/19 1:11 PM, Noel Kuntze wrote:
> Hello Ben,
> 
> Start off with the configs from the UsableExamples[1] page from the wiki.

Am I correct in believing that only the swanctl.conf config file matters
if I am using swanctl to control the system?  That was not clear at all the
first few times I tried to read those examples, if so.

 From more poking around, it seems that keys and certs and such need to go into
specific places, and I am still putting things in wrong places and/or creating
invalid swanctl.conf files.

If someone has time to help me translate the ipsec.conf example I posted
to swanctl API, please contact me off list.  I'll be happy to make it worth your
while.

Thanks,
Ben

> 
>> So, I'm afraid I need a bit of hand holding on this.  Can you suggest
>> the proper syntax and/or a link to something appropriate?
> 
> You only need to specify a section in "secrets" for an ECDSA or RSA key, if it's encrypted.
> Otherwise swanctl finds it by itself.
> 
> The following section would be correct if the key was an ECDSA key and in swanctl/ecdsa,
> and it was encrypted with the passphrase of an empty string (""):
> 
> secrets {
>      ecdsa-foo {
>          file = cert.key
>          secret = ""
>      }
> }
> 
>>
>> I thought that '@' might tell strongswan to go look in the secrets.conf file for an ike-* section
>> with matching ID?
> 
> No, a @ prefix is a hack for ipsec.conf to make the syntax parser identify the ID as of type FQDN.
> See the text for connections.<conn>.local<suffix>.id on the man page for swanctl.conf for the syntax
> you are supposed to use, if the heuristic doesn't take the right type first.
> 
> See the man page for details:
>>         secrets.ike<suffix>
>>                IKE preshared secret section for a specific secret. Each IKE PSK
>>                is defined in a unique section having the ike prefix.
>>
>>         secrets.ike<suffix>.secret []
>>                Value  of  the  IKE  preshared secret. It may either be an ASCII
>>                string, a hex encoded string if it has a 0x prefix or  a  Base64
>>                encoded string if it has a 0s prefix in its value.
>>
>>         secrets.ike<suffix>.id<suffix> []
>>                IKE  identity  the  IKE  preshared  secret  belongs to. Multiple
>>                unique identities may be specified, each having an id prefix, if
>>                a secret is shared between multiple peers.
> 
>> So, based on the example config (with different syntax) from my first email,
>> that supposedly works with the cisco, what *should* I use for the three id configs above?
>>
>> I this case, I used '4' because that is the routing table id, and that is what was passed as '-i' option
>> when creating the xfrm:  "$XFRMI -n $xfrm -i $table -d $wan"
> 
> XFRM interfaces have nothing to do with VRFs. XFRM interface are just dumb pipes that make the kernel process
> anything you put into it with the IPsec SAs and SPs that have the XFRM interface ID of the same value as the XFRM interface you are using.
> The reverse happens when you receive packets (if the IPsec SA has an XFRM interface ID set, the kernel looks for an XFRM interface with that ID
> and assigns the decapsulated packet to it, thus making it look like the packet was received on that XFRM interface).
> 
> XFRM interfaces have nothing to do with routing tables.
> 
>> I need to be able to autogenerate this based on a minimum of user input, and correlated
>> with vrfs, routing tables, and so forth.  I am following an example that worked with PSK
>> encryption, but that was my config on both sides, so I could easily be getting lucky
>> with some otherwise bad configuration.
> 
> Looks like you need a lot of hand holding to get that part of your project working correctly (and not have
> it be followed by an endless cycle of patching because of wrong assumptions).
> 
>> I think the pattern I am trying to use is to have all of the 'ike-foo' sections in one secrets.conf file,
>> and then have a per-wan-device config file in the peers-enabled directory.  I have already written code
>> to generate and manage these files, so as long as it is not a problem, I'll likely keep it that way.
> 
> Just don't bother. Generate connection specific configuration files that contain all details for that connection and store them in conf.d. Use UUIDs for any
> meta suffixes so they don't conflict between conns. Done. Then the stuff for a single conn is always in exactly one file and not spread over like 5 different ones.
> 
> Kind regards
> 
> Noel
> 
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
> 
> Am 17.07.19 um 21:53 schrieb Ben Greear:
>> On 7/17/19 12:27 PM, Noel Kuntze wrote:
>>> Hello Ben,
>>>
>>>>       local_addrs  = %any    # use any local IP to connect to remote
>>>
>>> That's superfluous.
>>>
>>>> ike-lanforge {
>>>>     id = "C=US, CN=192.168.5.1" # use remote id specified in tunnel config
>>>>     file = cert.key
>>>>     secret = ""
>>>> }
>>>
>>> That's a PSK. You probably want an ecdsa key though, probably?
>>
>> I've been using strongswan all of a few days now.  I do not understand
>> the syntax that well and find conflicting syntax when I try to search.
>>
>> So, I'm afraid I need a bit of hand holding on this.  Can you suggest
>> the proper syntax and/or a link to something appropriate?
>>
>>>
>>>>        id = @C=US, CN=192.168.5.1.loc # An key identifier per connection, remote ID
>>>
>>> That's wrong. That specifies an ID of literally "@C=[...]". You probably want an FQDN though, probably or an KEYID type ID?
>>> That depends entirely on what the other peer sends.
>>
>> I thought that '@' might tell strongswan to go look in the secrets.conf file for an ike-* section
>> with matching ID?
>>
>>>
>>>
>>>>           if_id_out = 4    # The xfrm interface ID, use VRF ID
>>>>           if_id_in = 4    # The xfrm interface ID, use VRF ID
>>>
>>> No, that won't work with VRF devices, if they are local. They are not related to the remote peer's configuration.
>>
>> So, based on the example config (with different syntax) from my first email,
>> that supposedly works with the cisco, what *should* I use for the three id configs above?
>>
>> I this case, I used '4' because that is the routing table id, and that is what was passed as '-i' option
>> when creating the xfrm:  "$XFRMI -n $xfrm -i $table -d $wan"
>>
>>>> # cat local/etc/swanctl/peers-enabled/
>>>
>>> You probably just want to store your stuff on swanctl/conf.d.
>>>
>>> You are allowed to have several connections {} or secrets {} or authority {}, ..., sections spread over several files (I don't know if it works in a single file).
>>>
>>> Just include swanctl/conf.d/*.conf from swanctl.conf and organize your configuration that way.
>>>
>>> Right now, you are needlessly reinventing the wheel.
>>
>> I need to be able to autogenerate this based on a minimum of user input, and correlated
>> with vrfs, routing tables, and so forth.  I am following an example that worked with PSK
>> encryption, but that was my config on both sides, so I could easily be getting lucky
>> with some otherwise bad configuration.
>>
>> I think the pattern I am trying to use is to have all of the 'ike-foo' sections in one secrets.conf file,
>> and then have a per-wan-device config file in the peers-enabled directory.  I have already written code
>> to generate and manage these files, so as long as it is not a problem, I'll likely keep it that way.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> Am 17.07.19 um 18:55 schrieb Ben Greear:
>>>> Hello,
>>>>
>>>> First, thanks for all the help so far.  I think I am getting close!
>>>>
>>>> I am hoping that someone can help with my problem below...
>>>>
>>>>
>>>> Someone sent me instructions for how to connect to a cisco vpn concentrator
>>>> with this information:
>>>>
>>>> "
>>>> I added the following to the ipsec.conf:
>>>>
>>>> conn ciscoasa
>>>>       right=192.168.5.1
>>>>       rightid="C=US, CN=192.168.5.1"
>>>>       rightsubnet=0.0.0.0/0
>>>>       rightauth=pubkey
>>>>       leftsourceip=%config
>>>>       leftauth=pubkey
>>>>       leftcert=cert.der
>>>>       auto=add
>>>>       esp=aes256gcm16-ecp384
>>>>       ike=aes256gcm16-prfsha384-ecp384
>>>>       keyexchange=ikev2
>>>>
>>>>
>>>> And the following to the ipsec.secrets:
>>>>
>>>> : ECDSA cert.key
>>>>
>>>>
>>>> The CA certificate must be placed in the /etc/strongswan/ipsec.d/cacerts/ directory.
>>>>
>>>> The user certificate 'cert.der' (as listed above in the ipsec.conf) must be placed in the /etc/strongswan/ipsec.d/certs/ directory.
>>>>
>>>> The user certificate private key 'cert.key' (as listed in the ipsec.secrets) must be placed in the /etc/strongswan/ipsec.d/private/ directory. The cert.key has been unencrypted and thus a password is not needed in the ipsec.secrets file.
>>>> "
>>>>
>>>>
>>>> I have been trying to convert this to (what is I assume) the newer strongswan config file API:
>>>>
>>>> # cat /home/lanforge/local/etc/swanctl/secrets.conf
>>>> ike-lanforge {
>>>>     id = "C=US, CN=192.168.5.1" # use remote id specified in tunnel config
>>>>     file = cert.key
>>>>     secret = ""
>>>> }
>>>>
>>>> # cat local/etc/swanctl/peers-enabled/eth4.conf
>>>>
>>>> _vrf4 {
>>>>       local_addrs  = %any    # use any local IP to connect to remote
>>>>       remote_addrs = 192.168.5.1 # WAN Address of IPsec concentrator, may use DNS
>>>>       unique = replace
>>>>       local {
>>>>        auth = pubkey
>>>>        id = @lanforge.loc # An key identifier per connection, local ID
>>>>       }
>>>>       remote {
>>>>        auth = pubkey
>>>>        id = @C=US, CN=192.168.5.1.loc # An key identifier per connection, remote ID
>>>>       }
>>>>       children {
>>>>        _vrf4_sa {
>>>>           local_ts  = 0.0.0.0/0,::/0
>>>>           remote_ts = 0.0.0.0/0,::/0
>>>>           if_id_out = 4    # The xfrm interface ID, use VRF ID
>>>>           if_id_in = 4    # The xfrm interface ID, use VRF ID
>>>>
>>>>           start_action = trap
>>>>           life_time = 1h
>>>>           rekey_time = 55m
>>>>           esp_proposals = aes256gcm128-modp3072 # Optimized for throuput on Intel HW
>>>>           dpd_action = trap
>>>>        }
>>>>           }
>>>>       keyingtries = 0
>>>>       dpd_delay = 30
>>>>       version = 2
>>>>       mobike = yes
>>>>       rekey_time = 23h
>>>>       over_time = 1h
>>>>       proposals = aes256-sha256-modp3072,aes256gcm16-prfsha384-ecp384
>>>> }
>>>>
>>>> # cat /home/lanforge/local/etc/swanctl/swanctl.conf
>>>> connections {
>>>>           include /home/lanforge/local/etc/swanctl/peers-enabled/*.conf
>>>> }
>>>>
>>>> secrets {
>>>>           include /home/lanforge/local/etc/swanctl/secrets.conf
>>>> }
>>>>
>>>>
>>>> These files are copied into place in the ./local/ directory structure:
>>>>
>>>> local/etc/ipsec.d/certs/cert.der
>>>> local/etc/ipsec.d/private/cert.key
>>>> local/etc/ipsec.d/cacerts/red-ca.cer
>>>>
>>>> -rw-r--r-- 1 lanforge lanforge 776 Jul 17 09:08 local/etc/ipsec.d/cacerts/red-ca.cer
>>>> -rw-r--r-- 1 root root 513 Jul 17 09:28 local/etc/ipsec.d/private/cert.key
>>>> -rw-r--r-- 1 lanforge lanforge 1143 Jul 17 09:08 local/etc/ipsec.d/certs/cert.der
>>>>
>>>>
>>>> Here is some output from swanctl that makes me think it is at least somewhat working:
>>>>
>>>> # swanctl --list-conns
>>>> _vrf4: IKEv2, no reauthentication, rekeying every 82800s, dpd delay 30s
>>>>     local:  %any
>>>>     remote: 192.168.5.1
>>>>     local public key authentication:
>>>>       id: lanforge.loc
>>>>     remote public key authentication:
>>>>       id: @C=US, CN=192.168.5.1.loc
>>>>     _vrf4_sa: TUNNEL, rekeying every 3300s, dpd action is hold
>>>>       local:  0.0.0.0/0 ::/0
>>>>       remote: 0.0.0.0/0 ::/0
>>>>
>>>> But certainly not completely working:
>>>>
>>>> # swanctl --load-all
>>>> loading shared secret failed: shared key data missing
>>>> no authorities found, 0 unloaded
>>>> no pools found, 0 unloaded
>>>> loaded connection '_vrf4'
>>>> successfully loaded 1 connections, 0 unloaded
>>>>
>>>>
>>>> # swanctl --list-sas
>>>>
>>>>
>>>> journalctl shows this when I try to start traffic on the xfrm interface:
>>>>
>>>> Jul 17 09:35:59 lf0313-63e7 ipsec[19850]: 12[IKE] initiating IKE_SA _vrf4[7] to 192.168.5.1
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 14[KNL] interface x_eth4 deactivated
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 13[KNL] interface x_eth4 activated
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 02[KNL] fe80::e380:2a25:4bcc:6d45 appeared on x_eth4
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 12[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 12[NET] sending packet: from 192.168.5.4[500] to 192.168.5.1[500] (628 bytes)
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[NET] received packet: from 192.168.5.1[500] to 192.168.5.4[500] (38 bytes)
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[IKE] peer didn't accept DH group MODP_3072, it requested ECP_384
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[IKE] initiating IKE_SA _vrf4[7] to 192.168.5.1
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[IKE] initiating IKE_SA _vrf4[7] to 192.168.5.1
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 01[NET] sending packet: from 192.168.5.4[500] to 192.168.5.1[500] (340 bytes)
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[NET] received packet: from 192.168.5.1[500] to 192.168.5.4[500] (431 bytes)
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) V ]
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] received Cisco Delete Reason vendor ID
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] received Cisco Copyright (c) 2009 vendor ID
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] received FRAGMENTATION vendor ID
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_384/ECP_384
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] received cert request for "DC=local, DC=red, CN=RED-CA"
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] sending cert request for "DC=local, DC=red, CN=RED-CA"
>>>> Jul 17 09:35:59 lf0313-63e7 charon[19856]: 09[IKE] no private key found for 'lanforge.loc'
>>>>
>>>> Any clues are welcome, and I will be happy to run more diagnostics if someone has suggestions.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>
>>
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Users mailing list