Magento 2 .maintenance.ip file is not working behind Varnish + Nginx

[franckgarnier21]

Preconditions

Magento 2.1.X
Varnish
Nginx
Test on a real webserver, not in local

Steps to reproduce

Browse your website before in order to put some page in Varnish cache
Enable maintenance mode via ssh , once in the application folder
php bin/magento maintenance:enable --ip=xxx.xxx.xxx.xxx

different from local IP 127.0.0.1 which works.

Expected result

1. Able to access my website while in maintenance mode with the specified IP
2. Unable to access my website from another IPs while in maintenance mode.

Actual result

1. Unable to access my website from any IPs.
2. Able to access my website from any IPs if the page is already cached by Varnish

Cause 1

Varnish forward the real customer IP through the X-Forwarded-For header.
Mange 2 bootstrap do not check this header but $isOn = $this->maintenance->isOn(isset($this->server['REMOTE_ADDR']) ? $this->server['REMOTE_ADDR'] : '');

Workaround 1

Update Nginx configuration in order to set the real customer IP

set_real_ip_from    127.0.0.1; #Put the Ip of your varnish/proxy here
real_ip_header    X-Forwarded-For; #Put the Header that your varnish/proxy set

Cause 2

If a user access the website with an allowed IP, Varnish will cache these pages. So other customer with forbidden IPs will be able to access the website which is supposed to be in maintenance!

Workaround 2

Magento needs to add some response header in order to communicate with Varnish that the page is currently in maintenance mode and should not be cached or not be server for other IPs.

Related issues

#4219
#7596

[behnamshayani]

should be fixed in this PR: #7864

[franckgarnier21]

Thanks for sharing your PR.

@behnamshayani Indeed, this PR will fix the first part of this issue but not the second.

If a customer access to my website in maintenance mode, Varnish will cache some pages.
Then if another customer with an IP not allowed in maintenance mode, he will be able to reach the pages cached by Varnish, so it is not the result expected.

Magento needs to communicate with Varnish in order not to cache pages only for authorized customer during maintenance.

Is it clear enough ?

[maderlock]

Would you suggest that when entering maintenance mode that varnish is informed by some message that temporarily disables caching? That would be ideal.

The alternatives are:

1. Varnish always checks with the origin server whether in maintenance mode - this call is going to slow down return of cached pages as a full round trip to the origin server will be needed
2. PURGE is used, and 503s should already not be cached, but that seems heavy handed in case your reason for entering maintenance mode does not affect the content of the pages already cached.

[Brikner]

I faced the same issues as Franck with a similar configuration, except I'm running Apache 2.4 on CentOS 7. After several days and much gnashing of teeth, I came up with solutions that appear to work for me (ymmv). In the hopes of saving someone else some time...

To pass the real customer IP address to the PHP scripts:

I added the following lines to my Apache config file (which in my case is httpd.conf):

LoadModule remoteip_module modules/mod_remoteip.so
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1

Then restarted Apache.

To bypass the Varnish cache while in maintenance mode:

I added the following line to my Apache config file:

Header set Cache-Control "max-age=0, private, no-cache, no-store, must-revalidate"

Then restarted Apache and Varnish (which appears to be an easy way to clear the cache).

To re-enable the Varnish cache after leaving maintenance mode:

I commented out the line above that I added to my Apache config file:

# Header set Cache-Control "max-age=0, private, no-cache, no-store, must-revalidate"

Then restarted Apache.

[Brikner]

Hmm. It seems that I sometimes need to clear the cache with the Magento CLI as well...

magento cache:flush full_page

Don't know if other cache types might be relevant.

[magento-engcom-team]

@franckgarnier21, thank you for your report.
We've created internal ticket(s) MAGETWO-84874 to track progress on the issue.

[m2-assistant]

Hi @ihor-sviziev. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
• 2. Verify that the issue is reproducible on 2.4-develop branch
     Details

     - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
     - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
     - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[ihor-sviziev]

Hi @franckgarnier21,
It seems to me as the issue was already fixed in the scope of #25790.
Could you confirm that it's fixed already?

[ihor-sviziev]

Hi @franckgarnier21,
I'm closing this issue due to inactivity. Feel free to drop here a comment if this issue still relevant

[cmuench]

https://dev98.de/2017/01/02/how-to-add-alternative-http-headers-to-magento-2/

[tuyennn]

@cmuench Thanks for pointing me out the great solution for this current problem. And indeed, I don't know why this issue was closed