[Openswan Users] Multi-hop IPSec

[Kevin Keane (subscriptions)]

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 (10.0.1.1/32) ===== hub1 (10.0.2.1) ========= hub2 (10.0.3.1) ----------- leaf2 (10.0.4.0/24)

I am trying to add this tunnel definition to hub1:

Right leaf1
LeftSubnet 10.0.2.1/32,10.0.4.0/24

Hub1 complains" our client(10.0.2.1) not in our_net(10.0.4.0/24)" and refuses to authenticate this whole connection. This actually makes sense: 10.0.4.0/24 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 10.0.4.0/24.

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 10.0.1.0 and 10.0.2.0 
> > 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 = 10.0.2.0 (the hub) even if the final destination is 10.0.4.0 (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 10.0.1.0 to 10.0.2.0 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 10.0.4.0 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):
leftsubnet=10.0.1.0/24
Rightsubnets=10.0.2.0/32,10.0.4.0/24

Hub1 connection to Hub2 (left=Hub1, Right=Hub2):
Leftsubnet=10.0.2.0/32
Rightsubnets=10.0.3.0/32,10.0.4.0/24

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

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


_______________________________________________
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