[strongSwan] Help with connecting to a cisco VPN system.
Noel Kuntze
noel.kuntze at thermi.consulting
Wed Jul 17 22:11:43 CEST 2019
Hello Ben,
Start off with the configs from the UsableExamples[1] page from the wiki.
> 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/20190717/697b366f/attachment-0001.sig>
More information about the Users
mailing list