<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
I have Sonicwall Pro 2040 Router with SonicOS Enhanced
3.2.3.0-6e. The sonicwall has a default "GroupVPN" policy for
client VPN connections. Xauth authentication is used. The
"Virtual Adapter" settings specify "DHCP lease or Manual
Configuration." Windows clients with the SonicWall GlobalVPN
client use a virtual NIC with DHCP for the VPN connection.<br>
<br>
<br>
I have a linux client running Fedora Core 14 (x64) with the bundled
openswan ver 2.6.33-3. This uses NETKEY for IPSec. I have
configured an IPSec client VPN connection to the sonicwall
Sonicwall. This is ipsec tunnel (not transport over PPTP or L2TP)
I am able to connect if I specify the client's current IP in
/etc/ipsec.conf. But this means you have to update the
ipsec.conf file everytime your IP address changes. If I configure
ipsec.conf to use "left=%defaultroute" I get through the xauth
authentication but then the connection fails. Xauth authentication
happens between phase 1 and phase 2. <br>
<br>
<br>
The client shows<br>
<br>
no acceptable response to our first quick mode message:
perhaps peer likes no proposal<br>
<br>
<br>
The server log shows<br>
<br>
IKE Responder: Received Quick Mode Request (Phase 2)<br>
IKE Responder: IPSec proposal does not match (Phase 2)<br>
<br>
<br>
I changed the "Virtual Adapter Settings" on the sonicwall to "none"
and I was able to connect from the Linux OpenSwan VPN client. I
then changed the "Virtual Adapter Settings" on the sonicwall back to
DHCP lease or Manual Configuration" to keep the Windows users
functional. However now the linux client seems to be able to
connect anyway (at least for now.) <br>
<br>
I welcome advice on what is going on.<br>
<br>
<br>
My ipsec.conf file generally looks like the following <br>
<br>
------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
config setup<br>
protostack=netkey<br>
interfaces=%defaultroute<br>
nat_traversal=yes<br>
<br>
<br>
<br>
<style type="text/css">p { margin-bottom: 0.08in;
conn SSCI
type=tunnel
#use the following line if you aren't explicitly specifying the
#local ip adress. This may not alway work
left=%defaultroute
#Use the following two lines if you to specify the local ip
#left=192.168.1.64
#leftsubnet=192.168.1.0/24
leftid=@GroupVPN
leftxauthclient=yes
right=173.14.162.93
rightsubnet=192.168.0.0/24 #the private LAN at work...
#rightid is the VPN server identifier
rightid=@pro2040
rightxauthserver=yes
keyingtries=0
pfs=no
auto=add
auth=esp
esp=3des-sha1 # Ipsec (Phase 2) Proposal
ike=3des-sha1-modp1024 #IKE (Phase 1) Proposal
# xauth=yes is valid and required for openswan 2.4 but not 2.6
authby=secret
aggrmode=yes
auto=add
</style><br>
conn MYCOMPANY<br>
type=tunnel<br>
#For Dynamic IP support , uncomment the following line <br>
left=%defaultroute<br>
#For Static IP uncomment the following two lines <br>
#left=192.168.1.x<br>
#leftsubnet=192.168.1.0/24<br>
leftid=@GroupVPN<br>
leftxauthclient=yes<br>
right=PUBLIC_IP_OF_ROUTER <br>
rightsubnet=192.168.20.0/24 #the private LAN at work...<br>
#rightid is the VPN server identifier<br>
rightid=@Sonic2040<br>
rightxauthserver=yes<br>
keyingtries=0<br>
pfs=no<br>
auto=add<br>
auth=esp<br>
#IKE (Phase 1) Proposal<br>
ike=3des-sha1-modp1024 <br>
# Ipsec (Phase 2) Proposal<br>
esp=3des-sha1 <br>
authby=secret<br>
aggrmode=yes<br>
auto=add<br>
#dpd settings don't seem to have an affect<br>
dpddelay=30<br>
dpdtimeout=120<br>
dpdaction=restart<br>
<br>
<br>
------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<br>
Thanks<br>
<br>
<br>
<br>
</body>
</html>