[Openswan Users] configuration problem, We cannot identify ourselves with either end of this connection.

Ken Barlow fifedrum at gmail.com
Thu Aug 6 10:48:17 EDT 2015


Good morning,

If someone can please hit me really hard in the face with the clue-stick I
would appreciate it.

Connecting an AWS EC2 instance running openswan to a Cisco ASA class
machine via IPSec VPN fails.

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.

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
Amazon Linux AMI release 2015.03

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.

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.

LOCAL-IP-NETWORK/16
EC2 instance (LOCAL-IP)
(Elastic IP)
...
Internet
...
(PRIMARY-CON-IP)
Cisco router (presumably on an IP behind NAT?)
REMOTE-IP-NETWORK/17

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.

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.

# /etc/ipsec.conf - Openswan IPsec configuration file
version    2.0    # conforms to second version of ipsec.conf specification
config setup
    plutoopts="--perpeerlog"
    dumpdir=/var/run/pluto/
    nat_traversal=yes
    virtual_private=%v4:192.168.0.0/24
    oe=off
    protostack=auto
include /etc/ipsec.d/*.conf

and /etc/ipsec.d/*.conf:

conn PRIMARY-CON
    type=tunnel
    authby=secret
    left=LOCAL-IP
        leftid=LOCAL-IP
        leftnexthop=%defaultroute
        leftsubnet=LOCAL-IP-NETWORK/16
        right=PRIMARY-CON-IP
    remote_peer_type=cisco
        rightsubnets={REMOTE-IP-NETWORK-A/17,REMOTE-IP-NETWORK-B/17}
        pfs=yes
        auto=start
conn SECONDARY-CON
    type=tunnel
    authby=secret
    left=%defaultroute
        leftid=LOCAL-IP
        leftnexthop=%defaultroute
        leftsubnet=LOCAL-IP-NETWORK/16
        right=SECONDARY-CON-IP
        rightsubnets={REMOTE-IP-NETWORK-A/17,REMOTE-IP-NETWORK-B/17}
        pfs=yes
        auto=start

secets files:
LOCAL-IP PRIMARY-CON-IP: PSK "FooBarBaz"
LOCAL-IP SECONDARY-CON-IP: PSK "FooBarBaz"


Starting the daemon shows this:

ipsec_setup: Starting Openswan IPsec 2.6.40...
ipsec_setup: No KLIPS support found while requested, desperately falling
back to netkey
ipsec_setup: NETKEY support found. Use protostack=netkey in /etc/ipsec.conf
to avoid attempts to use KLIPS. Attempting to continue with NETKEY
Aug  6 13:27:36 ip-LOCAL-IP ipsec__plutorun: Starting Pluto subsystem...

Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: Starting Pluto (Openswan Version
2.6.40; Vendor ID OSWvfazocUPZ) pid:21060
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: LEAK_DETECTIVE support [disabled]
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: OCF support for IKE [disabled]
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: SAref support [disabled]:
Protocol not available
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: SAbind support [disabled]:
Protocol not available
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: NSS support [disabled]
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: HAVE_STATSD notification support
not compiled in
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: Setting NAT-Traversal port-4500
floating to on
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]:    port floating activation
criteria nat_t=1/port_float=1
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]:    NAT-Traversal support
[enabled]
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: using /dev/urandom as source of
random entropy
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: starting up 1 cryptographic
helpers
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: started helper pid=21061 (fd:6)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: Kernel interface auto-pick
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
Aug  6 13:27:36 ip-LOCAL-IP pluto[21061]: using /dev/urandom as source of
random entropy
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_ccm_8: Ok (ret=0)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type
'0', algo_id '0', Algorithm type already exists
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_ccm_12: FAILED (ret=-17)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type
'0', algo_id '0', Algorithm type already exists
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_ccm_16: FAILED (ret=-17)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type
'0', algo_id '0', Algorithm type already exists
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_gcm_8: FAILED (ret=-17)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type
'0', algo_id '0', Algorithm type already exists
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_gcm_12: FAILED (ret=-17)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_add(): ERROR: algo_type
'0', algo_id '0', Algorithm type already exists
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: ike_alg_register_enc():
Activating aes_gcm_16: FAILED (ret=-17)
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description
"PRIMARY-CON/0x1"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description
"PRIMARY-CON/0x2"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description
"SECONDARY-CON/0x1"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: added connection description
"SECONDARY-CON/0x2"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: listening for IKE messages
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface eth0/eth0
LOCAL-IP:500
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface eth0/eth0
LOCAL-IP:4500
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo
127.0.0.1:500
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo
127.0.0.1:4500
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: adding interface lo/lo ::1:500
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from
"/etc/ipsec.secrets"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from
"/etc/ipsec.d/connect_to_primary.secrets"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: loading secrets from
"/etc/ipsec.d/connect_to_secondary.secrets"
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: initiating all conns with
alias='PRIMARY-CON'
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: initiating all conns with
alias='SECONDARY-CON'

Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: "PRIMARY-CON/0x2": We cannot
identify ourselves with either end of this connection.
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: "PRIMARY-CON/0x1": We cannot
identify ourselves with either end of this connection.


Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: "SECONDARY-CON/0x2": We cannot
identify ourselves with either end of this connection.
Aug  6 13:27:36 ip-LOCAL-IP pluto[21060]: "SECONDARY-CON/0x1": We cannot
identify ourselves with either end of this connection.

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
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
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
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
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
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
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
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
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
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


These connections (?) repeat every few seconds.

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.

Changing left= from %defaultroute to the LOCAL-IP eliminates the "We cannot
identify ourselves with either end of this connection" message.

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?

I tried %any in the secrets files, that didn't work either.

This configuration in 2.6.37 could bring up the tunnels, but no traffic
would flow down them...

Thanks for any advice you can give me.

Regards,
Ken



-- 
Ken Barlow, Unix Systems Administrator
Rochester, NY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150806/6a1b5cf6/attachment.html>


More information about the Users mailing list