Multiple layers of load balancers in 4.0

[niclashedam]

Our setup has multiple LB IP addresses, first a local one 10.* and then a public one 130.*. Lastly the users IP. This means that TrustedProxy should filter out 10.* and 130.*, but no matter what I do, it only filters out the first IP.

Everything worked correctly in version 3.*, but after upgrading to 4.*, it stopped working. Doesn't TrustedProxy support multiple layers of load balancers anymore?

Our environment is Google Cloud Platform with Laravel 5.6 and PHP 7.1.

[niclashedam]

When I call Request::ips() I get an array of two IPs, where index 0 is 130.*.

    protected $proxies = '*';

[fideloper]

Hi! I hope they do! The changes made in symfony has been a bit confusing (and buggy, I’ve had to file a few bug reports on it myself). It’s possibly a bug that it’s not catching the correct client IP address in a chain of proxies. Question: Are the trusted proxies you have set a chain of proxies? If that is a chain, I believe you’d only need to trust the proxy that is directly sending requests to your app servers (rather than the full chain). However, that may not help the issue of Request::clientIp() returning the wrong IP address! Can you dump out there $_SERVER array your app server receives? I’m specifically curious about what the headers received look like so I could recreate that and see if there’s a bug on my end, symfony’s end, or just a change in how trustedproxy needs to be configured in that scenario. Thanks

…

On Thu, Feb 8, 2018 at 08:39 Niclas Hedam ***@***.***> wrote: When I call Request::ips() I get an array of two IPs, where index 0 is 130.*. [image: image] <https://user-images.githubusercontent.com/770169/35978526-474e1db6-0ce6-11e8-9217-639efd27289d.png> protected $proxies = [ '209.85.152.0/22', '209.85.204.0/22', '35.191.0.0/16', '130.211.0.0/22', '10.0.0.0/8', ]; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAch03iynWg1msABDCgdzzADM6ej6YaHks5tSwc9gaJpZM4R-cke> .

[niclashedam]

Hi, Sorry that I haven't responded until now.

Are the trusted proxies you have set a chain of proxies?

Yes.

