We're attempting to identify where specific requests are coming from inside our Java application. We have changed the log files to include the IP address and we're using httpServletRequest.getRemoteAddr() to get that remote address.

On our local development machines running Tomcat, this works. In our CI environment (Tomcat on a Mac), this works.

The problem is that on our staging and production environments, this doesn't work. We always see from httpServletRequest.getRemoteAddr(). Our staging and production environments are both VMware VMs running CentOS. They are running within/on ESXI and are behind a Cisco 5500 ASA.

We've seen other posts similar to this problem that say to look for an "X-Forwarded-For" header and print that if it exists. It doesn't. Below is a full list of headers that are coming through the request.

We don't have much insight into how the ASA or VMware is set up so if there's something there that could be causing this, please provide a detailed answer on what to ask our IT group about to get this fixed. We think this might be related to VMware since we're seeing If it was the ASA, we'd assume we'd see the IP of the ASA instead but I'm open to being told I'm incorrect.

Complete headers for a request:

user-agent:Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)

UPDATE - We just realized we had a local port redirect involved:

The only other thing that might be relevant is that we're using an HTTP xinetd port redirect to forward SSL traffic to an internal port:

service https
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    port = 443
    protocol = tcp
    redirect = localhost 8999
    log_on_failure += USERID
  • Is there an Apache or NginX web server proxying the requests to tomcat? If so, the requests are coming from most likely. – yoonix Mar 13 '15 at 18:49
  • Yoonix, no. Requests are going straight to our VM as far as we know. We'll double-check. – Chris Williams Mar 13 '15 at 19:17

Probably the network configuration files are not correctly set. More details about them can be found here: http://docs.oracle.com/cd/E37670_01/E41138/html/ch11s02.html


It turns out it was the xinetd part of our configuration that was doing this. I'm going to close this question and ask another one specifically asking about that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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