[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