Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 client IP not updated when using KeepAlive #37

Open
jonmz opened this issue Dec 30, 2015 · 7 comments
Open

IPv6 client IP not updated when using KeepAlive #37

jonmz opened this issue Dec 30, 2015 · 7 comments

Comments

@jonmz
Copy link

jonmz commented Dec 30, 2015

Currently using the "stable" tree we were facing the problem that only the first request has the real client IP correctly transferred into REMOTE_ADDR when using KeepAlive. Further requests received the unchanged proxy IP, until the KeepAlive timeout value has been reached.

After stumbling upon Issue #35 we changed from "stable" to the current "master" tree, which effectively fixed the problem - but, amazingly, only for IPv4 addresses: IPv6 addresses still only got correctly set on every first request ever or after reaching the KeepAlive timeout. We're testing with the following PHP script:

<?php
echo $_SERVER['REMOTE_ADDR'];
echo "<br>";
echo $_SERVER['HTTP_X_FORWARDED_FOR'];
?>

Result on the first request is (correctly):

2001:470:1f0b:c02:888e:911b:c753:38a0
2001:470:1f0b:c02:888e:911b:c753:38a0

Result on every next request within the KeepAlive timeout results in (185.26.156.43 is the proxy IP listed as RPAF_ProxyIPs):

185.26.156.43
2001:470:1f0b:c02:888e:911b:c753:38a0

As a workaround we're currently having to turn off KeepAlive; in this case mod_rpaf provides correct results for both IPv4 and IPv6. Is there any chance to fix this?

@mpdude
Copy link
Contributor

mpdude commented Dec 31, 2015

Check 71a17f2 and see #35 for a similar report.

@jonmz
Copy link
Author

jonmz commented Dec 31, 2015

I already did that; see my second paragraph. By switching from stable to master, 71a17f2 is included in my source and fixed the problem for IPv4 IPs. It did not fix the problem for IPv6 IPs, thus this issue.

@mpdude
Copy link
Contributor

mpdude commented Dec 31, 2015

Oh, sorry, missed that!

@BenSjoberg
Copy link
Contributor

Explanation and proposed fix in #45. :)

@gnif
Copy link
Owner

gnif commented Dec 20, 2016

This issue may have been fixed with @BenSjoberg patch which has now been merged, can you please confirm if you are still experiencing the issue still?

@AndreiG6
Copy link

Would this fix have any impact on #42 ?

@pkramme
Copy link

pkramme commented Sep 2, 2024

Interestingly, on current master this problem reappeared for me. On new connections:

X-Real-Ip: 167.71.xx.xx
X-Forwarded-Proto: https
X-Forwarded-Port: 443
X-Forwarded-Host: example.com
X-Forwarded-For: 167.71.xx.xx

Second request on same connection:

X-Real-Ip: 167.71.xx.xx
X-Forwarded-Proto: https
X-Forwarded-Port: 443
X-Forwarded-Host: example.com
X-Forwarded-For: 167.71.xx.xx, fddb:cfc2:e3c3:1:0:101:0:1

Turning off keep-alives helped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants