Hi everyone,

 

I've run across a small problem using Pound which I'm hoping someone can
help me with. 

 

I've installed Pound on one of our servers (nav-akl-pcn-280) to act as
the front end to a couple of backend servers. Requests for our Factory
server should go through to 192.168.10.21 and all other requests should
go through to 192.168.10.23. Now, this seems to work fine for the web
services we have running, but we also have a JSP website with servlets
and that's where the problem starts.

 

In order to access the website users go to
https://nav-akl-pcn-280/admin/index.jsp,
which correctly displays the
index.jsp page from the server 192.168.10.23. The user enters their
login details and the login request is correctly sent through to the
login servlet (URL mapping of /servlet/login). The login servlet runs
correctly (I can see the debug output in the tomcat log) but when it
tries to send a redirect to a JSP page (java code:
response.sendRedirect(response.encodeRedirectURL
("../index.jsp;jsessionid=992152334E08C6E9902030C649AAE13F")); ) the
browser firstly gets a security alert indicating 'You are about to be
redirected to a connection that is not secure' and once you click 'Yes'
to continue the URL
https://nav-akl-pcn-280/admin/servlet/login;jsessionid=992152334E08C6E99
02030C649AAE13F, which does not display as it is an incorrect URL.

 

Now, the user has been correctly logged in as if you change the URL in
the browser to the correct URL of
https://nav-akl-pcn-280/admin/index.jsp;jsessionid=992152334E08C6E990203
0C649AAE13F then the website works fine from there on in until you try
to logout, which also uses a servlet and again the servlet is called,
processes correctly but the redirect to the login page (index.jsp) fails
in a similar manner. Btw, the only 2 servlets this site has are the
login and logout servlets - it's a pretty basic site.

 

For some reason the URL Redirects used by the servlets aren't working
correctly but I have no idea why. When I connect to the same backend
server via a different front end server running Apache, then the whole
site works fine. 

 

Btw, Apache is not involved at all in the case where I'm getting an
invalid URL - the request goes straight from Pound to Tomcat.

 

Some extra information which might help to locate the problem...

 

Pound config file...

ListenHTTPS *,443 /usr/local/etc/nav-akl-pcn-280.pem

#

LogLevel 2

#

URLGroup "/factory-jaxrpc.*"

Backend 192.168.10.21,8080,3

Session BASIC 0

EndGroup

#

URLGroup ".*"

Backend 192.168.10.23,8080,3

Session IP 3600

EndGroup

 

Pound Log...

Sep  7 10:00:31 nav-akl-pcn-280 pound: 192.168.12.33 GET
/admin/index.jsp HTTP/1.1 - HTTP/1.1 200 OK (192.168.10.23:8080)

Sep  7 10:00:31 nav-akl-pcn-280 pound: 192.168.12.33 GET
/admin/styles/registerbrowser.css HTTP/1.1 - HTTP/1.1 304 Not Modified
(192.168.10.23:8080)

Sep  7 10:00:37 nav-akl-pcn-280 pound: 192.168.12.33 POST
/admin/servlet/login;jsessionid=F8BEF803F4427793A3AF3BE5CB17A0EC
HTTP/1.1 - HTTP/1.1 302 Moved Temporarily (192.168.10.23:8080)

 

Tomcat Log...

2005-09-07 09:31:06,086 [http-8080-Processor24] DEBUG - login servlet

2005-09-07 09:31:06,086 [http-8080-Processor24] DEBUG - using existing
session

2005-09-07 09:31:06,086 [http-8080-Processor24] DEBUG - connecting to
database

2005-09-07 09:31:06,405 [http-8080-Processor24] DEBUG - authenticating
login

2005-09-07 09:31:06,406 [http-8080-Processor24] DEBUG - authentication
passed

2005-09-07 09:31:06,406 [http-8080-Processor24] DEBUG - redirecting to
../index.jsp;jsessionid=F8BEF803F4427793A3AF3BE5CB17A0EC

 

The following software versions are installed...

Pound 1.9

Tomcat 5

OpenSSL 0.9.8

 

Any assistance or guidance that anyone could provide in solving this
problem would be greatly appreciated.

 

Regards,

Sarah

I just got done troubleshooting a similar problem.

For some background (apologies if you already know all this)..

Pound needs to "rewrite" redirects.  The raw redirects that each 
back-end server generates are probably *not* going to be what you 
returned to the end-user since the hostname part of each redirect's 
"Location" URL will have the back-end's unique dns name (if it exists) 
or more likely just the machines IP address.  So if pound let the raw 
redirects through from your back-ends, your end-users would get 
redirects that looked like:

   https://192.168.10.23/admin/index.jsp

Obviously not what you want.

So Pound tries to do the "right thing".  When it sees redirects coming 
from your back-end it tries to rewrite them such that the back-end 
specific IP is replaced with a sensible DNS name.

By sensible, I think what it does (I'm a little fuzzy on the exact 
logic) is to do a reverse-dns lookup on the ListenHTTP (or ListenHTTPS) 
address to get a DNS name for that address.  Now that it has the public 
DNS name corresponding to your Listen address, it rewrites the redirects 
with the public DNS name.  Or something like that.  Perhaps Robert can 
clarify exactly why Pound needs DNS, I probably don't have all the 
details right.

But the point is that Pound requires a properly configured DNS resolver 
on the machine it's running on.

Short answer: double check that your machine is properly configured to 
do reverse DNS lookups on your public address.

If that doesn't do it, you might find that curl is very helpful for 
troubleshooting your redirect problems.  You can do something like this 
with curl (all one line)...

curl -i -d "username=usernamegoeshere&password=passwordgoeshere" 
https://nav-akl-pcn-280/servlet/login

