• RSS
  • Twitter
  • FaceBook

Welcome to ISAserver.org

Forums | Register | Login | My Profile | Inbox | RSS RSS icon | My Subscription | My Forums | Address Book | Member List | Search | FAQ | Ticket List | Log Out

Deny HTTP-8080

Users viewing this topic: none

Logged in as: Guest
  Printable Version
All Forums >> [ISA 2006 Firewall] >> Access Policies >> Deny HTTP-8080 Page: [1]
Login
Message << Older Topic   Newer Topic >>
Deny HTTP-8080 - 3.Aug.2010 10:31:19 AM   
tvbruwae

 

Posts: 69
Joined: 19.Jul.2005
Status: offline
Hi

In our environment we have several ISA 2006 Enterprise servers in different sites/arrays, each having its own internet connection. Proxy clients all have a primary proxy (nearby) and a secondary one, just in case the local internet line would be down. Everything is configured with wpad scripts.

Currently, when our monitoring software detects an internet line to be down, we shut down the corresponding ISA firewall service so that (Internet Explorer) clients detect the primary proxy to be down.

While this works, it has quite a few disadvantages (for instance, all equipment in a DMZ behind ISA is also unreachable). So now we tried to enable a rule that denies HTTP-8080 from anywhere to the ISA Server. Strangely enough, this has no effect at all and we can still telnet on port 8080 to ISA when the rule is on.

Any tips to handle this? For the browsers to detect a proxy failure, we should prevent it to connect to ISA on port 8080.

Thanks,
Tim
Post #: 1
RE: Deny HTTP-8080 - 3.Aug.2010 12:52:27 PM   
pwindell

 

Posts: 2244
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
You are already doing it the only way you can in the situation you have.

_____________________________

Phillip Windell

(in reply to tvbruwae)
Post #: 2
RE: Deny HTTP-8080 - 3.Aug.2010 4:44:49 PM   
tvbruwae

 

Posts: 69
Joined: 19.Jul.2005
Status: offline
That's not the answer I was hoping for, but at least it's a solid confirmation. Thanks for the reply Philip. Meanwhile I hope that in the future it will at least be possible to disable / block access to the web service somehow...

(in reply to pwindell)
Post #: 3
RE: Deny HTTP-8080 - 3.Aug.2010 5:05:25 PM   
pwindell

 

Posts: 2244
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
The problem is not the ISAs,..it is just simple mechanics.  If the ISA responds to the user,...then the ISA is not down,...what happens (or fails to happen) upstream is irrelevant to the situation.  Think about the process for a moment,..if it worked the way you want then the ISA would have no way to determine the difference if the break was just one-hop away or if it was just the one web server being reached,...after all, the ISA is not going to do a tracert and then analyze the result to determine where along the way it failed like a human would be able to do.

For example let's say Google had a bad day and their web server was down,...the user tried to go there and suddenly "nobody's home",...so the ISA then declares a failure and rolls over to the ISA at another site,...but the connection was fine all along, it was just one bad web server.  That is not the result anyone wants.

As far as the way you do it now,...there is no need to shut down the ISA.  Just unplug the network cable or disable the internal Nic by right-clicking on it and choosing disable.

_____________________________

Phillip Windell

(in reply to tvbruwae)
Post #: 4
RE: Deny HTTP-8080 - 4.Aug.2010 10:32:16 AM   
tvbruwae

 

Posts: 69
Joined: 19.Jul.2005
Status: offline
You remark makes sense if it is ISA who has to verify the upstream connection. However, in our situation it is not.

Per (main) site we have a simple script that runs on an internal machine every 10 minutes. It accesses a whole bunch of well-known web and FTP sites (the big ones: Microsoft, HP, Dell, Google, Yahoo, etc.). If they all fail to be reached through the local ISA at the same time, then we want the local ISA to become "unreachable" for the proxy clients. So we are using both a large number of sites + different protocols to actually verify the ISP line.

If the ISA is shut down (remotely, done by the script), then we have a proper failover of the clients. However it would be a lot nicer if we could just disable the web proxy port as this is the one with the most impact for end-users. If for instance we could enable a block-8080 rule through the script, we would still have full access to the networks in DMZ zones.

(in reply to pwindell)
Post #: 5
RE: Deny HTTP-8080 - 4.Aug.2010 11:56:25 AM   
pwindell

 

