Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm testing a new web server setup which is having a couple of issues. Essentially, we have a web server, where the code uses the remote IP for some interesting things, and also some apache directories secured down to some certain IP's (our office etc).

However, we've just chucked this behind ha_proxy so we can look at adding some more app servers, but now the remote IP is always coming through as the proxy ip, not the real remote user. This means we can't get to some locations, and our app is behaving a little oddly where user IP is important.

Our config is as follows:

global
      maxconn 4096
      pidfile /var/run/haproxy.pid
      daemon

defaults
      mode http
      retries 3
      option redispatch
      maxconn 2000
      contimeout 5000
      clitimeout 50000
      srvtimeout 50000

listen farm xxx.xxx.xxx.xxx:80
      mode http
      cookie GALAXY insert
      balance roundrobin
      option httpclose
      option forwardfor
      stats enable
      stats auth username:userpass

      server app1 xxx.xxx.xxx.xxx:80 maxconn 1 check
share|improve this question

7 Answers 7

up vote 21 down vote accepted

Quoted from the HAProxy doc at haproxy.1wt.eu.

- if the application needs to log the original client's IP, use the
  "forwardfor" option which will add an "X-Forwarded-For" header with the
  original client's IP address. You must also use "httpclose" to ensure
  that you will rewrite every requests and not only the first one of each
  session:
        option httpclose
        option forwardfor

It is stated that the application must treat the X-Forwarded-For HTTP Header to know the client IP adress. Seems like the only way to go in your case.

Updated for HAProxy 1.4

Haproxy 1.4 introduced a new mode with "option http-server-close". It still closed the connection to the server but maintains keep-alive towards the client if possible and used. On most setups, you probably want to use that as it helps with latency on the single high-latency part of your connection (between Haproxy and the client).

   option http-server-close
   option forwardfor
share|improve this answer
    
Better use option forwardfor header X-Real-IP and reqidel ^X-Real-IP:, this stops faking IPs in your logs. FYI: X-Real-IP is the default header for NginX' option set_real_ip_from. –  Tino Aug 30 '12 at 23:44

Use rpaf apache module http://stderr.net/apache/rpaf/ I know this is and old post but it took me days to find this. This will present to any application the x-forwarded-for ip.

share|improve this answer

Try mod_extract_forwarded from http://www.openinfo.co.uk/apache/

LoadModule extract_forwarded_module modules/mod_extract_forwarded.so
MEFOrder refuse,accept
MEFRefuse all
MEFAccept xxx.xxx.xxx.xxx
share|improve this answer

There is a way to recompile HAproxy to include Tproxy which will allow forwarding of the source address.

There's a blog post here about it: http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/

A few notes:

The latest linux kernel (2.6.28-11-server) includes support for TProxy, so recompiling the kernel is not necessary.

Make sure to configure the servers in your web farm with a default gateway address which points to the HAProxy server.

share|improve this answer

Well, it seems that the X-Forwarded-for doesn't work well for your setup. So, is there any special reason for you to stick with haproxy? It seems that IPVS is more aproppriate for your needs (I actually use ldirector which in turn uses ipvs).

Take a look at:

http://kb.linuxvirtualserver.org/wiki/IPVS

and

http://www.vergenet.net/linux/ldirectord/

Using IPVS in 'IP Tunneling' or 'Direct Routing' mode preserves the client's address.

share|improve this answer

HAProxy, by design, can't forward the original IP address to the real server, pretty much like any other proxy.

One solution may be, if your only problem is with a web server, to look into the X-forwarded-for HTTP header, which should contain the client's address. Now, that's pretty much application/language specific, but take a look at this example in php:

$headers = apache_request_headers();

$real_client_ip = $headers["X-Forwarded-For"];

If you also want to log the original address, you can modify the LogFormat in httpd.conf to look something like this:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{X-Forwarded-For}i\"" common

share|improve this answer
    
wrong, you can with the option "forwardfor" –  wittwerch Jun 23 '09 at 15:18
    
Yes, and this option comes on by default, but what it does is setting the X-Forwarded-For HTTP header. What I was saying, and it looks to me that is what the asker was actually asking, was about the actual source address of the IP packet –  Thiagodrv Jun 23 '09 at 15:40

Note that it would appear that you can override what the application see's my changing the Apache headers:

SetEnvIf X-Forwarded-For (.*) REMOTE_ADDR=$1
SetEnvIf X-Forwarded-For (.*) REMOTE_IP=$1

However, this doesn't work for Apache access via "Allow from" etc.

share|improve this answer
    
This might cause unpredictable results if the client sends an existing X-Forwarded-For header as the new IP address is added to the end of the existing list, separated by a comma and a space. Change the (.*) to ([^ ]*)$ to only grab the last IP... or use mod_rpaf or mod_remoteip for Apache 2.4 or later. –  Ladadadada Aug 24 '12 at 15:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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