I have about 15 WinXP clients in internal network wich use Cisco VPN Client to connect to public server. They worked perfectly before i implemented ISA 2006 NLB. Now, when they try to connect usig Cisco VPN client, they get message "Reason 412: The remote peer is no longer responding.". When i stop ISA NLB they are able to connect. There is rule for them (cisco VPN clients) on ISA with IPSec IKE and IPSec NAT-T client outbound protocol allowed... ISA Server array is between Cisco ASA devices, on internal and external network of ISA Array. I am using NLB Unicast mode.
1. There is no NAT between the VPN client and ISA Array 2. Client machines have ISA client installed OR they should point to ASA and in turn ASA should point to ISA as DG 3. Client should use ISA NLB IP and not ISA nodes IP
A network trace on Client machine and on the ISA server nodes at the same time will give you alot more information. If you want i can help you reading the traces. Let me know
1. u are right about it, but how come they are able to connect without NLB enabled??? 2. they do not have FW client installed, they are not members of domain, ASA is theirs DG and ASA point to ISA Array NLB IP 3. ASA use ISA NLB IP.
One more thing to add, clients are in 172.20.0.1/24 network, and ISA Array is in 192.168.210.1/24 network. Clients are ROUTED to ISA Array. That is how our Cisco Admin has configured network relationship.
Every VLAN in internal network of ISA Array is defined as ISA Array internal network. One thing is unusual, without NLB enabled i can capture traffic from client on port UDP 500 and UDP 4500. But when i enable NLB all i capture, from clients, is traffic using port UDP 4500???
Here is our network topology, maybe this will help:
INTERNET I Outside router I Cisco ASA (192.168.0.1/24) I ISA Array (192.168.100.0/24) I Cisco ASA (192.168.100.1/24) I LAN router* ( 26 VLANs using 172.16.x.x to 172.50.x.x )
If you leave NLB enabled, but shut down one node, does the problem go away?
Can you check the ARP and CAM tables on the ASA's to make sure that it is not getting confused with MAC addresses at Layer 2?
How is the back ASA physically connected to the ISA Servers - via a hub or switch (please be exact)?
When you disable NLB I assume you update the DGs on the ASAs to point to one of the ISA Server dedicated IP addresses, rather than the VIP?
I assume you have enabled NLB on both ISA internal and external interfaces?
Have you considered going to NLB multicast mode? This will probably require the addition of static ARP entries on the ASA's to manually map the VIPs to the NLB virtual MAC, but may be a potential way forward if you want to keep NLB...
< Message edited by Jason Jones -- 22.Apr.2009 6:49:12 AM >
if i stop NLB (only on one member, any member), or stop ms firewall service (only on one member, any member) or shut down one member of array, problem goes away.... Cisco vpn client is only problem with NLB enabled, everything other works perfect!
ASA`s have "learned" MAC`s well, they have ISA VIP MAC address in tables... I have balanced both networks, int and ext, both of them are connected with ASA`s using HUB, each network has own HUB, and nothing else is connected to HUB.
Why do you think multicast mode will help? Please explain....
How come ISA, NLB disabled, (on one member, any member) capture UDP 500 port and UDP 4500 port traffic, and when NLB enabled it capture only UDP 4500 port traffic from cisco vpn clients (when they try to connect)?
I'm not sure if you got it working, but, technically speaking you cannot see UDP 4500 traffic without UDP 500 traffic for your new VPN connections. How did you take the capture ? The VPN client connects to the VPN server on UDP port 500 to begin IKE negotiations. During these, the presence of the NAT device(s) will be detected, and the client will connect(switch) to UDP port 4500 to the VPN server, and the IKE negotations and Cisco's non-RFC compliant extensions will continue. If completed successfully, the IPsec ESP traffic will be also encapsulated within UDP and send to UDP port 4500 of the VPN server.
So you can see the original packets from the client, how the packets leave the first ASA and go to the ISA cluster, and then how they will reach the last ASA after it they passed through an ISA member and vice-versa. And you may be able to pay attention to the MAC addresses too. I'm not saying this is your case(just an example), but sometimes, taking captures can be tricky, because some packets(say maybe some low level packets) will not be supplied to the mechanism used to capture the packets(pcap), so you will not see them in your packet sniffer, or some packets, like TCP ones send by the host, may be displayed with TCP checksum offloading errors, if the TCP checksum will be done in hardware(NIC) when the packet is sent out by the NIC, after the capture mechanism intercepted the packet.