[Openswan Users] Multi-hop IPSec

Kevin Keane (subscriptions) subscription at kkeane.com
Tue Nov 22 06:17:26 EST 2011

I think I'm getting a better understanding of what my problem is - just not sure yet how to get around it. When I turned on pluto logging=all, I got a key error message: our client is not in our_net.

Here is my setup (only showing the relevant parts - also I'm using different IP addresses to show what is a subnet and what is an individual host):

Leaf1 ( ===== hub1 ( ========= hub2 ( ----------- leaf2 (

I am trying to add this tunnel definition to hub1:

Right leaf1

Hub1 complains" our client( not in our_net(" and refuses to authenticate this whole connection. This actually makes sense: is not local on Hub1, but behind *another* tunnel behind Hub2.

But on the other hand, I have to somehow be able to tell leaf1 to use hub1 for traffic to

Is there a way to solve this, or am I running into something IPSec is just not designed for?

-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On Behalf Of Kevin Keane (subscriptions)
Sent: Monday, November 21, 2011 4:53 AM
To: users at openswan.org
Subject: Re: [Openswan Users] Multi-hop IPSec

> -----Original Message-----
> On Behalf Of Tuomo Soini
> On Sun, 20 Nov 2011 16:51:06 -0800
> Kevin Keane (subscriptions) wrote:
> > I think I may be close to solving it. I think my data center may 
> > have a firewall between the leaf and hub1 (the and 
> > networks in the diagram below) that blocks traffic outside the two 
> > destinations.
> No. If both can talk to hub you can build tunnels to do the whole setup.

So the IP header will show dst = (the hub) even if the final destination is (the leaf on the remote end)? I know that there really is a firewall in the path; it is configured to only allow traffic from to and vice versa through.

> > If I remember right, IPSec does not do true tunneling. So my 
> > solution would be to build a network of L2TP tunnels on top of IPSec.
> That is completely wrong - IPsec does real tunneling but only when 
> your packets match ipsec tunnel. Both ends must have two tunnels to 
> hub, one for hub local net, one for remote net behind hub. So if you 
> want this to work correctly your hub need to have 4 tunnes and both 
> endpoints must have 2 tunnels.

Ah, thanks for explaining that. And (slapping forehead) you are right, of course - because the destination IP wasn't in a tunneled subnet, it wouldn't go through the tunnel. What I'm struggling with then is how to get the second tunnel to work; the hub seems to refuse to allow it.

Basically, what you are saying is that the settings should be:

Hub1 connection to Leaf1 (left=Leaf1, right=Hub1):

Hub1 connection to Hub2 (left=Hub1, Right=Hub2):

But when I try that, the log file in Hub1 tells me "initial Main Mode message received on but no connection has been authorized with policy=RSASIG" and both of the connections don't get set up. As soon as I remove from the connection Leaf1-Hub1 (no other changes to the config files), the connection gets established flawlessly (but doesn't forward traffic for

Maybe Hub1 is getting confused because shows up on the local site for one of the two connections, and on the remote side for the other?

Users at openswan.org
Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
Building and Integrating Virtual Private Networks with Openswan: 

More information about the Users mailing list