Windows 7 L2TP IPSec NAT-T

tmi_cce
tmi_cce used Ask the Experts™
on
Hello
I've set up a VPN between Windows 7 clients and a Juniper NS5GT Firewall according the Juniper KB articles http://kb.juniper.net/InfoCenter/index?page=content&id=KB10939  and http://kb.juniper.net/InfoCenter/index?page=content&id=KB16075.
With the first Windows 7 client, it work's just fine. With the second and the third clients, it won't work.

The error message while conecting is:
"Error 810: A network connection between your computer and the VPN server was started, but the VPN connection was not completed. This is typically caused by the use of an incorrect or expired certificate for authentication between the client and the server. Please contact your Administrator to ensure that the certificate being used for authentication is valid"

Debugging the vpn on the juniper firewall while connecting, I get the following difference betwen phase 1 and phase 2:

With the client that is ok:
## 2011-05-16 11:18:47 : IKE<138.188.100.248> responder (pki) constructing remote NAT-D
## 2011-05-16 11:18:47 : IKE<138.188.100.248> Construct [NATD]
## 2011-05-16 11:18:47 : IKE<138.188.100.248> responder (pki) constructing local NAT-D
## 2011-05-16 11:18:47 : IKE<138.188.100.248> Construct [NATD]
## 2011-05-16 11:18:47 : IKE<138.188.100.248> Xmit : [KE] [NONCE] [CERT-REQ] [NATD] [NATD]
## 2011-05-16 11:18:47 : IKE<138.188.100.248> Responder sending IPv4 IP 138.188.100.248/port 357
## 2011-05-16 11:18:47 : IKE<138.188.100.248> Send Phase 1 packet (len=278)
## 2011-05-16 11:18:47 : IKE<138.188.100.248> IKE msg done: PKI state<0> IKE state<2/1017200f>
## 2011-05-16 11:18:49 : IKE<0.0.0.0        >   from FLOAT port.
## 2011-05-16 11:18:49 : IKE<138.188.100.248> ike packet, len 1716, action 0## 2011-05-16 11:18:49 : IKE<138.188.100.248> Catcher: received 1688 bytes from socket.
## 2011-05-16 11:18:49 : IKE<138.188.100.248> ****** Recv packet if <untrust> of vsys <Root> ******
## 2011-05-16 11:18:49 : IKE<138.188.100.248> Catcher: get 1688 bytes. src port 63177
## 2011-05-16 11:18:49 : IKE<0.0.0.0        >   ISAKMP msg: len 1684, nxp 5[ID], exch 2[MM], flag 01  E
## 2011-05-16 11:18:49 : IKE<138.188.100.248> gen_skeyid()


With a client that isn't building up the VPN:
## 2011-05-16 11:43:57 : IKE<138.188.100.226> responder (pki) constructing remote NAT-D
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Construct [NATD]
## 2011-05-16 11:43:57 : IKE<138.188.100.226> responder (pki) constructing local NAT-D
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Construct [NATD]
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Xmit : [KE] [NONCE] [CERT-REQ] [NATD] [NATD]
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Responder sending IPv4 IP 138.188.100.226/port 381
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Send Phase 1 packet (len=278)
## 2011-05-16 11:43:57 : IKE<138.188.100.226> IKE msg done: PKI state<0> IKE state<2/1017200f>
## 2011-05-16 11:43:57 : IKE<0.0.0.0        >   from FLOAT port.
## 2011-05-16 11:43:57 : IKE<138.188.100.226> ike packet, len 116, action 0## 2011-05-16 11:43:57 : IKE<138.188.100.226> Catcher: received 88 bytes from socket.
## 2011-05-16 11:43:57 : IKE<138.188.100.226> ****** Recv packet if <untrust> of vsys <Root> ******
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Catcher: get 88 bytes. src port 14989
## 2011-05-16 11:43:57 : IKE<0.0.0.0        >   ISAKMP msg: len 84, nxp 8[HASH], exch 5[INFO], flag 01  E
## 2011-05-16 11:43:57 : IKE<138.188.100.226> Error: Responder expecting non-floated IKE packets in phase 2, drop pak.
According to the sent packet size I'm tempted to say that the second client isn't sending all the things he should, or he is floating to a different port when he shouldn't.

On booth machines, MS kb926179 (How to configure an L2TP/IPsec server behind a NAT-T)  is applied, AssumeUDPEncapsulationContextOnSendRule has value 2.

Any Idea ?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2016

Commented:
I asssume you did this on the non-working machinesOn a Windows XP setup, configuring the firewall to use the "COMPATIBLE" phase 2 proposal (on page 32 of the Application Note) will work fine. However on the Windows 7 and Windows Vista client this will end up with an error and the phase 2 never completes.

