Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I experience an issue accessing Tomcat running over SSL with MS ISA 2006 in front.

When I access using the internal IP address (e.g. everything works fine and localhost_access_log. show me that the query returns a 200.

However - accessing the same server using FQDN (e.g. throws a 403 - Forbidden in the browser. On the Tomcat server I find a 401 error listed not 403. In other words - ISA throw 403 while Tomcat throw 401.

Both the server hosting the Tomcat as well as the server querying the Tomcat application have full access to the internet.

I believe there might be an issue with the ISA server as I assume the IP address traffic goes directly while the FQDN traffic goes 'out' before it comes back 'in'. But I am not sure of this.

Does the Tomcat require any additional configuration to serve https traffic from the outside, e.g. add the IP address of the ISA server, since it works just fine using the IP address?

Do we need to do anything in regards to certificates, as indicated here:

Why does the traffic from my client machine on the outside go just fine, but the traffic from the internal network fails?

share|improve this question
Did you make sure that resolving the name gives the correct IP address of the server? If not, you may be directed to another server! – Khaled Oct 18 '11 at 18:42
Since I'm able to connect to the 'problematic' server from the outside I believe this is taken care. – sonstabo Oct 21 '11 at 6:43

A suppose that nslookup prints the IP address of the ISA server and is the IP address of the Tomcat (not the ISA).

So, when you connect to you connect directly to Tomcat (without ISA). You can check simply whether connecting to Tomcat with FDQN works if you write the following to your hosts file:

(The path of the file usually is c:\windows\system32\drivers\etc\hosts or /etc/hosts.)

After that check with ping that your hosts file entry is right. The command and the results should be something like this:


Pinging [] with 32 bytes of data:

If it's pings check in a browser. Maybe you need to restart the browser before it and don't forget to remove the line from the hosts file later.

If the website works well with the hosts file entry it's definitely an ISA server issue. Otherwise the issue is related to Tomcat.

share|improve this answer
I'm pretty sure it is a ISA issue: 1. Everything is OK when the 2 servers behind the firewall communicate using the internal IP 2. Everything is OK when a browser outside the network browses It is when the traffic going from internal server #1, out to the world, returning, through ISA and back to internal server #2 shit hits the fan :| – sonstabo Oct 21 '11 at 10:09
In that case you should edit your question, tag it as ISA instead of Tomcat, maybe change the title too. – palacsint Oct 21 '11 at 10:27
Thank you for the feedback. I've changed the title of the question. – sonstabo Oct 21 '11 at 12:45

You haven't said anything about the client, and that's important. Should the client be going "out" to hit the FQDN? Have you told it it's local, or that it should avoid the proxy, for that URL? (what is the client?)

Anyway, that aside, I think you could be experiencing reflection attack protection.

More classically: if your ruleset doesn't suggest that Internal hosts can talk to other Internal hosts, then they can't.

If the FQDN is designed to exit your network and come back in via ISA, it needs a rule set that permits that combination.

So if you want to allow Internal network clients to connect to your HTTPS external website, try a rule something like: Allow / HTTP&HTTPS / From: Internal Network / To: Internal IP of the host you're using (might also try a URL set including it, but that's possibly not required .

share|improve this answer
There are 2 servers involved that are basically the client and the server. The client will connect to the server and ask for user authentication. The server will basically respond Yes/No. This traffic has worked just fine using internal IP address. But not using FQDN. I need it to use FQDN as we are moving into a SSO setup and we're facing some issues we believe might have something to do with the fact that the client is trying to authenticate using the internal IP instead of the FQDN, e.g. that the cookie issues for != I'll forward information to my ASP. – sonstabo Oct 24 '11 at 8:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.