The username= and password= are curl's way of simulating a form post. 
Simply replace the "username" and "password" strings above with the 
corresponding names in your login form and, of course, supply valid 
values for usernamegoeshere and passwordgoeshere.

Run that from a machine on the public side of your firewall and curl 
will "post" to your login form and what you'll get back is the 
"Location" header that contains the redirect information.  That'll let 
you see exactly how Pound has rewritten your URL's.

Run something like

curl -i -d "username=usernamegoeshere&password=passwordgoeshere" 
http://192.168.10.23:8080/servlet/login

 From a machine *behind* your firewall (and within the same LAN as the 
servers) and you'll see the raw redirect generated by the back-end server.

Comparing the two (rewritten and un-rewritten) can be helpful when 
troubleshooting.

Also note that there has been some recent activity in the 
source-repository regarding redirects (particularly those involving 
HTTPS, I think) so you might double-check that you're running an 
up-to-date version.

Also, also, note that redirectRewrites can be turned off with a config 
directive.  They're on by default so you probably don't need to worry 
about it, but it's good to know you have some control over them.

Hope that helps.

- Gary


Sarah Brennan wrote:[...]

Hi Gary,

Thank you for your quick response and all the useful information you
included. You definitely put me on the right track and I have now solved
the problem. It appears that there was 2 main issues which needed to be
fixed. 

Firstly, our DNS server has a few problems and was incorrectly reporting
the name of the server which Pound was running on.

Secondly, in the Pound configuration file I was listening on '*' which
was a bad idea, so I changed the configuration file to listen on the
Pound servers IP address instead.

After fixing both of those issues, it now works as expected.

Thanks again,

Sarah

-----Original Message-----
From: glists(at)greywether.com [mailto:glists(at)greywether.com] 
Sent: Wednesday, 7 September 2005 11:01 a.m.
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Problem with Servlet Redirects

I just got done troubleshooting a similar problem.

For some background (apologies if you already know all this)..

Pound needs to "rewrite" redirects.  The raw redirects that each 
back-end server generates are probably *not* going to be what you 
returned to the end-user since the hostname part of each redirect's 
"Location" URL will have the back-end's unique dns name (if it exists) 
or more likely just the machines IP address.  So if pound let the raw 
redirects through from your back-ends, your end-users would get 
redirects that looked like:

   https://192.168.10.23/admin/index.jsp

Obviously not what you want.

So Pound tries to do the "right thing".  When it sees redirects coming 
from your back-end it tries to rewrite them such that the back-end 
specific IP is replaced with a sensible DNS name.

By sensible, I think what it does (I'm a little fuzzy on the exact 
logic) is to do a reverse-dns lookup on the ListenHTTP (or ListenHTTPS) 
address to get a DNS name for that address.  Now that it has the public 
DNS name corresponding to your Listen address, it rewrites the redirects

with the public DNS name.  Or something like that.  Perhaps Robert can 
clarify exactly why Pound needs DNS, I probably don't have all the 
details right.

But the point is that Pound requires a properly configured DNS resolver 
on the machine it's running on.

Short answer: double check that your machine is properly configured to 
do reverse DNS lookups on your public address.

If that doesn't do it, you might find that curl is very helpful for 
troubleshooting your redirect problems.  You can do something like this 
with curl (all one line)...

curl -i -d "username=usernamegoeshere&password=passwordgoeshere" 
https://nav-akl-pcn-280/servlet/login

The username= and password= are curl's way of simulating a form post. 
Simply replace the "username" and "password" strings above with the 
corresponding names in your login form and, of course, supply valid 
values for usernamegoeshere and passwordgoeshere.

Run that from a machine on the public side of your firewall and curl 
will "post" to your login form and what you'll get back is the 
"Location" header that contains the redirect information.  That'll let 
you see exactly how Pound has rewritten your URL's.

Run something like

curl -i -d "username=usernamegoeshere&password=passwordgoeshere" 
http://192.168.10.23:8080/servlet/login

 From a machine *behind* your firewall (and within the same LAN as the 
servers) and you'll see the raw redirect generated by the back-end
server.

Comparing the two (rewritten and un-rewritten) can be helpful when 
troubleshooting.

Also note that there has been some recent activity in the 
source-repository regarding redirects (particularly those involving 
HTTPS, I think) so you might double-check that you're running an 
up-to-date version.

Also, also, note that redirectRewrites can be turned off with a config 
directive.  They're on by default so you probably don't need to worry 
about it, but it's good to know you have some control over them.

Hope that helps.

- Gary


Sarah Brennan wrote:[...]
can[...]
should[...]
'Yes'[...]
fails[...]

[...]

Sarah Brennan wrote:[...]

Right, basically the same problem I had.
[...]

Yah, I noticed that in your config and wondered about it, too.

Robert, can you provide some detail on how DNS lookups work when using 
and "*" for ListenHTTP and ListenHTTPs?
[...]

Glad I could help.

- Gary

On Tue, 06 Sep 2005 18:39:16 -0700 glists(at)greywether.com wrote:
[...]

Sure. The DNS lookup is used to determine if a rewrite is required, not
to do it. Pound checks if the response is a redirect to one of the
back-ends it manages (given that these may be known by several symbolic
names rather than an IP address, a look-up is necessary).

Example: Pound has back-ends 1.2.3.4 and 1.2.3.5. A reply comes from
1.2.3.4, involving a redirect to www.elsewhere.net. A DNS look-up
reveals that www.elsewhere.net resolves to 1.2.3.5, and thus a rewrite
may be necessary.

The rewrite itself involves the original virtual host of the request.[...]