XF 2.3 "Please enter a value using 16 characters or fewer" on login when real IPv6 comes through (Cloudflare)

Yenxji

Well-known member
I've been issue with this IP/Cloudflare headache for a while and finally got real visitor IPs working properly. It can cause breaks login for anyone on IPv6.


1770855192460.webp

Here my CloudFlare Network settings:
1770855298396.webp

Here is my own server:
  • XenForo 2.3.9 (latest version)
  • Plesk at AlmaLinux backend with Apache & Nginx together
  • Separate proxy server for VPS at CloudPanel and Nginx
  • Cloudflare for proxy orange enabled

Real IPs are CF-Connecting-IP header and mod_remoteip (or nginx real_ip that I have tested). Current visitors members shows correct IP.

The issue:
When Cloudflare Pseudo IPv4 is set to Off, may shows users on real IPv6 connections but when people tried to login and failed caused this:

Oops! We ran into some problems.
Please enter a value using 16 characters or fewer.

A lot of people have reported that issue known caused by Pseudo IPv4 disabled/off at cloudflare. I have no clue but when pops up after submitting the login form (redirects to /login/login). IPv6 users can't log in at all. IPv4 users are completely fine. Fip Pseudo IPv4 to Overwrite Headers -> IPv6 gets mapped to short 250.xxx.xxx.xxx addresses, and login works perfectly again.

Important: This is isn't a passkey related. I have tested this on browser incognito mode and different browser (Edge, Opera, Chrome). I've tried cleared caches, rebuilt everything, no weird errors in logs, restarted NGINX, Apache service. Proxy passes the header cleanly. Also addons are currently disabled and still same the issue. Anyone there who have issue this with real IPv6 on normal logins? Is there some leftover IPv4 assumption somewhere in session/CSRF handling?

I would like to have run without Pseudo IPv4 overwrite headers if possible that can show real IPs would be nice.
 
Solution
All code paths in XF support IPv6 automatically. We use binary for storing IP addresses which is 4 bytes for IPv4 and 16 bytes for IPv6. So any IPv6 address that is correctly formatted should fit in that field.

The exception here would be if there's an add-on that either changes the formatting or, for some reason, the addresses coming through Cloudflare are malformed / longer than 16 bytes.

Unfortunately, not a lot we can do in either of those cases.
@Chris D Could you please take a look at this?

Users are unable to log in when their real IPv6 addresses come through Cloudflare. The validation error "Please enter a value using 16 characters or fewer" appears to be rejecting IPv6 addresses that exceed the character limit in the database field.

This is affecting real users and appears to be a core validation bug with IPv6 handling on the reverse proxy server.

I've been trying to figure this out for over 8 days and still couldn't solve this issue
 
All code paths in XF support IPv6 automatically. We use binary for storing IP addresses which is 4 bytes for IPv4 and 16 bytes for IPv6. So any IPv6 address that is correctly formatted should fit in that field.

The exception here would be if there's an add-on that either changes the formatting or, for some reason, the addresses coming through Cloudflare are malformed / longer than 16 bytes.

Unfortunately, not a lot we can do in either of those cases.
 
Solution
All code paths in XF support IPv6 automatically. We use binary for storing IP addresses which is 4 bytes for IPv4 and 16 bytes for IPv6. So any IPv6 address that is correctly formatted should fit in that field.

The exception here would be if there's an add-on that either changes the formatting or, for some reason, the addresses coming through Cloudflare are malformed / longer than 16 bytes.

Unfortunately, not a lot we can do in either of those cases.
Thank you very much, and the problem is that my add-on is storing IPv6 addresses as strings before converting them to binary format. When an IPv6 address comes through (which can be 39+ characters in string format), it triggers the validation error because it's checking the string length before the binary conversion happens. I've fixed my add-on that would need to convert IP addresses to binary format using \XF\Util\Ip::convertIpStringToBinary() before attempting to save them to the database. This matches how XenForo core handles IP addresses, so they are always converted to binary (4 bytes for IPv4, 16 bytes for IPv6) before storage
 
Back
Top Bottom