Reverse Proxy IP Header selection not working

[JazzyNL]

Hi,

We recently migrated from 2.0.15 to 2.1.3, we lost some of the previous administrators so decided to leave most of the customization behind and start with a clean slate. One issue that I have not been able to resolve is that the IP address of the reverse proxy is logged instead of the actual client IP.

As far as I know the reverse proxy adds a X-Forwarded-for header, so I went to Server Settings, Maintenance and under Reverse Proxy IP Header, I selected X-Forwarded-For. In the Reverse Proxy Servers IPs box I added the IP address that we currently see, a 192.168.x.x IP address.

This does not work. All activity is still logged with the IP address of the reverse proxy.

Next I added the following code in index.php:
if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){
    $_SERVER['HTTPS']='on';
    $_SERVER['REQUEST_SCHEME']='https';
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
}

This seemed to work, the actual client IP address now appears with each post. Unfortunately this introduced an other issue, we saw frequent Critical errors:

Wrong value type sent to the database. IPv4 or IPv6 expected.(ip)
Function: writeLog

This happens for functions writelog and is_not_banned. Unfortunately I lack php knowledge and do not know what to change to the code to resolve this. But ideally I would want to use the board's native feature, which doesn't seem to work either.

Board url: https://www.htforum.nl/yabbse/index.php

[JazzyNL]

Forgot to add the information from php.info:

Showing the reverse proxy address:
$_SERVER['REMOTE_ADDR']

Showing the actual client IP address:
$_SERVER['HTTP_X_FORWARDED_FOR']
$_SERVER['HTTP_CF_CONNECTING_IP']
$_SERVER['HTTP_X_REAL_IP']
$_SERVER['HTTP_CLIENT_IP']

Maybe relevant, the reverse proxy seems to perform SSL ofloading:
$_SERVER['SERVER_PORT'] 80
$_SERVER['HTTP_X_FORWARDED_PROTO'] https

[JazzyNL]

Gentle kick. Someone know why this feature doesn't work on our board?

[Arantor]

What did you set it to?

[JazzyNL]

What did you set it to?

Tested all four options, none worked.

[Arantor]

Try it without putting the revere proxy server IP in the box.

[JazzyNL]

Try it without putting the revere proxy server IP in the box.

I just tried. Makes no difference, unfortunately.

The weird thing is, php.info shows the correct values to it's not a server issue. Is this feature depending on anyting else that could be missing on my server?

[Arantor]

PHP info shows the correct values for which fields, exactly?

[JazzyNL]

PHP info shows the correct values for which fields, exactly?

The correct values for HTTP_X_FORWARDED_FOR, HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP and HTTP_CLIENT_IP.

For me this confirms that the reverse proxy provide the rigth headers, it's the board's feature that fails to use them and display on of those instead of the default REMOTE_ADDR address.

[Arantor]

Well, SMF internally has always taken two - historically both REMOTE_ADDR and HTTP_X_FORWARDED_FOR so that you couldn't just ban evade with a proxy.

What I don't get is why I don't replicate the behaviour you have - I'm behind CloudFlare too (the CF_CONNECTING_IP header is a giveaway) and... it just works as expected for me, though I don't tend to bother putting in the revere proxy IP.

But I'm wondering if you have a second proxy on there or similar and SMF is getting hung up on an intermediate?

[JazzyNL]

But I'm wondering if you have a second proxy on there or similar and SMF is getting hung up on an intermediate?

There's no second proxy. And please help me understand, if php.info shows the right values for all four IP address parameters, where would SMF obtain it's information and potentially getting hung up?

Also, is there another way you could recommend me to get support for this issue? I understand that SMF is supported through the community, but at this point this seems to be a SMF bug or issue and you're the only person who even responded to this thread. I'm grateful, don't get me wrong, but this is an impacting issue for our board and needs to be resolved.

[Arantor]

So let's recap. When it hits phpinfo, REMOTE_ADDR should contain the CloudFlare IP, and the others should contain the real IP. Seeing your post on this made me go look a bit deeper at what the code is actually doing.

What's weird is that my host apparently fixes this - which is why I'd never noticed a problem with it before, because php_info on my host serves up HTTP_CF_CONNECTING_IP and HTTP_X_FORWARDED_FOR as my real IP - but also REMOTE_ADDR.

I've never looked at this part of the code before, I'd assumed it would work as expected but actually... it can't.

It sets up $_SERVER['BAN_CHECK_IP'] as a secondary IP address (i.e. one step up the chain to find proxy ban evaders), but it never actually resets $_SERVER['REMOTE_ADDR'].

I'd suggest changing the lines in QueryString.php:

Code Select Expand

$_SERVER['BAN_CHECK_IP'] = trim($ip);

Code Select Expand

$_SERVER['BAN_CHECK_IP'] = $_SERVER[$proxyIPheader];
to both reference $_SERVER['REMOTE_ADDR'].

I'm also not 100% sure of the IPv4-over-6 code in there, it feels like it runs at the wrong point in the cycle and potentially does nothing with the output but that's a different question entirely.

This has also been noticed in the past, in https://github.com/SimpleMachines/SMF/pull/7368 but there's a misunderstanding on all sides that prevented it from being merged (and wouldn't work quite the way I'm suggesting)


Edit: filed as https://github.com/SimpleMachines/SMF/issues/7684

[Aleksi "Lex" Kilpinen]

So, I replicated all of this in my test environment. I could not get SMF to fix the IP, I was however fairly easily able to get Apache to fix the IP before it ever gets to SMF. This is probably something along the lines of what Arantor's host is doing. https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

[Arantor]

It's still wrong, though: if you're telling it to use an external proxy source to get the IP, it should use that IP!

[Aleksi "Lex" Kilpinen]

Yes, I agree! Just noting that there is a possible workaround. As well as an explanation to why this might have gone unnoticed.

[JazzyNL]

Thanks both. And apologies for abandoning the thread for a while, there were other priorities in life. Glad to see confirmation that I'm not the only person where SMF is not able to display any IP other than $_SERVER['REMOTE_ADDR'].

@Arantor: Just to clarify, this primarily has nothing to do with banning or working around a ban. It's much more basic than that, SMF is displaying the wrong IP-address at the left side of each user's post. Since the wrong IP address is logged in the DB too, there's a myriad of additional challenges but that's more the result of the original problem.

And like I said before, from the php.info we know that the alternative IP address values are in the requests. It's just the SMF feature to use those that seems to be broken.

[Arantor]

this primarily has nothing to do with banning or working around a ban

I know that's not your primary consideration, but I'm deliberately pointing it out because it's directly relevant to SMF's ban system.

SMF tracks two IP addresses for users - the first one is the primary and this gets funnelled into posts etc. but the *second* is used as a secondary for checking that individuals aren't using proxies to evade bans.

This is directly relevant because while the primary is REMOTE_ADDR, the secondary is hardcoded to look for the presence and contents of X-Forwarded-For. Which in your case is *correct* while REMOTE_ADDR is not. So changing this logic has consequences for the ban system too for other users.

[JazzyNL]

This is directly relevant because while the primary is REMOTE_ADDR, the secondary is hardcoded to look for the presence and contents of X-Forwarded-For. Which in your case is *correct* while REMOTE_ADDR is not. So changing this logic has consequences for the ban system too for other users.

Makes perfect sense. It would be helpful to understand how the new logic in 2.1.3 is supposed to work, with the new dropdown list that was added to the admin options (Server Settings, Maintenance, Reverse Proxy IP Header). I'm not a dev unfortunately so I guess we're depending on the people who developed this feature.

Is there anywhere I should raise this to get some traction? Sorry for asking, have no idea how bugs are being tracked for this project.

[Aleksi "Lex" Kilpinen]

#7684

[JazzyNL]

I just came back to edit my post, had found it too.