[Openswan Users] Openswan 2.5.17 doesn't work6

milan.lesnik at uni-mb.si milan.lesnik at uni-mb.si
Mon Mar 3 13:47:17 EST 2008


Hi

> On Mon, 3 Mar 2008, Milan Lesnik wrote:
> 
> > My setup (klips 2.5.17, pluto 2.5.17, kernel 2.6.19.7):
> 
> >     type=transport
> >     left=164.8.1.116
> >     leftnexthop=164.8.1.1
> >     leftprotoport=17/1701
> 
> >     right=%any
> >     rightprotoport=17/1701
> >     rightsubnet=vhost:%no,%priv
> 
> > I establish an IPSEC connection but tunnel doesn't work.
> 
> This is the server side, and not the client side right?

Yes this is server side.
 
> > Here are commands eroute and route.
> >
> > v-debian:~# /usr/local/sbin/ipsec eroute
> > 0     164.8.1.116/32  -> 192.168.2.3/32:1701 => comp0xdf5c at 82.149.5.181:17
> 
> Can you try using compress=no?
> Can you also try leaving out "type=transport" ?
> 
> Indeed, it looks like the traffic selector got dropped. Can you show me the
> output of: grep 164.8.1.116 /proc/net/ipsec/*eroute*. I want to make sure
> that this is a real problem, and not just a displaying problem of the eroute
> command.

It is a real problem. After I establish this tunnel, I want to establih L2TP 
tunnel, but this has never happen, because server wanted to establish a L2TP 
tunnel with public interface of my fw/nat box. And of course those packets 
aren't encrypted (viewed with tcpdump).

But here are /proc/net/ipsec/*eroute*:

type=transport & compress=yes
v-debian:~# cat /proc/net/ipsec_eroute 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x851d at 82.149.5.181:17
v-debian:~# cat /proc/net/ipsec/eroute/all 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x851d at 82.149.5.181:17


comment out type=transport & compress=yes
v-debian:~# cat /proc/net/ipsec_eroute 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0xa61c at 82.149.5.181:17
v-debian:~# cat /proc/net/ipsec/eroute/all 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0xa61c at 82.149.5.181:17


type=transport & compress=no
v-debian:~# cat /proc/net/ipsec_eroute 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x570b at 82.149.5.181:17
v-debian:~# cat /proc/net/ipsec/eroute/all 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x570b at 82.149.5.181:17


comment out type=transport & compress=no
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x122b at 82.149.5.181:17
v-debian:~# cat /proc/net/ipsec_eroute 
0          164.8.1.116/32     -> 192.168.2.3/32:1701 => 
comp0x122b at 82.149.5.181:17

Allways the same - port 1701 is missing.

> > v-debian:~# route -n
> > Kernel IP routing table
> > Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> > 192.168.2.3     164.8.1.1       255.255.255.255 UGH  t 0      0        0 ipsec0
> > 164.8.1.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
> > 164.8.1.0       0.0.0.0         255.255.255.0   U     0      0        0 ipsec0
> > 0.0.0.0         164.8.1.1       0.0.0.0         UG    0      0        0 eth0
> >
> > Route points to 192.168.2.3 and not to public address of the nat box.
> 
> I am not sure if I follow you here.
>
> I also see only 1 interface here? Is this the client? If so, you need to use
> %defaultroute, not %any.

I want to pinpoint out this strange route - from public network to my nated 
client at home.
 
This is server.
 


In my server config (/etc/ipsec.d/no_conf) I have lines rightcert=client.pem 
and rightca=%same. Openswan 2.4.12 has no problem with those two lines - 
everything works perfectly. Under Openswan 2.5.17 I have to comment out those 
two lines - my nated client wasn't able to connect (I can't establish ipsec 
tunnel). It took me two hours to figure out why - my server log was filled 
with:

Mar  2 16:53:04 v-debian pluto[6062]: "unimb"[1] 82.149.5.181 #2: no suitable 
connection for peer 'C=SI, ST=Slovenia, L=Maribor, O=University of Maribor, 
OU=Computer Centre, CN=client, E=ca-admin at uni-mb.si'

82.149.5.181 is public interface of my nat/fw at home (kernel 2.6.24), client 
is linux (2.6.24).

After commenting them out I could establish a quasi tunnel (port 1701 is 
missing).

I forgot to mention this problem in my first post.

Milan
-- 
----------------------------------------------------------------------
|Milan Lesnik, system manager         |http://rcum.uni-mb.si/~milan  |
|University Computer Centre, Maribor  |http://www.uni-mb.si/         |
|Tel: +386 2 2355 300                 |email: milan.lesnik at uni-mb.si |
|Fax: +386 2 2355 316                 |DECMail-Slovenia: rcum::milan |
----------------------------------------------------------------------
|    UNIX was not designed to be a secure OS - Sysadmin, June 97     |
----------------------------------------------------------------------




More information about the Users mailing list