Hi.
In addition to what you explained below, could you explain the network setup ?
In particular, are users always accessing the tomcat server directly, or through a
firewall, and/or through a front-end like Apache httpd ?
And what is this "external service" ? is that another webserver ?
On what ports does all this run/listen/communicate ?
Also, when you mention "85.18.x.x", is that literally "85.18.x.x", or did you just
"obscure" the real IP address for privacy reasons ? and if so, when you say "85.18.x.x",
does that mean that it is always the same IP address exactly, or do these last "x.x" vary ?
I guess that what I am saying really is : your explanation below is rich in words, but
relatively poor in real data, so it is a bit hard to give you real answers.
Also, just as a tip : if the pages returned by Tomcat (or this "external service") contain
links, and these links are sometimes relative (e.g. <a href="/img/logo.gif"..) and
sometimes absolute (e.g. <a href="http://someserver.company.com/img/logo.gif";..), it may
be that some user accesses take one route through the network, and other user acesses take
another route, and this may explain why getRemoteAddress sometimes shows different addresses.
Filippo Machi wrote:
Hi all,
we're experiencing an issue with the getRemoteAddress method
(HttpServletRequest).
We don't know whether is something known depending on tomcat or if it's
something malicious,
affecting our servers.
We have a filter that authorizes incoming requests using different patterns,
one of these is based on
ip checking. Requested performed by localhost are granted.
Since we have an external service, installed on the same host running the
tomcat, and this service
invokes b2b requests on the tomcat istance (using 127.0.0.1), we noticed the
following strange behaviour:
sometimes requests are rejected since the ip obtained invoking the
getRemoteAddress method results
equals to 85.18.x.x.
How can I say that? We considered both the log of the tomcat and the log of
the external service described above
and the content matches. I mean, each time this kind of failure occurs (it
happened different times), the external service
log the http response and, since the ip checking fails, it receives an html
page, the login page!
So, a request issued by a service running on localhost and sent as a get to
a tomcat istance running on localhost appears to be issued
from the ip address I mentioned above but we are sure that the client and
the server are talking each other.
This failure occurs periodically, at the same hour of the day. Besides,
since we added some logs to have a better picture, we noticed that
sometimes even during user interactions from external but known ips some
requests appear to be issued by the address 85.18.x.x.
Anyway, users are able to see web pages without any issues, since in this
case their requests are authorized by a cookie and not by ip checking.
Has anybody a clue of what is happening?
Thanks in advance
fil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
![http://someserver.company.com/img/logo.gif"](http://someserver.company.com/img/logo.gif"){kind=link}