The RDP rule can (and should) be safely ignored; it has nothing (read zip, zero, nada) to do with the tsweb rule. If you want to send anything, please send the ISAInfo (http://isatools.org/isainfo/isainfo.zip) and excerpts from the ISA logs showing these failures. Screenshots are very nearly useless for describing ISA configuration. ------------------------------------------------------- Jim Harrison MCP(NT4, W2K), A+, Network+, PCG http://isaserver.org/Jim_Harrison/ http://isatools.org Read the help / books / articles! ------------------------------------------------------- -----Original Message----- From: Clayton Doige [mailto:clayton.doige@xxxxxxxxx] Sent: Wednesday, October 19, 2005 18:08 To: [ISAserver.org Discussion List] Subject: [isalist] RE: 403 Forbidden http://www.ISAserver.org Thanks for that, I will be onsite tomorrow and have a look at what you have sent. However, I am not testing from an internal client, I am testing from the external interface network, I have placed countless entries in the Public Name section during this process up to all of the possibilities concurrently. Thanks for the refresher course on HTTP get requests. Let us not forget that a straight packet filter type rule using RDP to this same IP Address (as the tsfarms http address) is up and running from outside the firebox. I know this is a web listener misconfiguration issue, for which I blame everyone else but myself, mostly Bill Gates. I know that I have had web listeners work in sites where a simple public name of 'all' worked. So here's the last thing I can try on this, if you are up for it? I am using private 10 ranges for both the internal and external nics of the isa. Would you be willing to diagnose some screen shots if I sent them to you offline? This is not an issue of ego, I really don't care how stupid I might look, I just want to get this working, but at the same time, I don't need the big bad world knowing the internal IP Address of a TS Farm, for what I consider to be obvious reasons. Jim, if this is OK, then let me know. I am in the UK, and will be able to provide you with the screen dumps of the rule and listener config pages pdq, but would not assume you are ok with that without your consent. Regards Clayton -----Original Message----- From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx] Sent: 20 October 2005 01:23 To: [ISAserver.org Discussion List] Subject: [isalist] RE: 403 Forbidden http://www.ISAserver.org I swear; it's an epidemic... :-p I've included a breakdown I posted to the SBS list for your potty-time reading pleasure... <------------- start of posting ---------------> First, *never* test publishing rules from an internal client. Name resolution and "bounce-back" issues can give you some really interesting results. Second, perform your initial testing using a client that is connected to the same network as the ISA external interface; not another ISP. ISP blocking policies can severely impact your testing. Third, for *every* URL you expect to support, you *must* place the hostname portion of that URL in the "public name" list for that publishing rule. Short class on HTTP requests (Internet-based; not behind a proxy)... When a browser wants to make a connection to any Web service, it will: 1. Disassemble the URL into its component parts. So, for the URL http://host.domain.tld:1234/path/resource, the browser will break it down into three basic entities: 1. protocol; "http://"; 2. host: "host.domain.tld" 3. port: "1234" 4. resource: "/path/resource" 2. Resolve the host to an IP 3. Make a connection to the resolved IP. If the port is specified, it will use it, if not, it will use the standard port for the specified protocol (http == 80, https == 443, etc.) 4. Send the request to the server as a collection of data expressed as "headers". If you're watching through a network capture tool, they appear as: GET /path/resource HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NETCLR 1.1.4322) Host: host.domain.tld Connection: Keep-Alive The parts that interest you for web publishing are: - GET /path/resource HTTP/1.1 ..the "/path/resource" part need to be accounted for in the "Path" data for the publishing rule - Host: host.domain.tld ..the "host" header field data needs to be accounted for in the "Public Names" list <--------------- end of posting ---------------> ------------------------------------------------------- Jim Harrison MCP(NT4, W2K), A+, Network+, PCG http://isaserver.org/Jim_Harrison/ http://isatools.org Read the help / books / articles! ------------------------------------------------------- -----Original Message----- From: Clayton Doige [mailto:clayton.doige@xxxxxxxxx] Sent: Wednesday, October 19, 2005 14:15 To: [ISAserver.org Discussion List] Subject: [isalist] RE: 403 Forbidden http://www.ISAserver.org Jim, thanks, what you are telling me give me encouragement that I am doing things correctly in principle LOL. You are gonna love this. http://ip.add.re.ss/tsweb brings up 403 (12202)from the segment of the external card on the isa, and it does the same thing from outside the firebox. I have put the external IP of the ISA and the external IP of the firebox in the public names section. I have removed on, then the other, I have tried it with the original header being forwarded from the original client, and without one or other or both. I have taken out the specific entries under paths and tried, basically, I have tried every single combination I can think of in terms of what settings are available, and the ISA Server sends me away mad every single time. AS I mentioned, I have an RDP rule that works from the outside world absolutely perfectly, but as soon as I bring the web listener into place it screws up. Now, more information, which if it is relevant I apologise for leaving out: I have followed the tutorial off of the ISAserver.org site to configure ISA to server OWA using forms based authentication. This is only set up for port 443, and uses a different web listener, funnily enough, I get the same issue there. If I disable this rule, the arror on the tsweb site does not go away, but it does raise the question: should I bind a second IP Address to the external nic of the ISA, and set up the listener for the tsweb side of things on that nic? I dunno here, it SEEMS like I have done all of the stuff you have suggested here, and have spent the better part of two days a week for the last couple of weeks (all I have to give to the project as I am not permanently at this site) working through articles, google searches, trial and error, (specifically 403 LOL), and error and error. Thus, the comment about said server being at risk of a David Letterman experiment... Thanks again for your help, and I dunno why OWA did that on my last post oh well. Clayton -----Original Message----- From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx] Sent: 18 October 2005 23:30 To: [ISAserver.org Discussion List] Subject: [isalist] RE: 403 Forbidden http://www.ISAserver.org Your mail app is acting up; it sent your mail as an attachment... Ok - if you place a test client between the firebox (be quiet, Tim) and the ISA and test using http://ip.add.re.ss/tsweb, *exactly* what do you get? If you expect to test external to the firebox, you'll have to add the firebox external IP to the ISA "public names" list. When a browser attempts to connect to a server, is sends a "host header" as part of the request. This header contains the "host" portion of the URL that was entered in the address bar. For instance, if the URL is http://host.domain.tld/phisherman.dll?username=sillyfool&password=comple tedumbshit ..then the host header will contain "host.domain.tld" and it's this data that ISA will use to compare to the "public names" list to determine if this request should be allowed. 403/12202 is how ISA says "no host header match found; don't go away mad, just go away." Ideally, you shouldn't use IP addresses at all, since it's a *very* old virus connection technique (remember Code Red?). ------------------------------------------------------- Jim Harrison MCP(NT4, W2K), A+, Network+, PCG http://isaserver.org/Jim_Harrison/ http://isatools.org Read the help / books / articles! ------------------------------------------------------- -----Original Message----- From: Doige, Clayton [mailto:clayton.doige@xxxxxxxxxxx] Sent: Tuesday, October 18, 2005 14:42 To: [ISAserver.org Discussion List] Subject: [isalist] RE: 403 Forbidden http://www.ISAserver.org This is a multi-part message in MIME format. OK, OK, letting my frustrations rule the Vulcan mindset. I put the public name as an IP Address that is associated with the public interface of the ISA, which in this case is a DMZ IP of 10.*.*.*, and that does not work. I thought this would work as the external firewall is doing dynamic NAT from the public IP which will remain secret to protect my short comings that seem to be readily apparent here. I can open that website via IP directly from the ISA server itself. So, as that did not work, I tried giving the Public Name the IP Address that the external firewall, a Watchguard Firebox X 1000 with Fireware Pro software (does all sorts of whizzy loadbalancing amongst multiple ISP's that I am not using yet) and this still does not work. I very much appreciate your taking the time to help me out here, so ask away to clarify what the heck I am doing wrong. For the sake of clarity, I am going to make some IP Addresses up to try an illustrate the settings I have in place, and I will sub reserved IP's for what I am actually using (assume a 24 bit mask). Firebox X 1000 Public IP 192.168.0.1 NATS HTTP to 192.168.1.1. ISA 2004 External IP 192.168.1.1 HTTP Publishing Rule Public Address 192.168.1.1 To Web Server Address: 192.168.2.1 The listener is therefore configured to listen on 192.168.1.1 and pass this to 192.168.2.1 Combined with the settings in my earlier posts does this give you an idea of what I have set, and what might be missing? I am trying to access the site from a remote site that has no physical connectivity to my test bed other than on the public net. I have also tried to access the site directly through the ISA from (for example) 192.168.1.5, and get the same result, thus the X 1000 is not the issue. So, 192.168.0.1 should take you to 192.168.2.1. I have created a simple rule for the RDP protocol which works in the above scenario perfectly, and if I did the same with the HTTP protocol I am sure it would work a treat, but as soon as I invoke the web listener, I have this issue. Ultimately, I am having the same issues getting OWA with forms based authentication on this test bed, so am hoping a simple unsecure, non ssl http solution will get me where I want to go with the OWA as I need to get this working for many a reason. If I were to do anything with this kit, aside from the Coyote thing, it would be to install it at home as a nice movie storage location, given the three 72 GB 15000 rpm drives in the thing LOL. All mail to and from this domain is GFI-scanned. ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: clayton.doige@xxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: jim@xxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx All mail to and from this domain is GFI-scanned. ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: clayton.doige@xxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: jim@xxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx All mail to and from this domain is GFI-scanned.