[strongSwan] Help with connecting to a cisco VPN system.
Noel Kuntze
noel.kuntze at thermi.consulting
Thu Jul 18 15:02:23 CEST 2019
Hello Ben,
>
> 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.
Well, considering the secrets, authorities and conns, yes.
strongswan.conf settings are still applied in any case. They're for demon wide configuration.
> 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.
Yes, seems like it.
Kind regards
Noel
Am 18.07.19 um 15:00 schrieb Ben Greear:
> 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
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Noel Kuntze
IT security consultant
GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190718/919e9feb/attachment-0001.sig>
More information about the Users
mailing list