To fix this, when you get to page 32 of the Application Note, configure a phase 2 custom proposal on the firewall and apply it to the VPN configuration:

Create two new proposals as follows:
set ike p2-proposal "nopfs-esp-3des-sha-windows7" no-pfs esp 3des sha-1 second 3600 kbyte 250000
set ike p2-proposal "nopfs-esp-aes128-sha-windows7" no-pfs esp aes128 sha-1 second 3600 kbyte 250000
Then change the IPsec config as follows to reference these two p2 proposals (p.33 of the Application Note):
set vpn "WindowsVPN-vpn" gateway "WindowsVPN-gateway" no-replay transport idletime 0 proposal "nopfs-esp-3des-sha-windows7"  "nopfs-esp-3des-md5"  "nopfs-esp-aes128-sha-windows7"  "nopfs-esp-des-md5"
Important note: The LIFE SIZE has to be set for a value 250000; if LIFE SIZE is not set to 250000, it will not work.   All built-in P2 proposals set on the Juniper firewall are set to a LIFE SIZE of 0.
Top Expert 2016
Commented:
you also did all of the certificate stuff on the non working machines?

Author

Commented:
Yes I created and applied the 2 new proposals on the Juniper Firewall like described in http://kb.juniper.net/InfoCenter/index?page=content&id=KB16075 and it worked fine for the first windows 7 client.
I also issued the certificates  and put them in the riight certificate stores, for alle the clients. I checked that the private key of the clients certificate was present.
For one windows 7 client it just works fine ( see Firewall debug "With the client that is ok")
For the two others, it messes up between Phase 1 and 2 ( see Firewall debug "With a client that isn't building up the VPN")

Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Top Expert 2016
Commented:
on the bad machines try a new key (certificate) and do the certificate installation again.

Author

Commented:
I mad it several times.
I have compared the certifcate from the bad machines with that of the good machine. They are of the same type, with the same template, the private key is in the certificate store (local computer) and so on, everything is ok. The Root Certificate (public key) is also on every machine.
I have compared the data in the certificate of the bad machines with the data in the Firewall and they are right.
While buidling up the VPN with the good machine, I can see the Firewall making the match between the certificate of the client and the data stored in the firewall. This happens in Phase 2.
While building up the VPN with the bad machine, the problem appears before Phase 2, see the comparison between the two logs up here. So I don't believe this  is a certificate issue.
At one point with the bad machine, the firewall is expecting a non-floated IKE packets in phase 2. It looks like the bad machine doesnt sent all he the things he should or he is sending it on the wrong port.
Commented:
Ok ve3ofa, you were right about the certificates, I had to do it again, but not the way described by Juniper in hispapers.
The one way is should go, but I'm not certain, is to request the certificate from the certificate snap-in, using the option "Extended way" --> "Create User defined request" (In german "Erweiterte Vorgänge" --> "Benutzerdefinierte Anforderung erstellen" .... With this way you might define a custome certificate request, that you will post at your CA and you can install on your Client.

The sure way I use now, is: on a domain integrated client, start a command console (cmd) as administrator, create a certificate request setup file, then use the command line tool "CERTREQ.EXE" to post the request at the CA, then use "CERTREQ.EXE" again to retrieve the file containing the certificate.
At this point you can import the certificate to your computer certificate store using "CERTREQ.EXE  -accept -machine file_of_the_retrieved_certificate"

Instead,If you need the certificate on an other client, do not import the certifcate on the client doing the request. This would delete the request that belongs to the freshly obtained certifcate and you could not longer import the certificate on an other machine.
So: you can now export the "certificate request" from the machine store (in German "Zertifikatsregistrierungsanforderung") in a password protected .pfx file.

On the other client, you will import in the machine store:
- the public root certificate of your CA in the sore "Trusted CA"
- The request (.pfx file) into the store "Certificate requests"
- The certificate file previously obtained with "CERTREQ.EXE" into the store "Own certificates"
Do not forget: you willl need to import the request and the certificate in your machine certificate store in order that your client recognize this certifcate as his own and uses it in the VPN negotiation!!!

In order to build the certificate request setup file and request the certificate with "CERTREQ.EXE" you can use and adapt the script decribed in http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeVPN/thread/b766632e-2817-41d7-9f08-a56ffc5ba98a/

Author

Commented:
The question was misplaced, it's definitely not a NAT-T problem. it's a certficate problem with windows vista and 7 clients requiring certificates from a windows 2008 (non enterprise) server.
Beside talking of requesting the certifcates again, the expert didn't give any advice on how to do it in this case. That's why a c grade is enough.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial