[Openswan Users] 2.6.24rc4 - route problem

Bartek Knapek openswan at knapek.pl
Wed Dec 30 04:59:44 EST 2009


Hi,

   I am using IPSec/L2TP to strenghten encryption of the data sent over 
WLAN. My setup looks like this:

                      WLAN        Openswan
WLAN Client  =================== Server
192.168.13.132                   192.168.13.129/25 (WLAN device)
(192.168.13.101 in VPN)          192.168.13.1/25   (internal LAN device)

As you see I have 2 subnets:
  - 192.168.13.0/25 is a wired LAN,
  - 192.168.13.128/25 is WLAN

When connected using VPN, the WLAN clients are assigned IP addresses 
from the wired LAN.

Before the VPN connection is established, "route" shows the following data:

Destination     Gateway   Genmask         Flags Metric Ref    Use Iface
192.168.13.0    *         255.255.255.128 U     0      0        0 eth1
192.168.13.128  *         255.255.255.128 U     0      0        0 wlan0
192.168.13.128  *         255.255.255.128 U     0      0        0 ipsec1
213.134.184.0   *         255.255.252.0   U     0      0        0 eth0
loopback        *         255.0.0.0       U     0      0        0 lo
default         [cut]     0.0.0.0         UG    0      0        0 eth0


When I setup VPN then it looks like this:

Destination     Gateway   Genmask         Flags Metric Ref    Use Iface
192.168.13.132  0.0.0.0   255.255.255.255 UH    0      0        0 ipsec1
192.168.13.101  0.0.0.0   255.255.255.255 UH    0      0        0 ppp0
192.168.13.0    0.0.0.0   255.255.255.128 U     0      0        0 eth1
192.168.13.128  0.0.0.0   255.255.255.128 U     0      0        0 wlan0
192.168.13.128  0.0.0.0   255.255.255.128 U     0      0        0 ipsec1
213.134.184.0   0.0.0.0   255.255.252.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0   255.0.0.0       U     0      0        0 lo
0.0.0.0         [cut]     0.0.0.0         UG    0      0        0 eth0


But when a transport layer is broken (e.g. I disable WLAN in the client 
for a moment) then the ppp0 dissapears from route, but the direct route 
to 192.168.13.132 via ipsec1 remains, and it stays like this:

Destination     Gateway   Genmask         Flags Metric Ref    Use Iface
192.168.13.132  0.0.0.0   255.255.255.255 UH    0      0        0 ipsec1
192.168.13.0    0.0.0.0   255.255.255.128 U     0      0        0 eth1
192.168.13.128  0.0.0.0   255.255.255.128 U     0      0        0 wlan0
192.168.13.128  0.0.0.0   255.255.255.128 U     0      0        0 ipsec1
213.134.184.0   0.0.0.0   255.255.252.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0   255.0.0.0       U     0      0        0 lo
0.0.0.0         [cut]     0.0.0.0         UG    0      0        0 eth0

The .132 client is no longer able to use the WLAN, since all the traffic 
is sent from the server via ipsec1 instead of wlan0. I need to manually 
take ipsec1 down and restart ipsec in order to return to the initial 
"route" state.

I have also noticed the following message in the logs:

pluto[9620]: "MatyldaVPN-Home": unroute-host output: 
/usr/local/lib/ipsec/_updown.klips: doroute `ip route delete 
192.168.13.132/32  dev ipsec1 ' failed (RTNETLINK answers: No such process)

This is the only problem I have with the 2.6.24rc4 version.
I am using Slackware 13 with 2.6.32. xl2tpd is 1.2.4

Is it a bug, or is it a problem with my configuration?

My ipsec.conf:

config setup
         nat_traversal=yes 

         oe=off 

         protostack=klips 

         fragicmp=no 


conn MatyldaVPN-Home
                 authby=secret
                 pfs=no
                 keyingtries=3
                 rekey=no
                 type=transport
                 left=192.168.13.129
                 leftprotoport=17/1701
                 right=%any
                 rightprotoport=17/1701
                 auto=add



A secondary issue that I cannot overcome yet is that once in the VPN the 
client cannot renew it's WLAN IP address (192.168.13.132). I have a DHCP 
server running on 192.168.13.129. The client sends DHCP requests from 
.132 to .129, but the replies do not come. I guess the direct route via 
ipsec1 is the problem here. It is possible to solve it somehow?

BR/Bartek


More information about the Users mailing list