I'm publishing different web servers with a listner on the external interface. The problem is that when I try access those websites from other networks, not external, I get a "page not found" error. When I view the logs I can see that when I'm trying to access the published servers from one of the internal networks, it seems that the publish rule is ignored and I get a "Denied connection" based on the last default rule. I guess that is because the servers are published only on the external network. I don't want to publish the servers on other networks because I want everyone, including all the internal networks, to access those servers via their External IP addresses. I tried to add a regular access rule that will let the internal networks access the "localhost" with http and https. Now I don't get a "denied connection" on the log but I still can't access the websites.
I think the base of this problem is that the listner is only for the external network, but don't forget that I have to access those sites with their external IP addresses even from internal networks, so I can't add listners on the internal IP's,
i dont understand why you want to loopback through your isa server? that is not the right way to do this.. you should configure your dns internaly to point to your webserver because this way you will save resources on the isa server..
Not all my internal networks have access to each other so I can't do it. I nee the ISA to function as Reverse proxy for all website connections. My DNS environment is very complicated and I can't do it anyway. I have to point all the networks to the same IP address, which is the external IP on the ISA.
internal clients should access internal resources directly, not the published instance of that resource. If that isn't possible, the only workaround I know of is to publish those internal resources to the different internal interfaces and 'play' with the DNS Netmask Ordering feature on the internal DNS server.
For more info about the DNS Netmask Ordering feature, check out:
BTW --- I've learned in the 30 years I'm in the IT business that the art is to know the limitations of any product you deploy and accept them as it. In any case don't use the product for what it is not specifically designed for unless you are willing to hurt yourself!
HTH, Stefaan
< Message edited by spouseele -- 4.Nov.2006 5:54:49 PM >
Not enough for me my friend. If something don't work I want to know why. If there is no clear reason, we have to find it... If HTTP works, why SSL don't ? I'll keep searching and let you know.
If you really want to know why, I suggest you call Microsoft PSS or try to contact Jim Harrison [Jim.Harrison@microsoft.com] of the Microsoft Security Platform Group (ISA).
Posts: 271
Joined: 5.May2001
From: Redmond, WA
Status: offline
He did, too.
ISA laws of web proxy client traffic: - Web proxy clients connect to an upstream HTTP site via bridging - Web proxy clients connect to an upstream HTTPS site via tunneling
ISA bridging allows this because each connection (client to ISA, ISA to itself, ISA to upstream server) represents a different socket. Tunneling fails because ISA effectively becomes a port-translating NAT device. When ISA tries to create a tunnel to itself (the publishing listener), it has to change from bridging to NAT and this is where the connection fails.
Basically, you have two choices; both of whch require that you take control of your DNS: 1. build your split DNS and allow the web proxy clients co connect directly to the internal servers. 2. create DNS records that resolve to the ISA internal interface and build a web publishing rule that bridges back to the internal servers
so... basically the same limitations as with ISA 2000. As far as ISA 2006 is concerned, that's more an R2 release of ISA 2004. Therefore no change in that behavior, I think.