ISA proxy not working externally.....?

TechJunky

can someone please try to go to ww2.skurlas.com

I am getting a proxy error message and cannot figure out why its being caused.

Thanks.

TechJunky

I am thinking it is a bad dns record on my dns server not point to the 192.168.0.10 interface.

external is 192.168.0.10 and internal is 192.168.2.1

I had to recreate the reverse dns records today because nslookup was not working...

Nothing has changed on ISA.

sprkymrk

11004 - Host not found
Internet Security and Acceleration Server


This error indicates that the server, while acting as a gateway or proxy, could not find the IP address of an upstream content server.

Is that the same thing you're getting? Also:

C:\>nslookup [url]http://ww2.skurlas.com[/url]
*** Can't find server name for address 192.168.3.1: Server failed
*** Default servers are not available
Server:  UnKnown
Address:  192.168.3.1

*** UnKnown can't find [url]http://ww2.skurlas.com:[/url] Non-existent domain

TechJunky

Yes, I get 11004 error message.

Here is what I get when I do an nslookup.

C:\>nslookup
Default Server: vcns-1.gci.net
Address: 209.165.131.12

> set type=any
> ww2.skurlas.com
Server: vcns-1.gci.net
Address: 209.165.131.12

Non-authoritative answer:
ww2.skurlas.com internet address = 209.112.135.148

skurlas.com nameserver = ns1.hostgo.com
skurlas.com nameserver = ns2.hostgo.com
ns1.hostgo.com internet address = 64.71.145.162
ns2.hostgo.com internet address = 216.218.220.34

So it looks like its pointing to 209.112.135.148 like it should... I have no idea why it is showing 192.168.3.1 on your side. Maybe i fat fingered somewhere and put 192.168.3.1 in my dns somewhere instead of 192.168.2.1 ?

sprkymrk

TechJunky wrote:

So it looks like its pointing to 209.112.135.148 like it should... I have no idea why it is showing 192.168.3.1 on your side. Maybe i fat fingered somewhere and put 192.168.3.1 in my dns somewhere instead of 192.168.2.1 ?

The 192.168.3.1 is my dns server, the "non-existant domain" is what it's returning for your web site.

My nslookup is resolving to 209.112.135.148 now, if you notice I had done a quick copy/paste from the url and left the "http" in by mistake.

However, I still get the 11004 error. I get the same thing using http://209.112.135.148/ which might rule out a DNS error. Are you using private IP's internally that get nat'ed at the ISA? Or are you using public ip's internally? The error seems to indicate that the ISA server cannot find your internal web server for some reason.

TechJunky

I have a Router setup with the 209.112.135.148. I then have Natting to a 192.168.0.10 external on my ISA server, then I have a 192.168.2.1 internal on the same ISA server that goes to a switch with the network setup on a 192.168.2.10 - 192.168.2.254 ip range for internal users of the company.

I have OWA setup on the ISA server using 192.168.2.1 and 192.168.0.10 interfaces.

We can tell that it is getting past the router to the 192.168.0.10 interface because it returns an ISA error message by the ISA server. I know it was working before, I removed the 192.168.0.x reverse on my DNS, which my ISA server uses DNS. So I am thinking I need a PTR record for the ISA server of 192.168.0.10

I think its returning that error message, because its looking for the web server, but cannot resolve dns?

TechJunky

Btw, I think its DNS because if I am on the 192.168.2.x network and type in either 192.168.2.1 or the server name denali in the web browser the OWA service works just fine. Then when I get on the 192.168.0.x network and try 192.168.0.10 or the server name denali it gives me that 11004 error message.

TechJunky

Ok, I have DNS setup properly now and it still does not work. I can get to it by denali, or 192.168.2.1, but i cant get to it from 192.168.0.10....

Any ideas?

Thanks.

TechJunky

Here is some info I have found about the 11004 error...

11004 Valid name, no data record of requested type.

The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a hostname -> address translation attempt (using gethostbyname() or WSAAsyncGetHostByName()) which uses the DNS (Domain Name Server), and an MX record is returned but no A record - indicating the host itself exists, but is not directly reachable.


Using one of the WinSock based components (AspMail, AspPOP3, AspHTTP etc), I am getting, "11004 Valid Name, no data record requested type." The equivalent Winsock code is WSANO_DATA. This commonly occurs with
gethostbyname.
Typical causes we've found include:

You don't have a DNS entry for the server you are operating from or
You have not set a host and domain for the server.

I will take a screenshot of the server's DNS and see if you guys see something I am missing.

Thanks.

Here ya go.

sprkymrk

Hmmm.

Is the ISA server also running as your DNS server? Is it the OWA server? Or are the ISA and DNS and OWA seperate machines?

