WR44 as L2TP over IPSec server

Digi TransPort WR (Series)
,
1

Hello:

I am following AN21 and am attempting to connect from a Windows 7 Pro client.
Here are my client settings:
C:\Windows\system32>netsh advfirewall show global mainmode

Global Settings:

KeyLifetime 480min,0sess
SecMethods DHGroup2-3DES-SHA1,DHGroup2-AES128-SHA1
ForceDH Yes
Ok.

C:\Windows\system32>netsh advfirewall show global ipsec

Global Settings:

StrongCRLCheck 0:Disabled
SAIdleTimeMin 5min
DefaultExemptions NeighborDiscovery,DHCP
IPsecThroughNAT Server and client behind NAT
AuthzUserGrp None
AuthzComputerGrp None
Ok.

So, as you can see, my client is setup for both itself and the WR44 to be behind a NAT wall.

Following the app note and settig the client up to be the admin user it never gets to the ppp negotiation as IPSec fails, this form the event log:
16:56:47, 26 Jul 2016,(74) IKE SA Removed. Peer: ,Negotiation Failure
16:56:47, 26 Jul 2016,(74) IKE Negotiation Failed. Peer: ,Bad Packet
16:56:47, 26 Jul 2016,(74) IKE Keys Negotiated. Peer:
16:56:47, 26 Jul 2016,(74) New Phase 1 IKE Session 119.75.44.126,Responder
16:56:34, 26 Jul 2016,Clear Event Log

Usually this means a mismatched password and username. But my username for user14 is set to “*” and the psk is set to “mynameisjim” Exactly the same osk is used in my connection profile in windows.
ss398837>user 14 ?
Parameters are…
name: *
password:
epassword: .05;yeJFbeoxGAWA/bmI9CLCFgCL6gHEIitGCn54zlBKgZs=
newpwd:
enewpwd:
access: 4
fieldip:
IPaddr:
mask:
phonenum:
keyfile:
dun_en: OFF
webmode: 1
defpage:
Current user:mskroot
OK

ss398837>eroute 1 ?
Parameters are…
descr: L2TPServer
peerip:
bakpeerip:
peerid: *
ourid:
ouridtype: 0
neglocip:
neglocmsk:
locip:
locmsk:
locipifent: PPP
locipifadd: 1
remip:
remmsk:
remnetid:
mode: Transport
AHauth: Off
ESPauth: SHA1
ESPenc: AES
IPCOMPalg: Off
proto: Off
locport: 0
remport: 1701
ltime: 3600
lkbytes: 0
authmeth: PRESHARED
nosa: DROP
nosadeactcnt: 0
nattkaint: 20
autosa: 0
nosaoos: OFF
ikever: 1
ikecfg: 0
locfirstport: 0
loclastport: 65535
remfirstport: 0
remlastport: 65535
dhgroup: 0
ifent:
ifadd: 0
enckeybits: 128
privkey:
check_apnbu: OFF
apnbu: 0
usesecip: OFF
ipent:
ipadd: 0
oosdelsa: ON
intunnel: OFF
ripip:
vip: 0
xauthid:
inhibitno:
requireno:
ifvrrpmaster: OFF
vrrpinstance: -1
inact_to: 0
toslist:
debug: OFF
injectroute: OFF
metric: 1
replaywin: 0
OK

Looking for some pointers on how to trouble shoot this.

Cheers,
John

2

Additional Information from the analyzer trace:
----- 27-7-2016 16:11:29.890 ------
IKE DEBUG: Handling IKE packet

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG: Locating IKE context

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG: Packet for existing negotiation

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Located SA for existing phase 1 negotiation

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):IKE context located. Local session ID: 0x4109

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Checking packet

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):IKE decrypting packet

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Validating payloads

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Checking payload (5) ID

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Packet validation problem. Invalid payload header.

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):IKE unable to process packet

----- 27-7-2016 16:11:29.890 ------
IKE DEBUG (4109):Resetting IKE context 0

You can see where the problem happens with the invalid payload header. I am stuck there.

Its ‘appears’ that the authentication is working so that the user name wild card “" and the remote ID wild card '” are working? I someone can have a look it would be great.

the windows error is typically brief:
The user jserinki7-Win7\jserinkWin7 dialed a connection named Digitest2 which has failed. The error code returned on failure is 789.

