[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 747
  • Last Modified:

ISA Server 2004

I have a client who is running sbs 2003 with Isa server 2004 installed on both the server & clients. Now one of the users is having an issue with the HMRC 2010 cd. Basically she is trying to view a p11 summary which is online but every time the application tries to view the p11 thru internet explorer i am getting a network access message. To me it would appear that the server is refusing to allow access. All clients have no issues accessing any websites & i am pretty sure there are no internet filter rules created.

Now i spoke with the hmrc helpdesk & they mentioned that the application uses port 443 (https)

Do you think the error is related to Isa blocking access?
ISA-Error.jpg
0
Daniel Bertolone
Asked:
Daniel Bertolone
  • 15
  • 11
  • 6
  • +3
1 Solution
 
Mohamed KhairyEnterprise Solutions ArchitectCommented:
What do you mean by " ISA Server installed on both server and clients "?!!!

Also, let me know the source of this screenshot? is it from client computer or the ISA server itself?

Finally, it will be much better if you can attach a screenshot for the ISA Server rules to check it.
0
 
Daniel BertoloneAuthor Commented:
ISA sever us installed on the sbs server & the clients have the ISA client utility.

The screenshot is from the affected client,

Will get a screen of the ISA rules
0
 
Daniel BertoloneAuthor Commented:
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Daniel BertoloneAuthor Commented:
0
 
Mohamed KhairyEnterprise Solutions ArchitectCommented:
What I understand now from your comments and question is that you have the mentioned program installed on the same server and all users connected to it without any problems except this computer where you took the screen shot. right or not ?

If I am right? so why you are using the IP: 127.0.0.1 to connect to the application which is installed on onther serve?? You should use the server hostname or its IP instead.

127.0.0.1 is the standard IP address used for a loopback network connection. This means that if you try to connect to 127.0.0.1, you are immediately looped back to your own machine and that will work if the application is installed on the user computer not on another server. 127.0.0.1 is also referred to as “localhost”, meaning ‘this computer’.

So now try to open the application using the server IP instead of 127.0.0.1 and feed me back by the result and attach a screen shot if you got an error.

0
 
Daniel BertoloneAuthor Commented:
Thanks for the detailed reply.

The application is installed only on the user’s pc not the server. It’s an hmrc tax cd from the government which runs fine until the point it looks to accessing internet explorer & then throws up the error message
0
 
Mohamed KhairyEnterprise Solutions ArchitectCommented:
Ok. Can you try to put the computer IP instead of 127.0.0.1 and try again?
0
 
Daniel BertoloneAuthor Commented:
how would i do that as the applicatyion does not allow you to specify an ip address. Are you talking about the nic card config?
0
 
Mohamed KhairyEnterprise Solutions ArchitectCommented:
Look, open the application in the same way and then the internet explorer open with the address as showed on your screen shot.

Now modify the url in the internet explorer by replacing 127.0.0.1 by the computer IP and try again then let me know the result
0
 
Daniel BertoloneAuthor Commented:
i see, will let you know
0
 
dan_blagutCommented:
Hello

Did you tryed to enable bypas proxy for local adresses in the IE options?

Dan
0
 
Daniel BertoloneAuthor Commented:
Hi Dan

Are you talking about internet options on the client? I can confirm on the server that bypass for local address is checked but i am not sure regarding the client. I am due to visit on Tuesday so i will let you know.

One thing the client did mention was that the laptop is currently connected to a docking station. If she removes the laptop from the docking station then she no longer has the issue?
0
 
dan_blagutCommented:
The option is for the client config. If it works you should propagate for all clients (anyway you can do) using GPO.
If the client remove the laptop from docking station it hasn't a network connection, so ISA server can't deny the request. But is not shure that will work (can do an page unavailable, because the proxy is not available)

Dan
0
 
Daniel BertoloneAuthor Commented:
I replaced the ip 127.0.0.1 with the local ip of the machine but now i get a time out message.

As mentioned before as soon as i remove the laptop from the docking station then the user has no issues accessing the page.

Any ideas what i can try next?
0
 
sabkCommented:
replace the IP with localhost nd then check or Add "127.0.0.1" to the "Intranet Zone" (not Internet Zone) in the IE
Security Zones

0
 
Daniel BertoloneAuthor Commented:
I replaced the IP with localhost & it worked first time. I then added 127.0.0.1 to the local Intranet zone & restarted ie but i get the same error message. Will i be able to get this to work without entering localhost every time?
0
 
pwindellCommented:
The problem was never the ISA!!!!

The problem is IE.  When IE has "proxy settings" it does not properly handle URLs when the IP# is used.  When an IP# is used it improperly sends the request to the proxy listed in the proxy settings.

This is a Local Application,...it isn't supposed to "go" anywhere,...however because it was using 127.0.0.1 (which is an IP#) IE was trying to go through the ISA when it was never supposed to.

Replacing the IP# with the name LocalHost is the correct thing to do.  That remove the IP from the URL and it then works correctly.

This problem with IE is eliminated when you use WPAD Proxy Autodetection and have the Firewall Client installed on the Clients.

Most of the general public has no idea about this flaw in IE because most of the people use NAT based Firewalls that do not have "proxy settings" in the browsers
0
 
Keith AlabasterCommented:
I'll pick this up when I get home from work

Keith
0
 
pwindellCommented:
Sorry, didn't mean to imply shouting.  Just wanted it to be noticed,...that particular issue has haunted IE for a long time and not many people know about it,...that's all.

Thanks for removing the bold formating if you think if was a problem.

Phil
0
 
Keith AlabasterCommented:
Couldn't check this properly before as I hate EE attachments when on my iPhone.

Having reviewed the screenshots, MKhairy had this right very early on and all subsequent comnments have re-inforced the initial diagnosis. To all intents and purposes, to a machine that has the ISA firewall client installed, the address of 127.0.0.1 actually represents the ISA Server rather than the local machine although this can be circumvented (generally) if the web proxy settings in the client browser are empty. The same fault can be found with some of the HP Printer tools that also call http://127.0.0.1/blah/blah/blah. Phil's point is well made about the issue being well known.....

This is actually covered - to a degree - in the bowels of the ISA 2004 administrators guide. As he was a major contributor to the manual, Phil can confirm/deny whether it was also in the ISA 2000 admin guide.

I assume you are actually using the fwc in the true sense rather than having deployed it simply because it came on the CD?
0
 
pwindellCommented:
I don't remember if it was in the guide but I did find it other places about a year of so ago.  IE has this same problem no matter what brand of proxy is being used,..it just come down to whether or not it has "proxy settings" entered into or not.  IE's logic is that if the URL has "dots" between the "//" and the first "/" then it makes the assumption that the URL contains a FQDN and then it also assumes the FQDN is on the internet and not on the LAN,...hence it blindly sends it to the proxy.  There are three workarounds:

1. Use a single-label Netbios Name of the target server in the URL (like LocalHost instead of 127.0.0.1)

2. If continuing to use an IP#, then add the IP# to the Local Intranet Zone in the browser.

3. Use proxy auto detection by entering the script URL in the IE Proxy Settings (http://<servername>:8080/array.dll?Get.Routing.Script). Using WPAD is the best way, but can be added manually if not using WPAD.  This is also more dependable if the Firewall Client is installed as well.  A good well rounded config of using Auto-detection via WAD along with having the Firewall Client installed is the best.  The Firewall Client also uses the auto-detection.

 A sample code block showing the logic IE uses can be found here:

See Example #9
http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part6/c26ie6rk.mspx

Here as a KB article explaining more about it:

Intranet site is identified as an Internet site when you use an FQDN or an IP address
http://support.microsoft.com/default.aspx?scid=kb;en-us;303650

...and then here is some other reading if the link is still good (it's kinda old)

Local Intranet Zone and Proxies: The Surprising Connection
http://msdn2.microsoft.com/en-us/library/bb250483.aspx
0
 
pwindellCommented:
Sorry for all the typos,...but you all should be able to understand what I meant.
0
 
Keith AlabasterCommented:
Agreed. Although I prefer a proxy.pac file but in essence the same thing. Will wait for a response from the asker.
0
 
pwindellCommented:
BTW -  enabling the "bypass proxy for local address" is not one of the workarounds.  The reason being is that IE is not seeing this as an IP# and is not treating it like an IP#,...it is interpreting 127.0.0.1 to be a FQDN because it sees the "dots",...and hence passes it to the proxy listed in it's proxy settings.    After that the proxy is just simply "doing what it is told" and 127.0.0.1 become the local proxy machine itself,...which fails.

However the fact that this is 127.0.0.1 is only part of the problem,...this would still have the same problem with any IP#  that was used,...IE will always interpret it as a FQDN and pass it to the proxy,...and it will fail with most proxys because the proxy would see the address as being a LAT Address and drop it.
0
 
Keith AlabasterCommented:
lol - I think Dan gets the message Phil :)
0
 
pwindellCommented:
Just trying to be through :-)   Half the time I'm not even looking at who posted what specifically,...just trying to cover all the bases.
0
 
Daniel BertoloneAuthor Commented:
Thanks for all your informative reply s guys, so glad i found this place!!

I will have a proper read through later & get back to you

0
 
Keith AlabasterCommented:
Welcome :)
0
 
