[Openswan Users] "cannot install eroute" after remote IP change

[Greg Scott]

For what it's worth, I had some customers behind DHCP NAT gateways doing
VPNs.  I settled on OpenVPN for those instead of IPSEC and it's worked
out very well.  The challenge is, I can't access the NATed box unless
the OpenVPN tunnel is alive, but it's the same challenge with IPSEC.
And only the remote site can initiate a connection, so this adds some
complexity to troubleshooting outages - but no different than IPSEC.
The advantage is, you don't care about the remote site public IP Address
because the remote site connects based on an identity and not an IP
Address.  The other advantage is, you can test it from anywhere.  You
can put it together in a test lab, test everything, then deploy it and
it will run the same at the production site as in your test lab.  And
all it needs is UDP port 1194 going out, so it's firewall friendly.  

- Greg



-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Paul Wouters
Sent: Wednesday, February 09, 2011 9:24 PM
To: Michael Smith
Cc: OpenSwan
Subject: Re: [Openswan Users] "cannot install eroute" after remote IP
change

On Tue, 8 Feb 2011, Michael Smith wrote:

> I'm using Openswan 2.6.31, Linux 2.6.35.10, and NETKEY. One of my
remote
> sites is behind NAT and the public IP changes every couple of hours
(!).

Obviously not a scenario recommended for running ipsec on.....

> There are several IPsec SAs for the peer. After one or two IP changes,
> one or more of the IPsec SAs keeps failing to negotiate with a message
> like the following:
>
> Feb  7 16:45:42 vpngw pluto[10130]: "bldg-site111-laptops"[2] 5.6.7.8
> #25879: cannot install eroute -- it is in use for
> "bldg-site111-laptops"[1] 5.6.7.8 #0

Your connection should not be instantiating if this is a static tunnel.

Are you running scripts to bring up the tunnel?

> conn bldg-site111-laptops
>     rightsubnet=192.168.111.0/24
>     also=bldg-site-common
>     also=bldg-common-laptops
>     auto=add
>
> conn bldg-site111-support
>     rightsubnet=192.168.111.0/24
>     also=bldg-site-common
>     also=bldg-common-support
>     auto=add
>
> conn bldg-site112-laptops
>     rightsubnet=192.168.112.0/24
>     also=bldg-site-common
>     also=bldg-common-laptops
>     auto=add
>
> conn bldg-site112-support
>     rightsubnet=192.168.112.0/24
>     also=bldg-site-common
>     also=bldg-common-support
>     auto=add
>
> conn bldg-site49_32-phones
>     rightsubnet=192.168.49.32/29
>     also=bldg-site-common
>     also=bldg-common-phones
>     auto=add
>
> <some other tunnels not shown>
>
> conn bldg-site-common
>     right=%any
>     rightid=@remote-vpngw
>     rekey=no

I guess the right=%any causes the instantiation. But it should replace
instead of add the connections. You did not specify uniqueids=false
in config setup right?

> conn bldg-common-laptops
>     leftsubnet=10.1.2.0/24
>     left=44.44.44.44
>     leftid=@vpngw.cbnco.com
>     leftcert=/etc/x509cert.der
>
> conn bldg-common-support
>     leftsubnet=10.1.1.0/24
>     left=44.44.44.44
>     leftid=@vpngw.cbnco.com
>     leftcert=/etc/x509cert.der

Your different conns have the same ID. This might be confusing things.
I would try to specify unique leftids (on both sides!) for each tunnel.

Paul
_______________________________________________
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users
Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
Building and Integrating Virtual Private Networks with Openswan: 
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155