[Openswan Users] Openswan 2.6.22/CentOS 5.3: what should I see when it is working?

[Kevin White]

I'm trying to set up a VPN between a CentOS 5.3 box and a Cisco router.

I don't have complete control over the Cisco side of the network.  I've 
temporarily been given control of the router, but it isn't a critical 
border device at the moment.  It has a loopback device configured, as 
well as a route in to an internal network.  I should be able to contact 
a host on either once the VPN is set up, and I cannot.

What's confusing me is that it doesn't look like the CentOS box is 
actually routing anything...however, I suspect I just can't see the 
routes in any normal way.  There's so much unknown here that I'm just 
not sure why things aren't working.

First, I'm using Netkey.  I tried this setup with CentOS 5.3 and the 
distro provided Openswan 2.6.14 and ran into the problem, so I compiled 
Openswan 2.6.22 by hand, so that's what I'm running now.  I tried KLIPS 
(hoping that the ipsec0 device would make things more clear), but I had 
the compilation problem on CentOS 5.3 reported earlier.  I tried the fix 
as proposed on the mailing list, and that just resulted in a KLIPS 
module that seriously breaks the system (after a modprobe ipsec, I can't 
even run an "ifconfig" any more...no interfaces show up, and the only 
way to recover is reboot).  So, I went back to Netkey.

My configuration is pretty darn simple:

x.x.x.x represents the right ip
y.y.y.y is the left
ppp_peer is y.y.y.y's upstream ppp peer.

conn X_1-Y2_1
      type=tunnel
      pfs=no
      left=%defaultroute
      leftsubnet=192.168.10.0/24
      leftid=@X2
      leftnexthop=%defaultroute
      right=x.x.x.x
      rightsubnet=192.168.99.0/24
      auto=start
      esp=3des-md5-96
      authby=secret

The upstream is a ppp device (wireless).  2.6.14 couldn't handle 
%defaultroute in this case, 2.6.22 can.

There's basically nothing in /etc/ipsec.conf (protostack=netkey, 
nat_traversal=no).

On the Cisco side, everything looks like it is up.  On the Openswan 
side, everything also looks good:

000 #2: "X_1-Y2_1":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); 
EVENT_SA_REPLACE in 27868s; newest IPSEC; eroute owner; isakmp#1; idle; 
import:admin initiate
000 #2: "X_1-Y2_1" esp.7a017fe5 at x.x.x.x esp.729ec515 at y.y.y.y 
tun.0 at x.x.x.x tun.0 at y.y.y.y ref=0 refhim=4294901761
000 #1: "X_1-Y2_1":500 STATE_MAIN_I4 (ISAKMP SA established); 
EVENT_SA_REPLACE in 2933s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); 
idle; import:admin initiate

However, if I go to a machine on 192.168.10.x/24 and configure it to 
route 192.168.99.0/24 to 192.168.10.99 (the Openswan box), and then try 
to telnet, I don't see the telnet session go through.

I do, however, see this:

Aug 31 21:27:42 pgKevTest09 ipmon accept IN=eth0 OUT=ppp0 
SRC=192.168.10.10 DST=192.168.99.1 LEN=52 TOS=0x00 PREC=0x00 TTL=127 
ID=27309 DF PROTO=TCP SPT=49533 DPT=23 WINDOW=8192 RES=0x00 SYN URGP=0

which is what should happen...packet comes in eth0, goes out ppp0 
(ip_forward is set to 1).  The telnet never goes through.

So I can't tell if the problem is on my side, or on the network on the 
other side.  (They set up a second network that I should be able to get 
to from the Cisco, and I set up a second tunnel to that subnet, and 
still didn't see the traffic get to a machine on that subnet.)

Since the contents of "ip route" doesn't actually show 192.168.99.0/24, 
I thought maybe routing wasn't working.  However, that ipmon rule kind 
of shows that routing is working.  I wish I knew how routing actually 
works with Netkey.

[root at pgKevTest09 ipsec.d]# ip route
ppp_peer dev ppp0  proto kernel  scope link  src y.y.y.y
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.99
169.254.0.0/16 dev eth0  scope link
default dev ppp0  scope link

This also appears:

[root at pgKevTest09 ipsec.d]# ipsec auto --status|grep eroute
000 "X_1-Y2_1": 
192.168.10.0/24===y.y.y.y[@X2,+S=C]---ppp_peer...x.x.x.x<x.x.x.x>[+S=C]===192.168.99.0/24; 
erouted; eroute owner: #2

So everything looks like the eroute is set up...if the only place you 
actually see anything about the eroute is in ipsec auto --status.

Is there any other sort of testing I can do?

Kevin