<div dir="ltr"><div><div><div><div>Good morning,<br><br>If someone can please hit me really hard in the face with the clue-stick I would appreciate it.<br><br>Connecting an AWS EC2 instance running openswan to a Cisco ASA class machine via IPSec VPN fails.<br><br></div><div>With 2.6.37, I could create the tunnels, but network traffic wouldn't flow down them, and now I'm trying out 2.6.40.<br></div><div><br>Amazon Linux, 3.14.48-33.39.amzn1.x86_64 #1 SMP Tue Jul 14 23:43:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux<br>Amazon Linux AMI release 2015.03<br><br></div>I don't think this is related to the device being an EC2 instance in a VPC. I think it's related to my completely screwed up configuration files.<br><br></div>It's very similarly configured to my other Openswan IPSec connections that link various datacenters, those are fine, almost identically configured, but not pointing at Cisco devices.<br><br></div><div>LOCAL-IP-NETWORK/16<br>EC2 instance (LOCAL-IP)<br>(Elastic IP)<br>...<br>Internet <br>...<br>(PRIMARY-CON-IP)<br>Cisco router (presumably on an IP behind NAT?)<br>REMOTE-IP-NETWORK/17<br><br></div><div>I believe these two networks should be bridged? As opposed to NAT with IP Masquerade? We should see the IP of the devices on the far side, and they should see the IP of the devices behind me.<br></div><div><br></div><div>I used sed to replace the IPs and verify they're not different, mistyped etc, and used the same command line to watch the logs, so at least I know I didn't fat finger the IPs or networks.<br></div><div><br></div># /etc/ipsec.conf - Openswan IPsec configuration file<br>version 2.0 # conforms to second version of ipsec.conf specification<br>config setup<br> plutoopts="--perpeerlog"<br> dumpdir=/var/run/pluto/<br> nat_traversal=yes<br> virtual_private=%v4:<a href="http://192.168.0.0/24">192.168.0.0/24</a><br> oe=off<br> protostack=auto<br>include /etc/ipsec.d/*.conf<br><br></div><div>and /etc/ipsec.d/*.conf:<br></div><div><br>conn PRIMARY-CON<br> type=tunnel<br> authby=secret<br> left=LOCAL-IP<br> leftid=LOCAL-IP<br> leftnexthop=%defaultroute<br> leftsubnet=LOCAL-IP-NETWORK/16<br> right=PRIMARY-CON-IP<br> remote_peer_type=cisco<br> rightsubnets={REMOTE-IP-NETWORK-A/17,REMOTE-IP-NETWORK-B/17}<br> pfs=yes<br> auto=start<br>conn SECONDARY-CON<br> type=tunnel<br> authby=secret<br> left=%defaultroute<br> leftid=LOCAL-IP<br> leftnexthop=%defaultroute<br> leftsubnet=LOCAL-IP-NETWORK/16<br> right=SECONDARY-CON-IP<br> rightsubnets={REMOTE-IP-NETWORK-A/17,REMOTE-IP-NETWORK-B/17}<br> pfs=yes<br> auto=start<br><br></div><div>secets files:<br></div><div><div><div><div><div>LOCAL-IP PRIMARY-CON-IP: PSK "FooBarBaz"<br>LOCAL-IP SECONDARY-CON-IP: PSK "FooBarBaz"<br><br></div><div></div><div><br></div><div>Starting the daemon shows this:<br><br>ipsec_setup: Starting Openswan IPsec 2.6.40...<br>ipsec_setup: No KLIPS support found while requested, desperately falling back to netkey<br>ipsec_setup: NETKEY support found. Use protostack=netkey in /etc/ipsec.conf to avoid attempts to use KLIPS. Attempting to continue with NETKEY<br>Aug 6 13:27:36 ip-LOCAL-IP ipsec__plutorun: Starting Pluto subsystem...<br><br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: Starting Pluto (Openswan Version 2.6.40; Vendor ID OSWvfazocUPZ) pid:21060<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: LEAK_DETECTIVE support [disabled]<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: OCF support for IKE [disabled]<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: SAref support [disabled]: Protocol not available<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: SAbind support [disabled]: Protocol not available<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: NSS support [disabled]<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: HAVE_STATSD notification support not compiled in<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: Setting NAT-Traversal port-4500 floating to on<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: port floating activation criteria nat_t=1/port_float=1<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: NAT-Traversal support [enabled]<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: using /dev/urandom as source of random entropy<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: starting up 1 cryptographic helpers<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: started helper pid=21061 (fd:6)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: Kernel interface auto-pick<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: Using Linux XFRM/NETKEY IPsec interface code on 3.14.48-33.39.amzn1.x86_64<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21061]: using /dev/urandom as source of random entropy<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_ccm_8: Ok (ret=0)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type '0', algo_id '0', Algorithm type already exists<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_ccm_12: FAILED (ret=-17)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type '0', algo_id '0', Algorithm type already exists<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_ccm_16: FAILED (ret=-17)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type '0', algo_id '0', Algorithm type already exists<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_gcm_8: FAILED (ret=-17)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type '0', algo_id '0', Algorithm type already exists<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_gcm_12: FAILED (ret=-17)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type '0', algo_id '0', Algorithm type already exists<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc(): Activating aes_gcm_16: FAILED (ret=-17)<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description "PRIMARY-CON/0x1"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description "PRIMARY-CON/0x2"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description "SECONDARY-CON/0x1"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description "SECONDARY-CON/0x2"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: listening for IKE messages<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface eth0/eth0 LOCAL-IP:500<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface eth0/eth0 LOCAL-IP:4500<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo <a href="http://127.0.0.1:500">127.0.0.1:500</a><br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo <a href="http://127.0.0.1:4500">127.0.0.1:4500</a><br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo ::1:500<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from "/etc/ipsec.secrets"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from "/etc/ipsec.d/connect_to_primary.secrets"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from "/etc/ipsec.d/connect_to_secondary.secrets"<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: initiating all conns with alias='PRIMARY-CON' <br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: initiating all conns with alias='SECONDARY-CON' <br><br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: "PRIMARY-CON/0x2": We cannot identify ourselves with either end of this connection.<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: "PRIMARY-CON/0x1": We cannot identify ourselves with either end of this connection.<br><br><br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: "SECONDARY-CON/0x2": We cannot identify ourselves with either end of this connection.<br>Aug 6 13:27:36 ip-LOCAL-IP pluto[21060]: "SECONDARY-CON/0x1": We cannot identify ourselves with either end of this connection.<br><br>Aug 6 13:27:38 ip-LOCAL-IP pluto[21060]: packet from PRIMARY-CON-IP:500: received Vendor ID payload [RFC 3947] method set to=115 <br>Aug 6 13:27:38 ip-LOCAL-IP pluto[21060]: packet from PRIMARY-CON-IP:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07] meth=112, but already using method 115<br>Aug 6 13:27:38 ip-LOCAL-IP pluto[21060]: packet from PRIMARY-CON-IP:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115<br>Aug 6 13:27:38 ip-LOCAL-IP pluto[21060]: packet from PRIMARY-CON-IP:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115<br>Aug 6 13:27:38 ip-LOCAL-IP pluto[21060]: packet from PRIMARY-CON-IP:500: initial Main Mode message received on LOCAL-IP:500 but no connection has been authorized with policy=PSK<br>Aug 6 13:28:08 ip-LOCAL-IP pluto[21060]: packet from SECONDARY-CON-IP:4500: received Vendor ID payload [RFC 3947] method set to=115 <br>Aug 6 13:28:08 ip-LOCAL-IP pluto[21060]: packet from SECONDARY-CON-IP:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07] meth=112, but already using method 115<br>Aug 6 13:28:08 ip-LOCAL-IP pluto[21060]: packet from SECONDARY-CON-IP:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115<br>Aug 6 13:28:08 ip-LOCAL-IP pluto[21060]: packet from SECONDARY-CON-IP:4500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115<br>Aug 6 13:28:08 ip-LOCAL-IP pluto[21060]: packet from SECONDARY-CON-IP:4500: initial Main Mode message received on LOCAL-IP:4500 but no connection has been authorized with policy=PSK<br><br><br></div><div>These connections (?) repeat every few seconds.<br><br></div><div>The PSK lines match, the keys match the other end and I've tried swapping them just in case they were in the wrong order. I've turned off the secondary by removing the conf and secrets files. I've changed the LOCAL-IP to match the elastic IP, none of these have any effect. <br><br></div><div>Changing left= from %defaultroute to the LOCAL-IP eliminates the "We cannot identify ourselves with either end of this connection" message.<br><br></div><div>The "packet from" lines are connection attempts from the remote Cisco box? But there's nothing in the configuration that identifies it as a valid peer? <br><br></div><div>I tried %any in the secrets files, that didn't work either.<br><br></div><div>This configuration in 2.6.37 could bring up the tunnels, but no traffic would flow down them...<br></div><div><br></div><div></div><div>Thanks for any advice you can give me.<br><br></div><div>Regards,<br></div><div>Ken<br></div><div><br></div><div><br><div><br>-- <br><div class="gmail_signature">Ken Barlow, Unix Systems Administrator<br>
Rochester, NY<br><br></div>
</div></div></div></div></div></div></div>