[Openswan Users] Getting a handle on ip xfrm

[Whit Blauvelt]

Okay, I now see that xfrm is used by netkey, and xfrm is totally new to me.
I can see that Openswan sets up the following on my system:

# ip xfrm policy
src zz.zz.zz.192/26 dst 192.168.1.0/24 
	dir in priority 2342 
	tmpl src yy.yy.yy.222 dst xx.xx.xx.114
		proto esp reqid 16389 mode tunnel
src 192.168.1.0/24 dst zz.zz.zz.192/26 
	dir out priority 2342 
	tmpl src xx.xx.xx.114 dst yy.yy.yy.222
		proto esp reqid 16389 mode tunnel
src zz.zz.zz.192/26 dst 192.168.1.0/24 
	dir fwd priority 2342 
	tmpl src yy.yy.yy.222 dst xx.xx.xx.114
		proto esp reqid 16389 mode tunnel

Where:

xx.xx.xx.114 is left public IP
192.168.1.0/24 is left subnet
yy.yy.yy.222 is right public IP
zz.zz.zz.192/26 is right subnet

Is this about what I should be seeing, given that I'm trying to find what's
required to get the not-working-yet tunnel going? There are policies here to
tunnel in and out, and a policy to forward in - but not a policy to forward
from the local subnet to the remote one. Should there be one?

What does it need to match up with in terms of routes set by the routing
tables? Anything?

I find some old discussion of xfrm on the list, for instance here:

http://lists.openswan.org/pipermail/users/2006-August/010473.html

but it looks like Openswan has evolved since then. At least the policies I
get are more complex statements. That post does usefully suggest that
whatever's not getting set up in my case, probably because I don't use a
default route in the basic way for Openswan to deduce stuff from, can be set
up through a script, if only I can complete my own deduction of what the end
state must be for the tunnel to work.

If this gets solved, I'll write up at least a basic Openswan-on-Ubuntu to
Cisco recipe, because both Ubuntu and Ciscos are pretty damn common, so
solving this would be useful to many. I checked the StrongSwan mailing list
to see how people are doing connecting that to Ciscos, and it doesn't look
good there. Mostly problem reports that get ignored or at best half
answered. Maybe Cisco's IPsec is still so broken that it's not fully
compatible with anything but another Cisco. But I know I should be getting
farther than I am. And even if we're stuck buying a Cisco for our end, it
would be useful to have Openswan as a backup - or else we'll really need a
second Cisco for failover, too. Even a < 100% reliable Openswan backup would
be enough in that department, avoiding a single point of failure there.

Best,
Whit