I'm setting up ISA 2006 to monitor but not block internet access. We will let people do what they will do, but have recording and reporting.
I'm trying to think of ways users will either inadvertently or purposely bypass the ISA so they can surf on the local network without any accountability.
One way I can see is to change their gateway settings to bypass the ISA server.
Other ways are to use some kind of SSL connection external proxy anonymizing service as well as use virtual machines and other computers that are not managed by group policy to do shady web surfing.
We have managed domain-joined Windows computers along with non-managed hardware from vendors and other business partners with their company's laptops that are not joined to our domain, smartphones on wifi, non-Windows computers like Linux workstations as well as employees with virtual machines on their company workstation (that are intended for software testing purposed) that they have configured with access to the LAN and internet.
I plan to use the ISA 2006 Firewall Client for our domain-joined company-owned workstations and laptops.
That leaves maybe 1/3 of computers plus other devices that cannot have the firewall client installed for various reasons. So, we will use SecureNat for the rest so there won't be any need to configure proxy settings in browsers or do anything else to the other devices. We should still be able to run reports and manually look up the host name of the IP address of any problem devices that do not have the client installed and therefore will not list user or computer names in the ISA monitoring reports.
In a test lab I have got this to work by setting up a simple 1 NIC ISA 2006 server with the client's gateway set to the IP address of the ISA server. I did this manually, but I suppose we could change DHCP to do this when it goes to production users.
However, this setup would not stop anyone from manually changing their gateway to point directly to the regular gateway to bypass ISA. Plus there will be computers that are on static IPs that will not get their gateway settings updated to point to the ISA since the owner of the device has no motivation to make this change.
Is there a way to place the ISA server in a position on the network so either the existing gateway IP address works but routes through ISA or else set the current gateway to not allow any traffic to go through it unless it is coming from the ISA server? In that case the users will not have access to the internet unless their connection goes through ISA. Problem I see with this is that everyone loses web access every time the ISA server is restarted or if it had a serious malfunction and needed to be rebuilt.
If a user is surfing the net through a virtual machine installed on their PC will the traffic still show in ISA monitoring reports with the IP address of the host machine as opposed to the IP address of the VM's virtual nic which may or may not get it's IP address from our DHCP or register in DNS depending on how the user sets it up?
Can anything be done to report on SSL proxies used to obfuscate their web usage? We do not want to block anything. If users do what they are not supposed to do, it will be dealt with in other ways afterwards. It is more important that things that should not be blocked don't get blocked in error.
Thank you for the post.
“In a test lab I have got this to work by setting up a simple 1 NIC ISA 2006 server with the client's gateway set to the IP address of the ISA server.” – in a single NIC mode, you can only configure all the clients as web proxy client.
“Is there a way to place the ISA server in a position on the network so either the existing gateway IP address works but routes through ISA or else set the current gateway to not allow any traffic to go through it unless it is coming from the ISA server? ” – yes, you can place ISA server on the edge network to control all the outbound traffic. And configure NLB to provide high availability and scalability of ISA servers: http://technet.microsoft.com/en-us/library/bb794741.aspx
Nick Gu - MSFT
- Marked as answer by MyGposts Thursday, November 29, 2012 2:57 AM