[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