Don't know how much detail you wanted to go into for the Cisco VPN Client failing over TCP, but in case any one cares, here is the reason.
The Cisco VPN Client initiates a TCP Handshake to the external VPN Concentrator (or whatever other device suppports NAT Transparency over TCP) but does not specify the Maximum Segemnt Size option. This packet passes through ISA, but ISA, as Stefaan mentions, strips off the original TCP Header, and inserts it own, but does specify the MSS as 1460.
When the VPN Concentrator replies, it does not reply with the MSS option set. By RFC when a client sends a MSS Request and the remote system does not reply with an MSS option, the system must assume an MSS of 536.
This is exactly what is seen in a network capture of the client connecting. It sends a (for example) packet with 750 bytes of data - it reaches ISA and this is divided into 2 TCP Segments - 1 with 536 bytes, and the other with 214 bytes. The VPN Concentrator does not support this an apparently silently discards the packets.
Just for clarification, it is not an ISA problem (as the Cisco documentation mentions) - it is a problem with how the VPN Concentrator handles MSS "negotiation". I hate using the term "negotiation" for this as it isn't really a negotiation, but it gets the point across.
Will it work with a lan to lan solution: isa-cisco via ipsec? We're trying to set this up, but so far wityhout any luck. If we disable isa it works ok.
Thanks for the great documentation. I just had a request to setup a Cisco VPN Client. Followed your instructions and was able to connect on the first try... Now, I can not access anything on their network. I noticed in the IPFilter logs that UDP 137 is being filter on there internal IP for their DNS. Why is that happening?
the article is about IPSec passthrough. However, your question seems to be about using ISA as a VPN endpoint. If that's the case, I suggest you start a new topic in the VPN forum.
if you see in the ISA logs traffic for the destinations reachable through the VPN tunnel, then that traffic is not going through the VPN tunnel. That means that either there is a configuration problem with the VPN or the traffic is redirected by the firewall client.
In the first case check out with the VPN administrator that transparent tunneling is enabled. In the second case, disable the firewall client or fix your LAT configuration, either globally on ISA or local on the host with the VPN client.
Stefaan - I thought that was the issue. I don't have the firewall installed, so I am setup as SecureNAT. How do I fix the LAT? Do I remove the 10.1.X.X from the ISA LAT? I tried that and it didn't do anything. I will check with the VPN folks at the company if I can track them down... Any other thoughts?
how is the LAT configured? Keep in mind that the LAT should only contain the IP addresses used on your internal network. However, if you start playing with VPN, you need to fine tune the LAT further.
If you construct a gateway-to-gateway VPN solution with ISA as your VPN gateway, than the networks reachable through the VPN tunnel *must* be included in the LAT on ISA (globally). The reason is that by creating a gateway-to-gateway VPN configuration you are effectively joining the networks behind the VPN gateways together in one big routed network.
Now, in your situation we are talking about passing a VPN through ISA server in a client-to-gateway VPN scenario. In this case only the VPN client will become a member of the remote network behind the VPN gateway, not your whole internal network. Therefore, if you want to use the Firewall client at the same time as the VPN client, you must tell this particular Firewall client not to redirect the traffic for the remote network behind the VPN gateway to the ISA Firewall service. Otherwise, the VPN client will never see that traffic as explained in my article. The only way you can do this is by adding the network reachable through the VPN tunnel to the LAT, either globally on ISA server or locally on the client (locallat.txt file). The latter being my preferred method.
Another point to keep in mind is a possible IP address conflict as indicated in my article too. Check out that the network reachable through the VPN tunnel *and* the IP address assigned to your VPN client during the VPN tunnel negotiation is *not* used on your internal network.
I have two clients that are using VPN's that I previously was unable to get to work. After following everything in the articles, I was able to get the Cisco VPN client to work flawlessly. The one I am now having issues with is the Nortel Networks Contivity Client. It always fails on some banner thing. It works flawlessly through an old Linksys gateway/router. Any ideas? I don't control the VPN server, so I can only modify the ISA server and the client.
As indicated in my article, the Nortel Contivity VPN client can pass through ISA server successfully if it has the right firmware version and the VPN gateway is properly configured. So, you will have to contact the administrator of the VPN gateway to check out the version he is running and if the NAT Traversal feature is enabled. Without his help it simply won't work.
I have a situation. Our users use the Nortel Contivity VPN client to connect to the goverment site. Now, the government site requires us to use one-to-one NAT for each PC in order to connect. Anyone know how to configure this in ISA or Windows 2000?
I tried to setup ISA to passthrough the SonicWall VPN client. The authentication part went well. I can see on the Sonicwall an connected tunnel but i'm unable to send or receive data through the tunnel. (Terminalserver Session or something else)
I never worked with the SonicWall VPN client, so I have no first hand experience with it.
The first thing you should be sure of is that the NAT Traversal is indeed negotiated. Check out the ISA IP packet and Firewall log. You should only find communications on UDP port 500 and/or 4500. If you see blocked packets on IP protocol 50/51 then NAT Traversal is definitely not used. Also, check out the logging on the VPN client. I believe most vendors will log that information too.
Keep in mind that both the VPN client and the VPN gateway *must* support NAT-T and that it is very likely it must be enabled explicitely on the gateway. So, you need to check that out with the VPN administrator.
Is the Firewall client installed too? If that's the case, test first with the Firewall client disabled. Once that's working you can fine tune the Firewall client configuration.
RE: How to pass IPSec traffic through ISA Server - 7.May2003 8:48:00 PM
Guest
Thank you for a great article! I have a question reguarding the Checkpoint Securemote client. I am running 4.1SP5 and your doc states that this will work with NG. Is there a specific reasion why I need that version or is it the UDP header size issue with CKP? I need to know to determine if I should keep working on the ISA or move to looking at the SR client. BTW upgrading to NG is not trivial and I'd like to avoid it if I can.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2000 Firewall] >> VPN >> How to pass IPSec traffic through ISA Server 
How to pass IPSec traffic through ISA Server - 
RE: How to pass IPSec traffic through ISA Server - 
![[Smile]](/image/smiles/smile.gif)
![[Wink]](/image/smiles/wink.gif)
![[Big Grin]](/image/smiles/biggrin.gif)
![[Cool]](/image/smiles/cool.gif)
RE: How to pass IPSec traffic through ISA Server - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread