[Openswan Users] OpenSwan L2TP client to Sonicwall 2040

Gaiseric Vandal gaiseric.vandal at gmail.com
Wed May 16 19:23:25 EDT 2007


I am attempting to connect to the L2TP server on a Sonicwall Pro 2040
(with enhanced OS) from Openswan on Fedora Core 6. (The Ipsec
parameters are generally the same as those used for a IPSec tunnel VPN
connection.) This is with PSK (PreShared Key) and whatever user
authentication will be supported by the Linux PPP configuration
(possibly PAP for RSA Authentication Manager compatibility.)


(Alternately, I have also been trying to connect with OpenSWAN as an
IPSec XAUTH client, but I will address that in a separate post.


I was able to establish a L2TP connection with native VPN client in MS
Windows XP Pro. XAUTH is required by the sonicwall for IPSec tunnel
(non-L2TP) connections. This shouldn't matter for L2TP connections
(and in fact MS Windows XP Pro L2TP doesn't support XAUTH anyway, and
is using PAP or MS-CHAP.)


With OpenSwan, I only seem to be able to establish a connection as
long as as XAUTH is not required by the Sonicwall. However, the
sonicwall does not show any L2TP tunnels, so I suspect that OpenSwan
is not really connecting to the L2TP server on the sonicwall.

I have tried with both RPM version of OpenSwan 2.4.7, as well as
compiling it myself. I compiled it with
USE_XAUTH?=true,
USE_NAT_TRAVERSAL?=true
USE_NAT_TRAVERSAL_TRANSPORT_MODE?=true
USE_XAUTHPAM?=true

The configuration is as follows (the remote user is "left.")

__________________________________________________
_________________________________

conn l2tp1
type=transport
#left=%defaultroute
left=192.168.1.52
leftsubnet=192.168.1.0/24
#leftsubnet=192.168.100.0/24
leftid=@GroupVPN
# For updated Windows 2000/XP clients,
# to support old clients as well, use leftprotoport=17/%any
#leftprotoport=17/1701
#old style
leftprotoport=17/0
#leftprotoport=17/%any
#leftid=@bugsy.ssci.com
#right=%any
right=sonicwall.public.ip.address
rightsubnet=192.168.0.0/24
rightid=@pro2040
rightprotoport=17/1701
keyingtries=0
pfs=no
auto=add
auth=esp
esp=3des-sha1
ike=3des-sha1-modp1024
authby=secret
#rekey=no
#left=%defaultroute
aggrmode=no

__________________________________________________
_________________________________

I try connecting with either

# ipsec whack --name l2tp1 --initiate
or
# ipsec auto –up l2tp1

I get the following:
__________________________________________________
_________________________________

# ipsec auto --up ssci_l2tp
104 "ssci_l2tp" #1: STATE_MAIN_I1: initiate
003 "ssci_l2tp" #1: ignoring unknown Vendor ID payload [5b362bc820f60003]
003 "ssci_l2tp" #1: received Vendor ID payload [RFC 3947] method set to=110
106 "ssci_l2tp" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "ssci_l2tp" #1: ignoring unknown Vendor ID payload [404bf439522ca3f6]
003 "ssci_l2tp" #1: received Vendor ID payload [XAUTH]
003 "ssci_l2tp" #1: received Vendor ID payload [Dead Peer Detection]
003 "ssci_l2tp" #1: NAT-Traversal: Result using RFC 3947
(NAT-Traversal): i am NATed
108 "ssci_l2tp" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "ssci_l2tp" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
004 "ssci_l2tp" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
117 "ssci_l2tp" #2: STATE_QUICK_I1: initiate
010 "ssci_l2tp" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "ssci_l2tp" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "ssci_l2tp" #2: max number of retransmissions (2) reached
STATE_QUICK_I1. No acceptable response to our first Quick Mode
message: perhaps peer likes no proposal
000 "ssci_l2tp" #2: starting keying attempt 2 of an unlimited number,
but releasing whack
#
__________________________________________________
_________________________________

I never get prompted for a user name and password. And I never get
passed phase 1. Main mode seems more reliable than aggressive mode, I
am not using PFS, and I am using DH Group 2 (modp1024.)

I have tried both

leftprotoport=17/0
and
leftprotoport=17/1701

(Transport mode doesn't seem to like wild cards.



The sonicwall log shows

__________________________________________________
_________________________________

IKE Responder: Received Main Mode request (Phase 1)
NAT Discovery : Peer IPSec Security Gateway behind a NAT/NAPT Device
IKE Responder: Main Mode complete (Phase 1)
IKE Responder: Received Quick Mode Request (Phase 2)
IKE Responder: Mode 3 - not transport mode. Xauth is required but not
supported by peer.
IKE Responder: IPSec proposal does not match (Phase 2)

__________________________________________________
_________________________________

Any thoughts?

Thanks


More information about the Users mailing list