I’d like to paste the entire ana.txt files here if that is possible.

Cheers,
John

3

Use something like pastebin if you need to dump the full logs.

Then you can just post the link.

4

Digi is going through the process of updating TransPort AN’s and QN’s, and I believe AN 21 has been updated, but just isn’t yet on the site. Would you like me to try to get it and provide you with a link to it, in case some of the instructions in the current AN you followed were incorrect?

5

Yes please. I was wondering if there is something that has changed since the app note was written. Also, since windows 7 it’s impossible to get the oakleyIKE.log file any longer in windows. That file used to look like a Cisco ‘debug crypto isakmp’ dump which is essential to trouble shooting this stuff. Also, all microsoft offers now is a utility to push notifications of success or failure into the event log…auditpol.exe. There is nothing I have found to give a blow by blow examination of the negotiation like the digi analyser or cisco debug.

6

I’ve uploaded an updated version of AN 21, in case it’s helpful. You can download it via the link just below (which is temporary and will expire in a few months), using the password “eczJJuWf”.

https://na14.salesforce.com/sfc/p/d0000000eJxP/a/d0000001Hj9B/AUuz8zaLoooemk6ffHxz4xkPDqFu9aQHIQVCzRfpfTo

Please let us know if this helps or not.

7

Hello:

Thank you for the new app note. Its not much different from the old but followed it to the T and keep getting the same error. It never gets beyond the IPsec negotiation. That always fails with:
10:44:18, 05 Aug 2016,(308) IKE SA Removed. Peer: ,Negotiation Failure
10:44:18, 05 Aug 2016,(308) IKE Negotiation Failed. Peer: ,Bad Packet
10:44:18, 05 Aug 2016,(308) IKE Keys Negotiated. Peer:
10:44:18, 05 Aug 2016,(308) New Phase 1 IKE Session 119.75.44.126,Responder

Out of ideas here really. The lack of tools on the windows side really makes this difficult to trouble shoot.

I have tried to figure out how to use wireshark to decode IKE packets but so far have had no luck with that…but am not sure it would help. Windows is doing something so we need to see what it is doing, Via auditpol, this is all I get form the event viewer:
An IPsec main mode negotiation failed.

Local Endpoint:
Local Principal Name: -
Network Address: 192.168.100.233
Keying Module Port: 4500

Remote Endpoint:
Principal Name: -
Network Address: 14.100.33.2
Keying Module Port: 4500

Additional Information:
Keying Module Name: IKEv1
Authentication Method: Preshared key
Role: Initiator
Impersonation State: Not enabled
Main Mode Filter ID: 69076

Failure Information:
Failure Point: Local computer
Failure Reason: New policy invalidated SAs formed with old policy

State:			Sent third (ID) payload
Initiator Cookie:		3562c9a5fcc0c2c1
Responder Cookie:	3066db39b95299cd

From the application event log:
CoId={07719720-653A-455F-A02A-4977847EC163}: The user jserinki7-Win7\jserinkWin7 dialed a connection named Digitest2 which has failed. The error code returned on failure is 789.

Cheers,
John

8

hi

Normally when i see

IKE Negotiation Failed. Peer: ,Bad Packet

this is down to some password issue when doing normal IPSEC tunnels

regards

James

9

Yes, agree. That is what QN51 shows as well.
I have changed the password for user “*” to “frank”.
Went to my connection profile named Digitest2, properties, Security, Selected L2TP and clicked advanced settings, selected presharedkey and entered “frank”. Just to make sure I went to Administrative tools, windows firewall with advanced security Properties, IPSec settings, IPSec defaults, Authentication method, customize, First Authentication , Preshared key, 'frank".

Same error.
Scratching my head here.

Cheers,
John

10

Hi John
so you have setup 2 users for L2TP
1 “*” which is the pre shared that maps to page 25 to the windows client preshared
2 “remoteuser” this it the user that is used on page 24

the first is used by ike/ipsec to match the second would show as a PPP login error

regards

James

11

Yes, two users.
the user * is the psk, jserink is for the ppp session. But as you can see, ppp never comes up, it never gets that far. the IPSec doesn’t get up so hte L2TP never comes up and the ppp follows that so we’re stuck at the IPsec end of it.

Cheers,
John