Posts: 2244
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
You remark makes sense if it is ISA who has to verify the upstream connection. However, in our situation it is not.

No, in your situation it is the ISA that has to verify the upstream connection.  Neither ISA or anybody else's product on the market is going to be aware of, or even care, about your script.   The product involved (ISA or whatever) has to be the one that detects a down connection and then make a decision on it according to its internal programming.  ISA (and any other product) is only going to be able to do that between itself and the first routing device upstream,...never any further than that.

If the ISA is shut down (remotely, done by the script), then we have a proper failover of the clients. However it would be a lot nicer if we could just disable the web proxy port as this is the one with the most impact for end-users. If for instance we could enable a block-8080 rule through the script, we would still have full access to the networks in DMZ zones.

No, it would have to disable the Internal Nic,...but once done there is no way to tell it to re-enable later since a disabled nic cannot respond to any commands. I think you are confusing the difference in the intent of a Proxy Array -vs- and NLB Array.

You also have not built the proper environment for what you want.  For what you want to happen would require two ISP Connections at each physical Site and both connections would have to come into the same device (a load balancing appliance).  You would only need one ISA at each location and it would use the load balancing appliance as the Gateway.

A Proxy Array is only for the purpose of covering a proxy that went down,...not an ISP connection going down. The need for having a proxy array would be completely separate and distinct from, and have nothing to do with, the ISP connection going down.

Summary:

Proxy Arrays protect against a lost proxy
NLB Arrays (or Appliances) protect against loosing a link to the next hop router
Nothing protects against loosing communication beyond the next hop router.

If someone wrote the functionality of your script into the program logic of their product then what you are asking for would be theoretically possible,...but to my knowledge such a thing does not exist.

_____________________________

Phillip Windell

(in reply to tvbruwae)
Post #: 6
RE: Deny HTTP-8080 - 5.Aug.2010 9:34:01 AM   
tvbruwae

 

Posts: 69
Joined: 19.Jul.2005
Status: offline
quote:

ORIGINAL: pwindell
No, in your situation it is the ISA that has to verify the upstream connection.  Neither ISA or anybody else's product on the market is going to be aware of, or even care, about your script.   The product involved (ISA or whatever) has to be the one that detects a down connection and then make a decision on it according to its internal programming.  ISA (and any other product) is only going to be able to do that between itself and the first routing device upstream,...never any further than that.


Once upon a time (when we were still deploying ISA 2004), we tried to use ISA connectivity verifiers to check the local uplink and perform an action whenever it showed to be down. It only proved that ISA connectivity verifiers are totally unreliable (google was reported to be down at least 3 times in 24 hours). So we decided to use a script instead, with the logic I described. Until today, the script has always been right in detecting actual ISP downtime in sites around the globe, just because it is checking from a client (end-user) perspective. On top, clients don't care what hop is down, they just want to get to the internet. So responsive actions can be taken anytime the script detects a failure.

quote:


No, it would have to disable the Internal Nic,...but once done there is no way to tell it to re-enable later since a disabled nic cannot respond to any commands. I think you are confusing the difference in the intent of a Proxy Array -vs- and NLB Array.

We have all those types of redundancy in place: ISA arrays with NLB are being used for box redundancy, different ISP's are being used in selected sites to overcome internet line outages, etc. However it has been the company's decision to rely on a remote site (with its own ISA and ISP) in case the local ISA and/or ISP is down, so that leaves us without choice. We cannot have multiple ISP lines in one site, so instead we have to prevent clients to connect to the ISA when we detect any local failure (ISA/ISP), in order to use the IE fallback mechanism. Blocking tcp/8080 would just be the most simple and solid way to do that without any other consequences, but that just seems to be impossible...

(in reply to pwindell)
Post #: 7
RE: Deny HTTP-8080 - 13.Aug.2010 5:28:51 AM   
tvbruwae

 

Posts: 69
Joined: 19.Jul.2005
Status: offline
Meanwhile, we were able to find an possible solution using the FPC COM object and some guidance from the SDK:

...
network.EnableWebProxyClients = False
network.save
...

When applying this to the internal network on our back-end ISA it should no doubt work as we intend it to, without any special rules to be implemented.

(in reply to tvbruwae)
Post #: 8

Page:   [1] << Older Topic    Newer Topic >>
All Forums >> [ISA 2006 Firewall] >> Access Policies >> Deny HTTP-8080 Page: [1]
Jump to:

New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts