2

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. https://10.0.42.136/...) everything works fine and localhost_access_log. show me that the query returns a 200.

However - accessing the same server using FQDN (e.g. https://mydomain.com/...) 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: http://webcache.googleusercontent.com/search?q=cache:Y0BozNSUpN4J:forums.isaserver.org/fb.aspx%3Fm%3D2002034493+tomcat+behind+isa+server+certificates&cd=1&hl=no&ct=clnk&gl=no?

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

2
  • Did you make sure that resolving the name mydomain.com gives the correct IP address of the server? If not, you may be directed to another server!
    – Khaled
    Oct 18, 2011 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, 2011 at 6:43

2 Answers 2

1

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

So, when you connect to https://10.0.42.136/ 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:

10.0.42.136     mycompany.com

(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:

c:\>ping mycompany.com

Pinging mycompany.com [10.0.42.136] with 32 bytes of data:
...

If it's pings 10.0.42.136 check https://mycompany.com/ 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.

3
  • 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 mycompany.com 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, 2011 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, 2011 at 10:27
  • 1
    Thank you for the feedback. I've changed the title of the question.
    – sonstabo
    Oct 21, 2011 at 12:45
1

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 .

1
  • 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 10.1.1.1 != mycompany.com. I'll forward information to my ASP.
    – sonstabo
    Oct 24, 2011 at 8:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .