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!
Windows 7 L2TP IPSec NAT-T
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, AssumeUDPEncapsulationCont
Any Idea ?
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, AssumeUDPEncapsulationCont
Any Idea ?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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-window
set ike p2-proposal "nopfs-esp-aes128-sha-wind
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-window
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.
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-window
set ike p2-proposal "nopfs-esp-aes128-sha-wind
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-window
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.
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")
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")
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.
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.
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_cert
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 "Zertifikatsregistrierungs
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/
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_cert
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 "Zertifikatsregistrierungs
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/
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.
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial