<div dir="ltr">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!</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 8:11 AM, Paul Connolly <span dir="ltr"><<a href="mailto:paulconnolly75@gmail.com" target="_blank">paulconnolly75@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 4:55 AM, Nick Howitt <span dir="ltr"><<a href="mailto:nick@howitts.co.uk" target="_blank">nick@howitts.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you seen the AWS set up section on the wiki at <a href="https://libreswan.org/wiki/Interoperability#The_elastic_IP_and_the_RFC1918_native_IP_address" rel="noreferrer" target="_blank">https://libreswan.org/wiki/Int<wbr>eroperability#The_elastic_IP_a<wbr>nd_the_RFC1918_native_IP_addre<wbr>ss</a>, noting the configuration of the loopback interface?<br>
<br>
Nick<span><br>
<br>
On 29/04/2018 23:19, Paul Connolly wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
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.<br>
left=%defaultroute<br>
leftid=<elasticIP><br>
leftsourceip=<elasticIP><br>
leftnexthop=%defaultroute<br>
leftsubnet=<elasticIP>/32<br>
<br>
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:<br>
<br>
Apr 29 22:15:34: "ipsec" #257: starting keying attempt 258 of an unlimited number<br>
Apr 29 22:15:34: "ipsec" #258: initiating Main Mode to replace #257<br>
Apr 29 22:15:34: deleting other state #257 (STATE_MAIN_I3) "ford"<br>
Apr 29 22:15:34: "ipsec" #258: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2<br>
Apr 29 22:15:34: "ipsec" #258: STATE_MAIN_I2: sent MI2, expecting MR2<br>
Apr 29 22:15:35: "ipsec" #258: ignoring unknown Vendor ID payload [1516b07506feabaa5e8ed209f3332<wbr>f89]<br>
Apr 29 22:15:35: "ipsec" #258: sending INITIAL_CONTACT<br>
Apr 29 22:15:35: "ipsec" #258: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3<br>
Apr 29 22:15:35: "ipsec" #258: STATE_MAIN_I3: sent MI3, expecting MR3<br>
Apr 29 22:15:35: "ipsec" #258: received 1 malformed payload notifies<br>
Apr 29 22:15:35: "ipsec" #258: discarding duplicate packet; already STATE_MAIN_I3<br>
Apr 29 22:15:36: "ipsec" #258: discarding duplicate packet; already STATE_MAIN_I3<br>
Apr 29 22:15:37: "ipsec" #258: discarding duplicate packet; already STATE_MAIN_I3<br>
Apr 29 22:15:39: "ipsec" #258: next payload type of ISAKMP Hash Payload has an unknown value: 255 (0xff)<br>
Apr 29 22:15:39: "ipsec" #258: malformed payload in packet<br>
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<br>
<br></span><div><div class="m_-4868277400976010187h5">
On Sun, Apr 29, 2018 at 4:30 PM, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a> <mailto:<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>>> wrote:<br>
<br>
On Sun, 29 Apr 2018, Paul Connolly wrote:<br>
<br>
I have to create an IPSec tunnel from amazon to an ASA 5500.<br>
Below is the info I was provided on the ASA config:<br>
<br>
Support Key Exchanged for Subnets: ON<br>
IKE Encryption Method: AES256 SHA IKE Diffie-Hellman Groups<br>
for Phase 1: Group 2 (1024 bit) IKE (Phase-1) Timeout: 1440<br>
Min IPSEC Encryption Method: AES256 SHA IPSEC (Phase-2)<br>
Timeout: 3600 Sec PFS (Perfect Forward Secrecy): Disabled<br>
Keepalive: Disabled<br>
<br>
I setup libreswan on a centos 7 ec2 instance. This is what I<br>
have for Libreswan connection config:<br>
<br>
conn ipsec<br>
type=tunnel<br>
authby=secret<br>
remote_peer_type=cisco<br>
<br>
<br>
Remove the remote_peer_type=cisco line, that is only needed when using<br>
IKEv1 XAUTH as a client towards a Cisco server for Remote Access VPN.<br>
<br>
initial-contact=yes<br>
rekey=yes<br>
pfs=no<br>
ikelifetime=1440m<br>
salifetime=60m<br>
ike=aes256-sha1;dh2<br>
phase2alg=aes256-sha1;modp1024<br>
aggrmode=no<br>
<br>
I've successfully created a tunnel to another libreswan<br>
instance in a separate aws vpn and can pass traffic but when I<br>
point to the ASA, I don't seem to be even getting<br>
past the IKE phase. based on this ipsec status:<br>
<br>
<br>
000 #1: "ipsec":4500 STATE_MAIN_I3 (sent MI3, expecting MR3);<br>
EVENT_v1_RETRANSMIT in 12s; nodpd; idle; import:admin initiate<br>
1: pending Phase 2 for "ipsec" replacing #0<br>
<br>
I know the preshared key is correct but I'm at a loss. For<br>
starters, do I at least have the correct libreswan config<br>
based the ASA config?<br>
<br>
<br>
The config looks fine except for you not specifying and IDs for either<br>
end. Since you are in AWS, that means you are likely presenting your<br>
pre-NAT IP as your ID which is most likely rejected by the Cisco.<br>
<br>
You should ask them what ID they are using on their end and what ID<br>
they expect you to have on your end.<br>
<br>
Also, you should REALLY ask them to change dh2/modp1024 to at least<br>
dh5/modp1536 because dh2/modp1024 has been declared obsolete by<br>
RFC-8247<br>
and support will soon be removed from libreswan. This DH group is<br>
simply too weak for today's computing powers.<br>
<br>
Paul<br>
<br>
<br>
<br>
<br></div></div>
______________________________<wbr>_________________<br>
Swan mailing list<br>
<a href="mailto:Swan@lists.libreswan.org" target="_blank">Swan@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan" rel="noreferrer" target="_blank">https://lists.libreswan.org/ma<wbr>ilman/listinfo/swan</a><br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Swan mailing list<br>
<a href="mailto:Swan@lists.libreswan.org" target="_blank">Swan@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan" rel="noreferrer" target="_blank">https://lists.libreswan.org/ma<wbr>ilman/listinfo/swan</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>