Forum Index > Tomcat - General > Ports needed between IIS and Tomcat using JK redirector2.dll

Sep-24-2007, 09:09AM (47 weeks ago)
Photo Gary Allgood
System Engineer
Smurfit-Stone Container Corporation
Member since August 2007
Posts: 2
Hi, I have been very busy since training last month with Tomcat and
the training helped greatly. I am having one issue that I hope you
can help me shed some light on. I have searched high and low and
don't seem to be able to find anything to fully explain the
redirector2.dll for IIS, my question to you is does the redirector
using port 8009 require more than that port open in the firewall
between IIS and Tomcat?

With my IIS Server in the DMZ and the isapi filter setup as
documented would I need ports 8009 and 443 opened to reach the Tomcat
server in the business network? In other words does 8009 create a
tunnel over say port 443? If so I would need both ports open on the
firewall and that would make sense. But my understanding of the
redirector is it takes the traffic destined for 443 and tunnels it
via port 8009?

I seem to be stuck at this point never seeing the 8009 port hit the
firewall unless I specifically call in via the URL.

Your help is most appreciated,

Gary
Sep-24-2007, 08:04PM (47 weeks ago)
Photo Aleksandar Gargenta
Partner
Marakana, Inc.
Member since January 2007
Location: San Francisco, CA, United States
Posts: 10
Gary,

Your understanding is correct. The JK isapi_redirect.dll redirector
installed on IIS proxies requests to Tomcat on port 8009 over the
Apache JServ Protocol v1.3.

[Client] ----> HTTP/S (80/443) ----> [IIS] ----> AJP (8009) ----> [Tomcat]

If you have a firewall between IIS and Tomcat, you would just need to
open up inbound TCP port 8009.

The AJP protocol is not designed to be tunneled through SSL (port
443), although that's certainty possible (as with any other TCP
protocol) with custom OS/-level configuration. By default that will
not be the case.

Having said that, the JK connector in Tomcat can issue "redirects",
for unsecured connections in case your application has a user-data-
constraint with a transport guarantee of CONFIDENTIAL or INTEGRAL.

If you take a look at server.xml file, you'll find that by default the
redirects are sent to port 8443:

Code:

<Connector port="8009" enableLookups="false"
redirectPort="8443" protocol="AJP/1.3"
emptySessionPath="true" />


When a 302-redirect is sent back to the client:
1) Browser makes another request at the specified port (8443 by default)
2) IIS accepts that request (handling all SSL encryption)
3) IIS then proxies the request to Tomcat over AJP/8009 (informing Tomcat that the request is now "secure")
4) Tomcat generates the response
5) IIS receives the response from Tomcat over AJP
6) Client receives the response from IIS over HTTPS

I am not sure what you mean by not seeing hits to port 8009 unless you
specifically call it *via the URL*. You will not be able to make any
"browser" connections over the AJP/8009.

I hope this helps,
Sasa
Oct-17-2007, 08:57PM (43 weeks ago)
Photo Gary Allgood
System Engineer
Smurfit-Stone Container Corporation
Member since August 2007
Posts: 2
Sasa,

Thanks for your earlier input. What I found after long hours of toil is that the Isapi redirector has a bug that put us out of business as far as IIS.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35297

It seems that the current JK connector (as well as all the older ones cannot send chunked encoded content which is what I believe is causing us a HTTP 411(no content-length) error on some of this applications servlets. Much of the app worked fine, just some broke and the vendor assured us that their code was fine. It looks like this bug won't be fixed until JK 1.3 at the latest.


The bright news is that using Apache 2x and Mod_jk it is working like a charm. Now to tighten down the security and get SSL on there and test it out all.

Just wanted you to know about the bug in case other students threaten to use IIS and Isapi anytime soon...


Thanks,
Gary

Post Reply

Would you like to reply to this post? Please login or create an account.