Hello all, Testing MS ISA Server for potential use. I have the server setup: Standard Edition, Integrated Mode and have a few test clients pointed to the ISA server. The SecureNAT clients have outbound web access and MSN, AIM working. However, I am trying to get the Cisco VPN Client--> through ISA---> to remote Cisco PIX working. I have tried to do the following: Create Packet filter rules Send/Rcv on ports UDP 10000, UDP 500, TCP 10000. That did not work. Second tried to create a custom Protocol Definition with the same ports. It still does not work.
1. Create two protocol definitions: - UDP Port 500 Send Receive : this is for the IKE protocol (key negotiation). - UDP Port XXXX Send Receive : this is for the UDP encapsulated ESP packets. The administrator of the VPN gateway should be able to tell you the exact portnumber to use.
2. Next, create a protocol rule who allows those two created protocols.
3. One thing you must keep in mind is that the client must be a SecureNAT client and that the firewall client must be disabled when setting up the VPN connection. Also, when certificates are involved disable filtering of IP fragments on ISA.
Keep in mind that the IPSec implementation *must* support the NAT Traversal feature or sometimes called the UDP encapsulated ESP. It's some time ago I've checked it for the Cisco PIX, but at that time the PIX did *not* support the NAT Traversal feature.
Hi All, I've tried ALOOOOOOOOOOOOOOOt to make cisco vpn client work behind ISA.I tried various scenerios as mentioned below BUT.. it didn't worked. I tried same settings with Winroute it wors excellent. IF ANYONE MAKE CISCO VPN CLIENT 3.6.1 WORK BEHIND ISA THEN PL TELL ME SO THAT I CAN IMPLEMENT THE SAME AS I DO NOT WANT TO GO FOR WINROUTE. SCENERIOS I TESTED:-
1. I disabled transparent tunneling on Cisco VPN Client & using SecureNAT client of ISA server (As ISA’s Web proxy & Firewall client are not supported for VPN access) w/o configuring any extra protocol definitions (Used default protocol definitions) on ISA server, tried to access VPN server but I received message “ Remote Peer not responding” (Packet filtering was disabled on ISA server in this scenario).
2. Then I configured AH (51 outbound), ESP (50 outbound), IKE (UDP 500 send & receive) Protocol definitions on ISA server and disabled transparent tunneling on Cisco VPN client & then tried to access VPN server but received the same message “ Remote Peer not responding” (Packet filtering was disabled on ISA server in this scenario).
3. Then I configured the port address 48981 (UDP Send & Receive), mentioned by you on ISA server keeping all the protocol definition created above (ESP, AH, IKE) & enabled transparent tunneling on Cisco VPN client and selected “Allow IPSEC over UDP” option and tried to access VPN server but received the same message “Remote Peer not responding” (Packet filtering was disabled on ISA server in this scenario). I also opened all ports and tried the same but the same result.
4. I then enabled Packet filtering on ISA server and enabled all the ports (ANY ANY) and tried to access VPN server but received the same message “Remote Peer not responding”.
5. I then configured “Allow VPN client connections” (Basically required if ISA server is acting as a VPN server) on ISA server & tested the connectivity but recd the same message “Remote peer not responding”.
6. I then enabled “Routing & Remote access service” on Windows 2000 advanced server & enabled IP routing on ISA server & tested the connectivity but recd the same message “Remote peer not responding” .
7. I’ve also tried different combinations mentioned in above steps but could not get success.
In the scenarios 3 and onwards, mentioned above I’ve used Protocol analyzers while connecting to VPN server and could see that CISCO VPN client is sending packets to VPN server (188.8.131.52) but is not receiving the response from VPN server (when CISCO client is behind ISA server). I feel that ISA server is corrupting the IPSEC packets due to which your VPN server is not responding to the packets received.
Though ISA’s Firewall client is not supported for VPN access I still tested it but could not get success.
Stefaan pointed out the link. Did you do what this fellow did?
========================= Win2k Senior Member Member # 4291
Member Rated: posted November 28, 2002 05:49 PM -------------------------------------------------------------------------------- I use my cisco VPN client daily from behind my ISA server and have tested it with both SecureNat and Proxy clients. Here is how I have it set. Port 10000 TCP Outbound Port 10000 UDP Send Port 500 UDP Send and thats it. Some times I have to try to connect two times but it always works. ===================================
Hello all, Thanks for the posts. I did what Tom S. suggested and I got it to connect. So, I have it working at least the way it does with my not so good Intel Lan Rover VPN pLus. Which is it connects but has issues. On the Cisco VPN Client 3.6.2, with "Enable tranparent tunneling and allow udp transparency" checked, it still says "transparent tunneling: inactive" when I right click (status) the vpn client after establishing tunnel. I think the PIX on the remote side may not be setup to allow NAT-Transparency?
a lot of people have the Cisco VPN client working from behind ISA. If you have followed the configuration steps as outlined in my previous post, it should work *unless* the Cisco VPN gateway on the remote site is NOT properly configured!
Check out the IP packet log. If you see dropped incoming UDP packets on destination port 500, then the Cisco VPN gateway on the remote site is definitely not configured for NAT Traversal.
From: Auburn, AL USA
The question I have is which method are you connecting successfully? We can connect using the UDP settings, but can not with the TCP settings and the port set to 10000. We have the rules applied as specifed in this thread.
what protocols/ports must be opened for the Cisco VPN client is depending on the version and the configuration. It might be that the VPN administrator had shipped you a customized and predefined configuration. In that case he should be able to tell you exactly what protocol/ports must be allowed.
As far as I know, the *default* configuration for the NAT Traversal, or Transparent Tunneling in Cisco terms, is the use of 'IPSec over UDP'. For the older versions the protocols UDP port 500 and 10000 send/receive must be allowed. For the latest version the IETF defined protocols UDP port 500 and 4500 send/receive must be allowed.
BTW --- don't forget that the client must be configured as SecureNAT client and if the Firewall client is installed, it must be disabled. If certificates or involved, it might be necessary to disable the filtering of IP fragments on the ISA server.
From: Auburn, AL USA
The sight we are now attempting to connection to REQUIRES the TCP connection, and is using the default 10000 for the TCP port. We have proven that the UDP connections work, but the remote site will not open the ports required for the UDP connections to work so it is out. We do see the TCP handshake in then network trace, but the client reports a "unknown TCP control packet" when behind ISA.
I have discovered the issue with the firewall client and this box does not have the client installed. Has anyone gotten the TCP connection to work through ISA?
One thing I thought of was it might have something to do with blocking of ICMP. If the packet needs to be fragmented, does ISA pass the ICMP packet back to the client? I tried adjusting the MTU on the client station, but still got the same results. I have been talking to Cisco Tac and they are claiming this is an ISA issue, but don't seem to be too interested in pursuing it.
a self respecting VPN administrator should follow the IETF standards and *not* an unstandard implementation from a specific vendor!
I know that according to the Cisco documentation there should be a possibility to tunnel IPSec through a TCP connection. However, I have never seen here a post of someone who has been able to do that. I you badly need to get it working, I suggest you put a network monitor on the workstation (check out http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=14;t=000062 for a very good and free one), place the workstion outside of ISA and give it a try. With the help of the network monitor trace you should be able to figure out how the TCP encapsulation really works and which protocols and ports numbers it uses.
With that knowledge, you can then define the necessary protocol definitions and protocol rule on ISA server. Don't forget to analyze the ISA logs when something isn't working as expected. They are your primary resource for debugging.
We are having the same problem as Mathew. The host provider is requesting that we use TCP for our Transparent Tunneling. We are using Version 3.6.3(A) of the VPN Client and if you open up the property screen you get the following options.
Enable Transparent Tunneling Allow IPSec over UDP (NAT/PAT) -or- Allow IPSec over TCP (NAT/PAT/Firewall) TCP Port xxxxxx (we have '10000')
If we select the TCP option, the VPN Logger shows the error message:
'Unexpected TCP Control packet received from xxx.xxx.xxx.xxx, src port 10000 dst port 1161, flags 10h'
It does not appear that the ISA server is blocking any packets. The host provider doesn't have an answer either and is opening up an error request with Cisco.
From: Auburn, AL USA
It sounds like we are duplicating a lot of work. Our firewall is not blocking any packets (according to the logs) and a netmon trace seems to indicate that as well. I did get a response from Cisco. They send me a link to a readme file that says: ˘IPSec over TCP encapsulates both the IKE and IPSec protocols within a TCP packet, and enables secure tunneling through both NAT and PAT devices and firewalls. This feature does not work with proxy-based firewalls."
So it looks like this will not work. As far as why we need this, it is a customer demand. They are the ones insisting that we use this because everyone else does, and that's just the way their policies are written. Not a great reason, but not much I can do about it either.
I would really like to know what exactly is broken in this transaction, especially since other PAT/NAT devices don't seem to have any issues; I don't know why a proxy based firewall would introduce problems. I may actually call MS support on this as well and see if we can get to the bottom of this.
so you only need one single TCP connection for the whole VPN stuff? In theory that should be quit simple to get through ISA, unless it uses some weird TCP stuff!
First of all, if the TCP connection is not on port 80, then it should not going through the web proxy service. So, it is the Firewall service on ISA which will handle it.
I suggest you try the following: 1) make sure the client is configured as SecureNAT client and that the Firewall client is disabled if installed. 2) try a Telnet IP-address_VPNgateway 10000. The connection should succeed. 3) disable in the IP packet filter properties IP fragment and IP options filtering.
BTW --- have somebody already tried the TCP encapulating outside of ISA and have taken a network monitor trace of the VPN setup to verify that it really works?
Well I finally had a chance to do some testing on this workstation. I placed the workstation in front of the ISA Server and I had no problem operating the VPN connection using either the IPSec over UDP protocol or using the IPSec over TCP protocol using port 10000. I didn't even have to inform the administrator of the VPN so the auto negotiate must be working okay.
But when I operate the VPN through the ISA Server, I can't get it to work at all. If I use the IPSec over UDP, I can attach and login to it okay but then I can't communicate with anything on the other network. If I use the IPSec over TCP Port 10000, I can't even get the login screen to appear. I get the same messages as before where the VPN log shows the messages "Unexpected TCP control packet received..." and "Exceeded 3 IKE SA negotiation retransmits..." and "GI VPN start callback failed 'CM_PEER_NOT_RESPONDING'".
I have followed all of the suggestions listed in this and other threads. Unless I am not sure what Stefaan is saying in his 2nd suggestion above. I assumed he is saying to use TCP Port 10000. If there is more to that comment, please explain.
I think the version (ver 3.6.3) of the VPN Client I am using is a new one, since most of you haven't seen the TCP option on the Transparent Tunneling screen. What is the version number of the Client that has been known to work. I will happily digress to a previous version if I can get this thing to work.
how have you verified that the UDP and TCP encapsulation works outside of ISA server? Did you take a network monitor trace?
I'm definitely sure the UDP encapsulation works from behind ISA server. So, check out your configuration and the firewall log for this one.
For the TCP encapsulation you should first test your outbound access rule with the command Telnet IP-address_VPNgateway 10000. The connection should succeed. Then, try a VPN connection and see if it works. If not, take a network monitor trace at the client and the ISA external interface. Then the real interesting work starts. Analyse those traces in detail and compare them with the reference trace taken from a VPN session outside of ISA with the TCP encapsulation enforced. With some luck you might find something useful that explains why it isn't working through ISA.
The way I verified that the VPN connection was working correctly was to change all the settings to allow the workstation to operate directly off of the router in front of the ISA Server. When I did this, I could connect to the VPN using either the UDP or the TCP encapsulation. I knew it was working correctly because I could login and use the application without getting any errors. Then when I would make the few changes to allow the workstation to operate through the ISA Server, I was getting the errors as I described in my other post. I know I was communicating throught the ISA because I could do normal browsing on the Internet.
I just thought that there might be an older version of the VPN Client that was working, because it sounded like the TCP option was new as no one had heard of it. I may try to get ahold of the last version and give that a try.
I haven't done any of the other suggestions you have given, but I plan to and I will let you know if it works out.
It's not because it was configured for UDP or TCP encapsulation that the VPN test outside of ISA was really working through the UDP or TCP encapsulation method. You should verify that with a network monitor trace. It is very likely that the VPN client and gateway are trying to determine first if a NAT device is in the path. If a NAT device is detected, then the encapsulation method is negotiated. So, I'm not sure you can enforce the use of an encapsulation method in the configuration of the VPN client and/or gateway.
From: Auburn, AL USA
After significant testing, the TCP option does NOT work behind ISA. I have a current Microsoft case open with this, as well as a Cisco case. Cisco says that client will not allow for window negotiation. It seems that when ISA is attempting to renegotiate the window size during the connection and it is causing the client to abort the connection attempt. I will post if we find a work around.