I currently working with 2 ISA 2006 Std on Win2k3 SP2 servers, both running with about 2+ GHz processors, and 4 Gigs of RAM.
Problem I am having is the following:
Locally - No noticeable 'lag' in processing time for sites using Internet Explorers 6 and 7 for computers in the local LAN environment.
Remotely - Several locations that connect to our LAN via Checkpoint/Cisco VPN tunnels are reporting major slowdowns on internet connections, processing time on either server for those remote users sometimes are in the 3k-45k ms range (IE: 3 to 45 second).
The remote locations are setup with an access rule that is suppose to limit their internet access to a select group of websites if they are not authenticated, a broader set if they do get authenticated. Problem is, even with the limited allow (IE: Anonymous allow) the processing time takes several seconds, sometimes minutes for the user to see the page.
The Remote locations, at best, are DSL connections, if not T1. Our connection is T1 and both ISA servers are Uni-homed, setup with just the specific IP ranges that our network handles as internal.
Any thoughts as to what I should be looking for to explain the high processing times for the remote locations?
One thing also to note, I do have one machine that is using a User ID that the remote locations use that is local to the network and noticing the 'slowness' as well.
Internal DNS (AD DC) 2 external DNS IPs referenced via our ISP.
Looking at the logs, there is no reference of not being able to reference or look up the name. Also, for most of the LAN based computers, the response doesn't seem abnormally slow, mostly the remote locations seem to have it, and seeing one computer logged in using the same GPO as the remote users.
The 64.0 group is the remote locations, as well as 65.0 and 18.0.0 groups The gateway 172.16.0.10 is an internal router where it does have paths set to 64.0, 65.0 and 18.0.0. Our Firewall is at 172.16.1.43, and the router points 64.0 and 65.0 to 1.43 because those 64.0 is Cisco PIX VPN Tunneled to our Checkpoint firewall. 65.0 is DMZed on the Checkpoint Firewall. The ones reporting the issue is on the 64.0 group.
Now a collaborator put in a static route for the 64.0 group to go to the firewall on the box itself, but it doesn't make sense to me why if the default gateway, being a router that will route that traffic to the appropriate direction, would make things seem 'slower'.
It also doesn't explain why, on my one computer within the LAN, not outside of the 172.16.0.0 subnet, would seem 'slow' handling refresh of the same page via the same server.using the same login as the 64.0 subnet group.
Remote location connects to our LAN via a VPN tunnel, using either a Cisco PIX or Ad-Tran Router VPN tunnel to a Checkpoint Firewall.
The ISA server is not functioning as a Firewall in this case, but as a Web Browsing management. Given the Remote Location computers are part of the AD Domain, so they are group policied to use the ISA Server as a proxy.
What I have not seen, given this is not necessarily a 'common' or often use practice with the ISA server, is reference to a situation of the above mention.
A Unihomed ISA server, servicing a local network, and subnets that are outside the local network. In this format, there is an internal Router that directs where traffic should go for certain networks, such as special subnets, majority of it is pointing to the Checkpoint Firewall, as it then redirects to where it should go for VPN tunnels if not to the External network.
What I haven't understood is why an ISA server setup in this way, where the internal network is including the subnets that can be handled by the Internal gateway, require a Route Add to go to the Firewall when it should be handled by the internally defined gateway.
And yes, I saw the article references that the internal gateway should not be defined, however, does this also not mean that you have to have the External Gateway defined and that you are setup in a dual nic design, not a single nic/unihomed design?
Looking at the limitations provided on the link did not seem to be the issue that we seem to be having, however. For instance, we have no intention of doing VPN to this ISA server, so that is a non-issue. Web publishing on it is also a non-issue, as this isn't publishing any servers in our internal network to the rest of the world.
What was perplexing about the issue at hand is that there is no reference in the situation where we have the following:
Obviously, the Gateway has to be defined, so at this time, it is defined to 172.16.0.10.
The problem arises when requests from the 172.16.64.0 group would take a long time to process, like things that would take about 3 or 4 seconds at most, are taking 15 seconds to 2 to 3 minutes at the worse case scenario.
So far, the solution my parent company has employed which seems to work is forcing a 'route add' for 172.16.64.0 mask 255.255.255.0 to point directly to the Firewall that the remote locations are vpn tunneling through, which is 172.16.1.43. What I could not find, however, is why would this route add on the ISA server, even in its not so great configuration, would cause such a heavy delay in proxy traffic to an address where internal network is defined, the internal nic has a gateway to reference it, but still requires a route add to direct the traffic to where it needs to be in a more timely manner.
So, technically, I should not have the subnets in question I am defining as my 'Internal' Network defined beyond just the standard 'All but Local Host'... And when defining the handling of certain ranges, I should be using Computer Sets...
IE: I know my Remote Machines will be at this 172.16.64.x range, if they go to any range outside my 172.16.0.0 mask 255.255.192.0 range, I then check the other conditions... Under networks, Network Rules, do I specify how it routes the information or should it already be handled from how Internal is handled?
From: United Kingdom
Nope, your internal network object should look like the above picture.
If you need to define rules to allow access to and from ISA, you can then use address ranges, subnet or computer sets - just leave the ISA internal network object as per the default single NIC setup.
With a single network card, ISA cannot be a "router" hence will send all traffic to it's default gateway just like any other host...ISA can therefore only control traffic to and from itself and provide proxying for HTTP, HTTPS and FTP over HTTP - it cannot act are a firewall and permit/deny traffic from one interface to another.
< Message edited by Jason Jones -- 26.Aug.2008 6:58:08 PM >
Well, here's the thing. We aren't trying to treat it as a router, we are trying to treat it as a standalone Proxy server. Like I said before, with our normal LAN, the response time between Client computer to the Proxy server is reasonable. However, with the remote locations, where they are at the 172.16.64.x subnet, it is extremely slow. Unless you put in the 'route add' for 172.16.64.x to point to 172.16.1.43, which is our firewall, nothing improves the situation. With the NIC already defined with a 172.16.0.10 default gateway, one would think that this is implicitly implied to have 172.16.0.10 handle where it needs to go either if we have it set the way you stated or just having only the subnets in question defined as the internal addresses.
Also, can you define the traffic flow (e.g. path taken) for me from a remote site user in terms of routers, firewall, ISA etc...
Sorry, missed that Post... Here is how things technically should go for this environment.
Remote Location -> Cisco Pix (At Remote Location) -> Checkpoint Firewall (Local) -> ISA server
ISA server should technically be doing this:
ISA Server -> Internal Router (Determining where to go within the network, through one of the other Routers as we have another T1 to a specific subnet, namely the 172.18.0.0 one, or back to the Firewall for Outside Internet/Remote Location PIX)
So one would think that when a Remote computer does an Internet Explorer Web Browse to the ISA server, it gets funneled via the PIX to Checkpoint via VPN. From there, the Checkpoint FW sends the request to ISA server. The ISA server responds back.
Given 172.16.64.x is not part of the 172.16.0.0 mask 255.255.192.0 network, ISA has to inquire from Internal Router with "Where does this go?" based on the Internal NIC definition on the ISA server's physical nic that it should go to the default Gateway.
What we are seeing, however, is that unless you implicitly tell ISA Server that if there is traffic for 172.16.64.0 mask 255.255.255.0, go directly to Checkpoint Firewall. Otherwise, it seems to take LONGER for it to figure out that it needs to go to Checkpoint Firewall to direct information from ISA back to the Remote computers in question.
The other strange thing I noticed, was when I had a computer that was WITHIN the internal subnet of 172.16.0.0 mask 255.255.192.0, but logged in as one of the remote location's Domain UserID (Their Usernames and passwords are stored on the LAN's DC server), it almost behaved similarly doing 'refresh' of said content from the ISA server. This behavior lead me to believe it was something else, but at the same time, it doesn't explain to my why there was a necessity to tell the ISA server to go 'directly' to the Checkpoint Firewall for the Remote IP addresses when this should be handled by the ISA Server's Internal NIC's Gateway Definition, which points to a router that would also point it to the Checkpoint Firewall as the next logical route.