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 <[email protected]> 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 <[email protected]> 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 <[email protected] <mailto: >>> [email protected]>> 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 >>> [email protected] >>> https://lists.libreswan.org/mailman/listinfo/swan >>> >> >> _______________________________________________ >> Swan mailing list >> [email protected] >> https://lists.libreswan.org/mailman/listinfo/swan >> > >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
