[Openswan Users] "We cannot identify ourselves with either end of this connection." on EC2 instance
amos.shapira at gmail.com
Wed Jan 20 00:14:08 EST 2016
Just a quick update - I'm not sure what changed but I managed to get the
VPN working without adding the sourceip fields. The second tunnel also
reports up after a while, sometimes.
I also got forwarding between all subnets (public and private on each side
of the VPN) as well as NAT to the public Internet from the single EC2
Here are the working configuration files, in case someone else finds this
/etc/ipsec.conf (note - 172.29/16 is the local subnet of the EC2 instance
Thanks for your help.
On 19 January 2016 at 17:42, Amos Shapira <amos.shapira at gmail.com> wrote:
> Thanks Neal,
> I'll test that when I get back to the office tomorrow.
> In the meantime I found a copy of the old working ipsec.conf and compared
> it with the one that doesn't work (which is basically the default one from
> the Ubuntu package, plus an "include /etc/ipsec.d/*.conf") and noticed that
> they differ in the "protostack" setting - the working one had "netkey" and
> the broken one had "auto". Once I updated the broken config file to
> "netkey" the connection came up (with everything else untouched, as far as
> I remember).
> One of the VPN tunnels is now marked as "up" on the AWS side (the second
> one is down, with an error about "can't set eroute, already used" in the
> ipsec logs, I suspect this is normal), but no routing is happening. (ping
> to an EC2 instance behind the virtual GW doesn't get any response, and I
> don't see where the packets go. It's not a firewall/security-group/acl
> On 19 January 2016 at 17:04, Neal P. Murphy <neal.p.murphy at alum.wpi.edu>
>> On Tue, 19 Jan 2016 15:47:20 +1100
>> Amos Shapira <amos.shapira at gmail.com> wrote:
>> > Hello,
>> > I'm trying to connect an EC2 instance to an Amazon Virtual gateway using
>> > openswan.
>> > My configuration:
>> > 1. Ubuntu Trusty, up to date.
>> > 2. Openswan 2.6.38 from the standard Ubuntu package.
>> > The following configuration (real IP's slightly obscured) worked for me
>> > before when I did manual tests:
>> > conn sing-sydney
>> > type=tunnel
>> > authby=secret
>> > forceencaps=yes
>> > auto=start
>> > left=%defaultroute
>> > leftid=52.74.73.X
>> > #leftsourceip=52.74.73.X
>> > leftnexthop=%defaultroute
>> > leftsubnet=172.28.0.0/16
>> > right=52.64.16.Y
>> > rightid=52.64.16.Y
>> > rightsubnet=172.27.0.0/16
>> > ...
>> > So what am I missing to make it work?
>> I think you need *sourceip.
>> In a nutshell (meaning this is close but mayhap not technically
>> accurate), 'left' and 'right' are the publicly-accessible addresses; each
>> tells the remote end where to send packets. 'leftsourceip' and
>> 'rightsourceip' are the 'private' or 'locally assigned' addresses on the
>> public-facing interfaces; each tells the local end which interface to use.
>> *sourceip is usually used when an end is behind a NATting firewall; this
>> end usually has to initiate the VPN.
>> Users at lists.openswan.org
>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users