[Swan] ASA 5550 Connection Help

Paul Connolly paulconnolly75 at gmail.com
Mon Apr 30 19:01:12 UTC 2018


After all this drama, issue turns out to be a preshared key mismatch.
Boom, tunnel now comes up.  I am not able to ping servers at the other end
of the tunnel, but I'm assuming I missing route or security rule on the
amazon end.  Thanks so much for the help guys!

On Mon, Apr 30, 2018 at 8:11 AM, Paul Connolly <paulconnolly75 at gmail.com>
wrote:

> 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_a
>> nd_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/ded22295/attachment-0001.html>


More information about the Swan mailing list