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.