[Swan] Problem connecting to a Cisco ASA
Miguel Ponce Antolin
mponce at paradigmadigital.com
Wed Mar 10 14:55:23 UTC 2021
Hi,
Finally it is working with this config:
conn vpn
type=tunnel
authby=secret
auto=start
left=%defaultroute
leftid=xxx.xxx.xxx.120
leftsubnets=10.xxx.xxx.80/28
right=xxx.xxx.xxx.45
rightid=xxx.xxx.xxx.45
rightsubnets={10.xxx.xxx.0/22 ... 10.xxx.xxx.xxx/32}
leftsourceip=xxx.xxx.xxx.92
#leftnexthop=%defaultroute
ikev2=insist
ike=aes256-sha2;dh14 (It is not especified this way on the
documentation, a collegue has noticed me that this is a really problematic
point, I think it was failing to connect phase 1 because of this)
esp=aes256-sha256
keyexchange=ike
ikelifetime=28800s
salifetime=28800s
dpddelay=30
dpdtimeout=120
dpdaction=restart_by_peer
encapsulation=no (Needed to avoid connect using Nat-T, it is not
configured in any side but it keeps going through port 4500)
Also I have tcpdump and analized with wireshark the packets sent by both
peers and see that the AES_CBC is sent with key lenght 256 bits.
Payload: Transform (3) Next payload:
Transform (3) Reserved: 00 Payload length: 12 Transform Type: Encryption
Algorithm (ENCR) (1) Reserved: 00 Transform ID (ENCR): *ENCR_AES_CBC* (12)
Transform Attribute (t=14,l=2): Key Length: *256* 1... .... .... .... =
Format: Type/Value (TV) Type: Key Length (14) Value: 0100 Key Length: *256 *
Payload: Transform (3) Next payload:
Transform (3) Reserved: 00 Payload length: 8 Transform Type: Pseudo-random
Function (PRF) (2) Reserved: 00 Transform ID (PRF): PRF_HMAC_SHA2_256 (5)
Payload: Transform (3) Next payload:
Transform (3) Reserved: 00 Payload length: 8 Transform Type: Integrity
Algorithm (INTEG) (3) Reserved: 00 Transform ID (INTEG):
AUTH_HMAC_SHA2_256_128 (12)
Payload: Transform (3) Next payload: NONE / No Next Payload (0) Reserved:
00 Payload length: 8 Transform Type: Diffie-Hellman Group (D-H) (4)
Reserved: 00
Thanks for your help and being there as support.
Best regards!
El mié, 10 mar 2021 a las 12:30, Nick Howitt (<nick at howitts.co.uk>)
escribió:
>
>
> On 10/03/2021 11:17, Miguel Ponce Antolin wrote:
> > Thanks for your answer Paul,
> >
> > I have tried the options you said with similar results, the connection
> > is not stablished in any case.
> >
> > The other side configuration is mandatory, so the AES256 must be
> effective.
> >
> > We have seen that the aes256 configuration selects AES_CBC and the 256
> > bit option have to be selected.
> >
> > Does libreswan accepts this 256 bits option on AES_CBC?
> >
> > Looking on the libreswan wiki the Implemented Standards
> > <https://libreswan.org/wiki/Implemented_Standards> I can see that the
> > option is possible but I cannot assure that when cipherkey is selected
> > as AES_CBC the 256 bits are selected.
> >
> > The other peer is sure that the problem is about this and I don't know
> > if the 256 bits option is effective when the Payload is negotiated.
> >
> > Maybe you can bring me some clarity,
> >
> > Thanks in advance!
> >
> > El mié, 10 mar 2021 a las 4:16, Paul Wouters (<paul at nohats.ca
> > <mailto:paul at nohats.ca>>) escribió:
> >
> > On Mon, 8 Mar 2021, Miguel Ponce Antolin wrote:
> >
> > > I think we are facing issues with the IKE algorithms.
> > >
> > > The Cisco peer has the next configuration:
> > > - pfs group14
> > > - ikev2 ipsec-proposal AES256-SHA256
> > > - security-association lifetime seconds 28800
> > >
> > > So the libreswan side is configured in the ipsec.d/vpn.conf with
> > similar parameters using the yum repository last version 3.25:
> > >
> > > conn vpn
> > > type=tunnel
> > > authby=secret
> > > auto=start
> > > left=%defaultroute
> > > leftid=xxx.xxx.xxx.120
> > > leftsubnets=10.xxx.xxx.xxx/28
> > > right=xxx.xxx.xxx.45
> > > rightsubnets=xxx.xxx.xxx.17/32
> > > leftsourceip=xxx.xxx.xxx.92
> > > leftnexthop=%defaultroute
> > > ikev2=insist
> > > ike=aes256-sha2;dh14
> > > keyexchange=ike
> > > ikelifetime=28800s
> > > salifetime=28800s
> > > dpddelay=30
> > > dpdtimeout=120
> > > dpdaction=restart
> > > remote_peer_type=cisco
> > > aggrmode=yes
> > > initial-contact=yes
> > > encapsulation=no
> >
> > Delete the lines with remote_peer_type, aggrmode, and encapsulation
> >
> > Try using ike=aes256-sha2_256;dh14
> >
> > > Mar 8 12:33:25.540325: | selected state microcode Initiator:
> > process AUTHENTICATION_FAILED AUTH notification
> >
> > It could also be that they are expected a different leftid= then you
> > think?
> >
> > Despite them claiming pfs, you can try pfs=no as well to see if that
> > makes a difference.
> >
> > Paul
> >
> >
> >
> > --
> >
> > Logo Especialidad
> >
> > *Miguel Ponce Antolín.*
> > Sistemas · +34 670 360 655
> > Linea
> > Logo Paradigma · paradig.ma <https://www.paradigmadigital.com/> ·
> > contáctanos <https://www.paradigmadigital.com/contacto> · Twitter
> > <https://twitter.com/paradigmate> Youtube
> > <https://www.youtube.com/user/ParadigmaTe?feature=watch> Linkedin
> > <https://www.linkedin.com/company/paradigma-digital/> Instagram
> > <https://www.instagram.com/paradigma_digital/?hl=es>
> >
> >
> > _______________________________________________
> > Swan mailing list
> > Swan at lists.libreswan.org
> > https://lists.libreswan.org/mailman/listinfo/swan
> >
> Is "sha2-truncbug = yes" relevant?
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
--
[image: Logo Especialidad]
*Miguel Ponce Antolín.*
Sistemas · +34 670 360 655
[image: Linea]
[image: Logo Paradigma] · paradig.ma <https://www.paradigmadigital.com/>
· contáctanos <https://www.paradigmadigital.com/contacto> · [image:
Twitter] <https://twitter.com/paradigmate> [image: Youtube]
<https://www.youtube.com/user/ParadigmaTe?feature=watch> [image: Linkedin]
<https://www.linkedin.com/company/paradigma-digital/> [image: Instagram]
<https://www.instagram.com/paradigma_digital/?hl=es>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20210310/800a270c/attachment.html>
More information about the Swan
mailing list