Daniel BertoloneAuthor Commented:
Thanks again for the reply’s guys!

Now from reading the above it seems I have two choices, either enter the ip# in local intranet settings or use a proxy auto detection script.

Now if I use ip# in local intranet settings I am assuming I enter the ip address as follows: 127.0.0.1# as I tried last time but without the # & it did not work.

If using the script do I enter  (http://<servername>:8080/array.dll?Get.Routing.Script) in proxy settings - advanced - exceptions
0
 
pwindellCommented:
Enter it into the Local Intranet Zone  exactly as it would appear in the URL up to the first "/"
(http://127.0.0.1)
0
 
Daniel BertoloneAuthor Commented:
I entered "http://127.0.0.1" last time & it had no effect however you mention to enter up to the first "/" which from my screenshot would include “http://127.0.0.1:46721"
0
 
pwindellCommented:
Yes,..then enter http://127.0.0.1:46721
0
 
Keith AlabasterCommented:
Exiting question

Keith
0
 
Daniel BertoloneAuthor Commented:
I tried adding http://127.0.0.1:46721 in the local Intranet settings but for some reason when I apply the list of allowed sites only shows http://127.0.0.1

With the URL added i still get the same error message, only local host has worked so far.

0
 
pwindellCommented:
Then you are just going to have to use Localhost.  If you use that name (which has no "dots") it will just work,....nothing we have ever mentioned in this thread will matter or need to be done,...it will just work.

The root of the whole problem here is that using the IP# creates "dots" in the URL making it be treated as a FQDN when it is not a true FQDN.

The rule to live by here is never ever ever ever ever ever use IP#s in a URL,...ever.
0
 
Daniel BertoloneAuthor Commented:
Thanks for the tips phil, i think i will get her to use local host.

When you mention to never use IP#s in a url, where is this specified, on the proxy config on the server?
0
 
pwindellCommented:
When you mention to never use IP#s in a url, where is this specified, on the proxy config on the server?

No,...I mean,..literally,...never use IP# in the URL,..ever,...for anything.   I'm talking human fingers typing out the URL on the keyboard.

Now as far as this HMRC thing,...if you can't reconfigure how the HMRC thing works then you will just have to let it fail first,...and then back space the IP# out of the URL and replace it with Localhost manually.

Now I thought this was mentioned, but maybe not,..I can remember anymore and the thread has gotten excessively long......  If you use Proxy Auto detection via WPAD and also make sure the workstations have the Firewall Client installed the whole "dots in the URL" thing would simply disappear without any kind of intervention.   This proper configuration arrangement over-rides the bad behavior of IE and the IP#s in the URLs are properly interpreted.
0
 
pwindellCommented:
This site really needs to get an Edit feature so we can correct posts after they are submitted to clean up typos that are not noticed until after they are sent.
0
 
Daniel BertoloneAuthor Commented:
Thanks phil
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 15
  • 11
  • 6
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now