[Swan] ASA 5550 Connection Help

Paul Connolly paulconnolly75 at gmail.com
Mon Apr 30 13:11:40 UTC 2018


I did see that and did add the IP as a loopback but still no go.  I'm
hoping the ASA provider has some logging on their end that can shed some
light on why it isn't working.  At this point I think I've read about every
document on the web about libreswan in ec2 connecting to an ASA.

On Mon, Apr 30, 2018 at 4:55 AM, Nick Howitt <nick at howitts.co.uk> wrote:

> Have you seen the AWS set up section on the wiki at
> https://libreswan.org/wiki/Interoperability#The_elastic_IP_
> and_the_RFC1918_native_IP_address, noting the configuration of the
> loopback interface?
>
> Nick
>
> On 29/04/2018 23:19, Paul Connolly wrote:
>
>> thanks so much for the response.  Below is the left side config.  The ASA
>> provider would only allow public IP networks so we provided them with the
>> elastic IP of the libreswan box as our endpoint and <elasticIP>/32 for our
>> vpn subnet.  This limits us to only being able to use the vpn server for
>> traffic across the tunnel, but for now that's fine.  I was concerned that I
>> wasn't presenting the IP or the network properly to the ASA, so I did the
>> test setup pointing to another libreswan instance and using the values
>> below for the right side of the connection successfully established the
>> tunnel and two way traffic.  I took this to mean that I was presenting the
>> public IP and subnet properly.
>>   left=%defaultroute
>>   leftid=<elasticIP>
>>   leftsourceip=<elasticIP>
>>   leftnexthop=%defaultroute
>>   leftsubnet=<elasticIP>/32
>>
>> I'm aware bad security of the ASA side settings and was concerned that
>> they weren't supported on the Libreswan side. The ASA provider is unwilling
>> to make ANY changes on their setup; they are an older large company that
>> does VPN connections to many vendors and they only configuration values
>> they will accept from us are our VPN IP and VPN networks(and only public
>> ones at that).  It's doubtful that I'll even be able to get any logging
>> from the ASA side to see why the connection is failing.  On my side, pluto
>> logs aren't super helpful:
>>
>> Apr 29 22:15:34: "ipsec" #257: starting keying attempt 258 of an
>> unlimited number
>> Apr 29 22:15:34: "ipsec" #258: initiating Main Mode to replace #257
>> Apr 29 22:15:34: deleting other state #257 (STATE_MAIN_I3) "ford"
>> Apr 29 22:15:34: "ipsec" #258: transition from state STATE_MAIN_I1 to
>> state STATE_MAIN_I2
>> Apr 29 22:15:34: "ipsec" #258: STATE_MAIN_I2: sent MI2, expecting MR2
>> Apr 29 22:15:35: "ipsec" #258: ignoring unknown Vendor ID payload
>> [1516b07506feabaa5e8ed209f3332f89]
>> Apr 29 22:15:35: "ipsec" #258: sending INITIAL_CONTACT
>> Apr 29 22:15:35: "ipsec" #258: transition from state STATE_MAIN_I2 to
>> state STATE_MAIN_I3
>> Apr 29 22:15:35: "ipsec" #258: STATE_MAIN_I3: sent MI3, expecting MR3
>> Apr 29 22:15:35: "ipsec" #258: received 1 malformed payload notifies
>> Apr 29 22:15:35: "ipsec" #258: discarding duplicate packet; already
>> STATE_MAIN_I3
>> Apr 29 22:15:36: "ipsec" #258: discarding duplicate packet; already
>> STATE_MAIN_I3
>> Apr 29 22:15:37: "ipsec" #258: discarding duplicate packet; already
>> STATE_MAIN_I3
>> Apr 29 22:15:39: "ipsec" #258: next payload type of ISAKMP Hash Payload
>> has an unknown value: 255 (0xff)
>> Apr 29 22:15:39: "ipsec" #258: malformed payload in packet
>> Apr 29 22:16:39: "ipsec" #258: max number of retransmissions (8) reached
>> STATE_MAIN_I3.  Possible authentication failure: no acceptable response to
>> our first encrypted message
>>
>> On Sun, Apr 29, 2018 at 4:30 PM, Paul Wouters <paul at nohats.ca <mailto:
>> paul at nohats.ca>> wrote:
>>
>>     On Sun, 29 Apr 2018, Paul Connolly wrote:
>>
>>         I have to create an IPSec tunnel from amazon to an ASA 5500.
>>         Below is the info I was provided on the ASA config:
>>
>>         Support Key Exchanged for Subnets: ON
>>         IKE Encryption Method: AES256 SHA IKE Diffie-Hellman Groups
>>         for Phase 1: Group 2 (1024 bit) IKE (Phase-1) Timeout: 1440
>>         Min IPSEC Encryption Method: AES256 SHA IPSEC (Phase-2)
>>         Timeout: 3600 Sec PFS (Perfect Forward Secrecy): Disabled
>>         Keepalive: Disabled
>>
>>         I setup libreswan on a centos 7 ec2 instance. This is what I
>>         have for Libreswan connection config:
>>
>>         conn ipsec
>>           type=tunnel
>>           authby=secret
>>           remote_peer_type=cisco
>>
>>
>>     Remove the remote_peer_type=cisco line, that is only needed when using
>>     IKEv1 XAUTH as a client towards a Cisco server for Remote Access VPN.
>>
>>           initial-contact=yes
>>           rekey=yes
>>           pfs=no
>>           ikelifetime=1440m
>>           salifetime=60m
>>           ike=aes256-sha1;dh2
>>           phase2alg=aes256-sha1;modp1024
>>           aggrmode=no
>>
>>         I've successfully created a tunnel to another libreswan
>>         instance in a separate aws vpn and can pass traffic but when I
>>         point to the ASA, I don't seem to be even getting
>>         past the IKE phase. based on this ipsec status:
>>
>>
>>         000 #1: "ipsec":4500 STATE_MAIN_I3 (sent MI3, expecting MR3);
>>         EVENT_v1_RETRANSMIT in 12s; nodpd; idle; import:admin initiate
>>         1: pending Phase 2 for "ipsec" replacing #0
>>
>>         I know the preshared key is correct but I'm at a loss. For
>>         starters, do I at least have the correct libreswan config
>>         based the ASA config?
>>
>>
>>     The config looks fine except for you not specifying and IDs for either
>>     end. Since you are in AWS, that means you are likely presenting your
>>     pre-NAT IP as your ID which is most likely rejected by the Cisco.
>>
>>     You should ask them what ID they are using on their end and what ID
>>     they expect you to have on your end.
>>
>>     Also, you should REALLY ask them to change dh2/modp1024 to at least
>>     dh5/modp1536 because dh2/modp1024 has been declared obsolete by
>>     RFC-8247
>>     and support will soon be removed from libreswan. This DH group is
>>     simply too weak for today's computing powers.
>>
>>     Paul
>>
>>
>>
>>
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>>
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180430/7cd182f4/attachment.html>


More information about the Swan mailing list