Fix IPv6 client IPs when the proxy uses KeepAlive #45
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think I figured out #37. It's because of how the original apr_sockaddr_t object is restored to the request_rec object during the cleanup process.
When a request is being processed, the original IP address is saved and the apr_sockaddr_t object is overwritten with a new one based on the IP in X-Forwarded for:
Then during the cleanup, rcr->old_ip is used to put the original IP address back into r->DEST_ADDR:
The problem is that when X-Forwarded-For contains an IPv6 address, r->DEF_ADDR->family is set to APR_INET6. When the connection is reused, r->DEF_ADDR is checked against RPAF_ProxyIPs to see if it's an authorized proxy, but it thinks it's checking against an IPv6 address, so it doesn't match. (If RPAF_ProxyIPs isn't set, this problem doesn't happen.)
Another problem is that apr_inet_addr() doesn't support IPv6 addresses, so the current code would also have issues when IPv6 is used to communicate with the proxy. Instead of reconstructing the address from r->DEF_IP, my solution is to just copy r->DEF_ADDR into a new member of rpaf_cleanup_rec, then copy it back during the cleanup process.