Menu

determining client IP address when behind cloudflared

n3tllama
2023-01-01
2023-01-06
  • n3tllama

    n3tllama - 2023-01-01

    I have an apache web server sitting behind CloudFlare's tunneling client (due to a NAT). As a result, all of the web traffic reaching apache has 127.0.0.1 as the REMOTE_ADDR (header value). I can determine the real remote client IP address using the remoteip module ( https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html ) by inspecting the content of the HTTP_CF_CONNECTING_IP header.

    However, mod_qos seems to only check the value of REMOTE_ADDR when making decisions about the client IP. I tried setting:

    QS_ClientIpFromHeader HTTP_CF_CONNECTING_IP

    but mod_qos continues to ignore that header when making decisions regarding the client IP address. I can see this problem when watching the qos-viewer console's "client ip connections" which never show anything other than 127.0.0.1 for every request. The apache access log entries are showing the real client IP (by inspecting the HTTP_CF_CONNECTING_IP header), so I'm certain that header is present and apache is aware of it.

    Am I misunderstanding how to make this work with mod_qos ?

    thanks!

     
    • Pascal Buchbinder

      QS_ClientIpFromHeader works for QS_ClientEventRequestLimit, QS_ClientEventLimitCount, QS_ClientSerialize, and QS_ClientGeoCountryDB. Directives working exclusively at the connection level can't read the IP address from a request header (as there isn't any).

       
  • n3tllama

    n3tllama - 2023-01-03

    ok, thanks. I tried switching to using QS_ClientEventRequestLimit, but now I'm seeing this error for every connection:

    [qos:error] [pid 939267:tid 939302] [client 38.242.155.167:0] mod_qos(069): no valid IP header found (@hp): header 'HTTP_CF_CONNECTING_IP' not available, fallback to connection's IP 127.0.0.1, id=Y7Rpcvro8TsUqQocyjD0UwAAAMc
    [qos:error] [pid 942833:tid 942865] [client 173.249.63.71:0] mod_qos(069): no valid IP header found (@hp): header 'HTTP_CF_CONNECTING_IP' not available, fallback to connection's IP 127.0.0.1, id=Y7RscmLLlk4HBZNA2dcSnQAAAQQ

    The real client IP is in the errors above, so I don't understand how qos isn't finding it.

    The config that I'm trying to use is:

    QS_ClientIpFromHeader HTTP_CF_CONNECTING_IP
    QS_ClientEntries 10000
    QS_ClientEventRequestLimit 25

    thanks

     
  • n3tllama

    n3tllama - 2023-01-03

    Per your suggestion, I changed to:

    QS_ClientIpFromHeader CF_CONNECTING_IP

    However, I'm still seeing errors which corectly identify the client IP, yet fail to match against it with the QS_ClientEventRequestLimit option:

    [qos:error] [pid 1006522:tid 1006612] [client 88.99.215.210:0] mod_qos(069): no valid IP header found (@hp): header 'CF_CONNECTING_IP' not available, fallback to connection's IP 127.0.0.1, id=Y7SqvDghNr9YAujDKT45dQAAAAM

    Do you have any other suggestions?

    thanks

     
    • Pascal Buchbinder

      Documentation says CF-Connecting-IP and not CF_Connecting_IP

       
  • n3tllama

    n3tllama - 2023-01-04

    Even with CF-Connecting-IP:
    QS_ClientIpFromHeader CF-Connecting-IP

    Its still not working:

    [qos:error] [pid 1165385:tid 1165434] [client 114.119.143.25:0] mod_qos(069): no valid IP header found (@hp): header 'CF-Connecting-IP' not available, fallback to connection's IP 127.0.0.1, id=Y7W7UCbdgDkVVxW1MdL-tAAAAZU

    The client IP in the error is correct, so why isn't mod_qos able to use that (somehow)?

     
    • Pascal Buchbinder

      Strange... any you configured what for mod_remoteip?

      RemoteIPHeader CF-Connecting-IP
      

      What do you see when you add the header to the access log?

      LogFormat "... %{CF-Connecting-IP}i ...
      
       
  • n3tllama

    n3tllama - 2023-01-04

    Yes, remoteip is configured with:

    RemoteIPHeader CF-Connecting-IP

    The access log is already configured to report the value of the CF-Connecting-IP header, and shows the correct (not 127.0.0.1) client IP. Prior to setting up remoteip, the access log only reported 127.0.0.1 for everything.

     
    • Pascal Buchbinder

      from https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

      if all IP addresses were trusted, this header is removed from the request altogether.

      and in the code:

          else {
              apr_table_unset(r->headers_in, config->header_name);
          }
      
       

      Last edit: Pascal Buchbinder 2023-01-04
  • n3tllama

    n3tllama - 2023-01-04

    OK, but how/where is mod_qos figuring out the correct client IP?

    From my example from a few hours ago, mod_qos correctly identified one client IP as 114.119.143.25. How can I force mod_qos to use that IP instead of falling back 127.0.0.1 when the client IP is not 127.0.0.1 ?

     
    • Pascal Buchbinder

      what if you add

      RemoteIPProxiesHeader CF-Connecting-IP
      
       
      • n3tllama

        n3tllama - 2023-01-04

        I added:

        RemoteIPProxiesHeader CF-Connecting-IP

        but it didn't change anything with respect to mod_qos. Its still treating every connection as originating from 127.0.0.1. The qos console shows only 127.0.0.1 for "client ip connections" even though the apache access log shows connections originating from many other IP addresses.

        Although mod_qos is no longer flagging the real IP address in the logs either.

         
        • Pascal Buchbinder

          Although mod_qos is no longer flagging the real IP address in the logs either.

          Means this modqos(069) error is gone and the problem could be solved?

          Please remember what I told you in the beginning: QS_ClientIpFromHeader works for QS_ClientEventRequestLimit, QS_ClientEventLimitCount, QS_ClientSerialize, and QS_ClientGeoCountryDB only.

           
          • n3tllama

            n3tllama - 2023-01-05

            Does not seem solved as the qos console still isn't showing the real client IP address, only 127.0.0.1.

             
            • Pascal Buchbinder

              Again: while it is possible to read an IP address for an HTTP request from a header field, this is not possible for TCP connections.

              QS_ClientEventRequestLimit, QS_ClientEventLimitCount, QS_ClientSerialize, and QS_ClientGeoCountryDB are using the IP address from the source defined by QS_ClientIpFromHeader (you find the mod_qos documentation here). Your configuration is now correct if the "069" errors are gone.

               
              • n3tllama

                n3tllama - 2023-01-06

                ok, thanks for all the assistance.

                 

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.