Hi This gives me nightmares A sbs2003premium network with isa 2004, 4 clients. 2 of that 4 clients has to make a vpn connection to another network to get some business info. They have to use the cisco client. So i started playing with isa, everytime they get disconnected after 10-15 minutes, nomather what i do... Rules:Allow all to "ip of that vpn connection" from "internal" to "external" for all users
then: Allow ike client, ipsec ESP, IPSEC NAT-T, port 10000 udp send and receive, port 4500 udp send and receive.
But still they get disconnected.
What i think is that they don't have Nat traversal enabled on their vpn servers. But can't find that out, that company just don't want to give support, unless for 25 €/hour and just want to sell their site to site vpn solution. But that's not an option for my client.
This is what the cisco client gives me: 13 14:28:23.305 01/23/06 Sev=Warning/3 IKE/0xE3000065 Could not find an IKE SA for 192.168.16.9. KEY_REQ aborted.14 14:28:23.305 01/23/06 Sev=Warning/2 IKE/0xE3000099 Failed to initiate P2 rekey: Error dectected (Initiate:176)15 14:28:23.305 01/23/06 Sev=Warning/2 IKE/0xE3000099 Unable to initiate QM (IKE_MAIN:458) Maybe somebody has experience with it?
you said that they get connected. Does that mean that the Main and Quick mode SA's are correctly setted up, check out the Cisco client log and status for that, and that they can effectively work for about a 10 minutes?
If that's the case, it could not be a NAT-T problem because the Main and Quick mode SA's wouldn't be established in the first place. With NAT-T you should see communications on UDP port 4500 or whatever UDP port the Cisco NAT-T is using. Also, every 20 seconds you should see a NAT-keepalive packet from the client to the VPN server.
for the full security considerations in using NAT-T, check out http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt , section '8. Security Considerations'. The major difference is of course that you can't use IP addresses for authentication purpose because NAT always breaks that. Personally I don't find this a real problem because authentication on the basis of IP addresses is a bad security practice in any case!
Now, you said "Otherwise it's my word against his... ". I don't understand that! Whether NAT-T is negotiated are not and if the VPN connection is effectively established, you can see that in the Cisco logging and the status screen at the client! So it sounds you never checked that out!