I found out that if I only trust one level of proxies, then the next level will become the client IP.

  | [REDIRECT_STATUS] => 200
  | [HTTP_HOST] => xx
  | [HTTP_CACHE_CONTROL] => max-age=0
  | [HTTP_UPGRADE_INSECURE_REQUESTS] => 1
  | [HTTP_USER_AGENT] => Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
  | [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
  | [HTTP_DNT] => 1
  | [HTTP_ACCEPT_ENCODING] => gzip, deflate, br
  | [HTTP_ACCEPT_LANGUAGE] => en-US,en;q=0.9
  | [HTTP_X_CLOUD_TRACE_CONTEXT] => aa5a75e58e03d50cb323e452a4114e28/2672460875832957278
  | [HTTP_VIA] => 1.1 google
  | [HTTP_X_FORWARDED_FOR] => 185.206.224.209, 130.211.43.142
  | [HTTP_X_FORWARDED_PROTO] => https
  | [HTTP_CONNECTION] => Keep-Alive
  | [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  | [SERVER_SIGNATURE] => <address>Apache/2.4.18 (Ubuntu) Server at xxx Port 80</address>
  |  
  | [SERVER_SOFTWARE] => Apache/2.4.18 (Ubuntu)
  | [SERVER_NAME] => xxxxxxx
  | [SERVER_ADDR] => 10.76.3.44
  | [SERVER_PORT] => 80
  | [REMOTE_ADDR] => 10.132.0.4
  | [DOCUMENT_ROOT] => /var/www/public
  | [REQUEST_SCHEME] => http
  | [CONTEXT_PREFIX] =>
  | [CONTEXT_DOCUMENT_ROOT] => /var/www/public
  | [SERVER_ADMIN] => xxxxx
  | [SCRIPT_FILENAME] => /var/www/public/index.php
  | [REMOTE_PORT] => 63699
  | [REDIRECT_URL] => /login
  | [GATEWAY_INTERFACE] => CGI/1.1
  | [SERVER_PROTOCOL] => HTTP/1.1
  | [REQUEST_METHOD] => GET
  | [QUERY_STRING] =>
  | [REQUEST_URI] => /login
  | [SCRIPT_NAME] => /index.php
  | [PHP_SELF] => /index.php
  | [REQUEST_TIME_FLOAT] => 1519400295.321
  | [REQUEST_TIME] => 1519400295

[MichMich]

I'm seem to be having the same issue on an app running on AWS behind cloud front. The Request has the following headers:

REMOTE_ADDR: 172.16.1.231
HTTP_X_FORWARDED_FOR: 193.34.4.230, 54.240.150.52

The IP I'm looking for is 193.34.4.230. The IP I'm getting without any settings in TrustProxies is 172.16.1.231. If I use $poxies = '*', then I'm getting the 54.240.150.52. I'm unable to get the desired IP.

[fideloper]

Hi @MichMich !

Can you show me your laravel trustproxies middleware, and what version of laravel you're on? In your case, it sounds like it's not looking at X-Forwarded-For at all (instead of just grabbing the wrong IP from X-Forwarded-For).

[MichMich]

It seems to be working if I use multiple proxy options:

class TrustProxies extends Middleware
{
    /**
     * The trusted proxies for this application.
     *
     * @var array
     */
    protected $proxies = ['172.0.0.0/8', '54.0.0.0/8', '216.0.0.0/8'];

    /**
     * The headers that should be used to detect proxies.
     *
     * @var string
     */
    protected $headers = Request::HEADER_X_FORWARDED_ALL;
}

If I use '*', then I get the 172.16.1.231 ip. The above solution isn't ideal because I'm not sure of all the Amazon loadbalancing IP's.

[MichMich]

So, I did some digging and the following is the issue:

• Server is behind an Amazon Load Balancer
• The Load Balancer is behind Amazon Cloud Front

Because of this, my HTTP_X_FORWARDED_FOR contains 2 IPs.

In the previous version of TrustedProxies, this could be solved with: $proxies = "**" as stated in https://github.com/fideloper/TrustedProxy#configure-trusted-proxies

In version 4, ** doesn't have any effect. The only way to currently solve this, is by manually defining all proxies. But a wildcard would be preferable.

Any suggestions are welcome.

[MichMich]

Ah, rubber ducky debugging strikes again!

Using the following results in a wildcard for all proxies:

protected $proxies = ['0.0.0.0/0'];

[boynet]

@MichMich thanks, I couldn't find anywhere, what is the danger of just trusting all ips?

I am using cloudflare, and when user is using google date saver, I am also getting double ip list, but always the google one is used(HTTP_X_FORWARDED_FOR look like 0.0.0.0,1.1.1.1) where I couldn't get a list of all google ip address to trust them

[Justintime50]

@MichMich you're my hero! Been stewing on this same issue for multiple days. Thank you!

[antriver]

@MichMich Thanks! That solved my problem.

If you're using '0.0.0.0/0' (and maybe it needs Laravel 5.6?) you don't need to use this package at all.
In your AppServiceProvider.php boot() method (or somewhere similar if you prefer) you can put:

        Request::setTrustedProxies(
            [
                '0.0.0.0/0'
            ],
            Request::HEADER_X_FORWARDED_FOR
        );

and remove the TrustProxies middleware from your stack.

[pvledoux]

@MichMich Thank you! You saved my day. I spent literally 2h searching why a dockerized Laravel app was always generating http instead of https urls.

[MichMich]

Keep in mind this isn't very secure since it allows you to spoof the original IP address.

[gtjamesa]

I created a package that will "replace" the fideloper/proxy package: ge-tracker/laravel-vapor-trusted-proxies. It sits in front of fideloper/proxy to dynamically build the proxies array from the server-side Vapor headers, which change on every request. It also respects the proxies that you have configured which is safer than blindly trusting all proxies.