Last week I said that 3 out of 5 cases where user says it is an ISA issue it ends up not being. Today I worked in another case that goes to that statistic. What makes me sad about this is the mindset that many Windows Admins, Network Administrators and users in general have when deal with an issue where ISA is in the middle. Sometimes they don’t even stress the troubleshooting because of the wrong thinking that: if works internally and doesn’t work externally, then of course is ISA blocking. No it is not like that.
Use your troubleshooting skills to narrow down the issue, research, try to repro, do above and beyond on the subject that you excel. If after all that you have enough technical argument to say it is an ISA issue, than it is fine. But point to ISA just because it is the device in the middle it is just a bad habit.
The issue in this case was that Windows Vista clients were unable to access resources through a VPN and the VPN Server was an ISA Server 2006. First point of argument in this case was: in the past (with Windows XP) the VPN Clients used to receive the IP address of the default gateway, now with Vista it appears as 0.0.0.0. Well, that’s not ISA and this is explained in here:
Second point of argument was: I correctly connect to my VPN Server, authenticate just fine but can’t access resources internally by name. If ISA Server rules are configured correctly, allowing the traffic (which in this case it was) then issue needs to be investigated in the client side. Guess what? It was a known issue with Vista and here it is how to resolve:
I’m sure this won’t be the last case where Admins point fingers to ISA, but at least is one more that I’m glad to document here and share with you guys.