ClintD
Posts: 1848
Joined: 26.Jan.2001
From: Keller, TX
Status: offline
|
What I meant in my post above is if the client is behind a NAT device that uses 192.168.1.x for the private side, and ISA uses 192.168.1.x for it's Internal network, then you should expect problems.
This is because the client, prior to connecting has a subnet specific route for 192.168.1.x through it's network adapter. Now, once the client connects with a PPTP/L2TP VPN, it still thinks 192.168.1.x is accessible through the NIC. If the client tries to initiate traffic to the Internal network of ISA, since it has a more specific route for 192.16.1.x through it's NIC,the traffic will not go through the VPN adapter - it will go through the NIC. You can override this behavior by removing the checkbox for "Use Default Gateway on remote network", but this is a security risk.
Before testing the following, ensure ISA Server has been configured with the following.
1. Network Rule - VPN Clients Routes to Internal (this is the default) 2. Firewall Policy Access Rule - Allows PING from VPN Clients to Internal network for All Users. Don't use "Authenticated Users" just yet.
Now once the client connects the VPN, retrieve the IP address the client received for the VPN connection. Once you have it, go into the ISA console and under Monitoring\Logging, add an entry for "Client IP" "Equals" "%VPNClientIPAddress%" and start the query.
Then, go to the client and try to PING a DC/File Server/etc... and see what the ISA log shows for the request.
Does it hit the Default Rule? Does it show a Rule at all for the traffic? If it doesn't, go into the View menu and select Add/Remove Columns. Find the entry for "Result Code" and add it to the right. once it is added in, what is the result code the PING request?
Assuming that you have an access rule in place to allow PING, the Workgroup name has no bearing on connectivity to the Internal network - yes, it affects the view shown in My Network Places, but doesn't affect PING, Remote Desktop, FTP, etc...
I'm not trying to be a jerk, but you guys are posting "symptom" based descriptions of the problem - once you get the hang of the Logging, you can provide specific technical reasons for the failures and we can help a lot more with the failure. The more detials the better - "client receives IP address XXXX for it's VPN connection. This traffic is seen by the ISA Server and is being denied by rule yyy even though I have a Access Policy rule in place named zzz which allows the traffic". Something along those lines... [ July 26, 2005, 04:56 PM: Message edited by: ClintD ]
|