How is ISA handling DNS - is it a split-DNS configuration?

The thing that is confusing me is the fact that even typing in the IP address of the server won't work, which should technically eliminate a DNS issue in most cases. Are we trying to connect to OWA or a website that is hosted on the same server as the OWA?

Since you can connect from the 192.168.2.x network I think DNS is properly configured, and since the firewall is not in-between the clients and server (unless it is also the DNS server or also the web server) it may be the problem lies in it somewhere. The rule that published the website - can you disable it and rerun the "publish server" wizard or whatever it's called in ISA 2004 and see what happens?

TechJunky

Ok, I agree with the dns, since it doesnt work via ip.

Here is the server configuration.

SBS 2003 with the Remote Desktop/OWA installed and running. It comes as a package deal on 2003 SBS. Also, ISA comes with SBS 2003.

So ISA, DNS, OWA/Remote Desktop are running via the same box. I know this is a bad idea, but the company is small and they dont want to fork over the cash for seperate boxes.

It was working until last friday.

I can re-run the ISA server setup wizard and see if that fixes the problem?

blargoe

Disclaimer: I'm not an ISA expert or even an SBS expert..

I just set up an SBS 2003 (R2) server a couple of weeks ago for my customer, and there was a wizard to configure which applications you wanted to grant outside access (the wizard has the option to allow remote desktop, outlook web access, something called remote workplace, and one or two other things) and I think there is also a way to change the settings back to the defaults as well. I'm haven't monkeyed with the configuration very much so I'm not really sure where to tell you to look, and if you're not running R2 (which uses ISA 2004) I don't know whether it would apply. On the surface to me it seems like there is a problem with the rules that is causing port 80 to not be allowed from outside anymore.

sprkymrk

TechJunky wrote:

Ok, I agree with the dns, since it doesnt work via ip.

Here is the server configuration.

SBS 2003 with the Remote Desktop/OWA installed and running. It comes as a package deal on 2003 SBS. Also, ISA comes with SBS 2003.

So ISA, DNS, OWA/Remote Desktop are running via the same box. I know this is a bad idea, but the company is small and they dont want to fork over the cash for seperate boxes.

It was working until last friday.

I can re-run the ISA server setup wizard and see if that fixes the problem?

I wondered if it was an SBS box, which can make the problem more difficult to troubleshoot, but I realize for smaller companies it's a good bargain software and hardware wise so I wouldn't be critical of using it if it fits the need.

ISA plays funny with DNS, and I haven't looked at an ISA box in a while, but the 2004 version may have a split-dns configuration by default which could put us back at square one on what exactly the problem is. I would try running the server publishing wizard again now that you have rebuilt the dns. I am curious on how ISA handles the 2 host (A) records for denali. It should have a rule or something in the publishing wizard to tell it which IP to use. It may be that the server is only published by it's 192.168.2.1 address, perhaps the deletion of the ptr record corrupted a rule it was using to publish via the 192.168.0.10 address.

blargoe

Hey, here's another clue you guys - I tried the site using https, got the certificate prompt for denali.skurlas.local, accepted it, and still got the same error message that you guys have been getting. I think that pretty well settles that DNS is working.

TechJunky

I wouldnt doubt that it could be using the 192.168.2.1 instead of the 192.168.0.10. Which I would think could cause this whole problem I am having. I will try and re-run the wizard when we have some down time at work.

TechJunky

I went ahead and ran the internet wizard and created a new certificate. Everything seems to be working again.

sprkymrk

Cool! Thanks for letting us know, I was curious.

TechJunky

Ok, lol. It looks like it works from 192.168.0.x network, but not outside?

try getting to ww2.skurlas.com and let me know.

sprkymrk

I get this when I use https:

TechJunky

Thanks,

I already left work, but since the packet filtering was reset when I did the wizard I think I found the problem.

I am getting the following error when trying to remote desktop connect.

"The client could not connect to the remote computer. Remote connections might not be enabled or the computer might be too busy to accept new connections. It is also possible that network problems are preventing your connection. Please try connecting again later. If the problem continues to occur, contact your administrator."

Then I found this KB.

http://support.microsoft.com/kb/828053

So when I get back into work I will try adding the ip packet filter again.

TechJunky

Just so everyone knows that was the problem. Once I allowed the port through everything worked as described.

sprkymrk

Glad you got it back up and running.
So do you think the original problem was deleting the ptr record, which was being referenced by ISA, or was it something else? Maybe a combination of two things that made it harder to trouble shoot?

TechJunky

Yeah, it was the PTR record. It could not figure out internally where to direct the site to.

I am just glad its fixed.