IP Address

This is the error I’m getting: “The remote website encountered the following error: Unauthorized access (invalid remote IP address 000.000.000.00) – https://example.com”

Note: The above IP is not what shows in the error, but security reasons I change it with the zeros.

Thank you

And, when I looked up the IP Address since I don’t recognize it, it’s not showing that any organization owns it.

Thanks

Hi,
The plugin does not and cannot assign IPs. This is all dependent on the network between the 2 servers (proxys, CDNs like Cloudflare, etc). As this may be different for each install, and is more of a server & configuration issue, this cannot be addressed here.

• This reply was modified 1 month, 3 weeks ago by Alexandre Froger.

Hello @frogerme, thank you for the response.

A curious and security question: Technically, I should know my IP Addresses from the remote sites and not necessarely find it in the logs of the plugin… So, is it safe to think that the plugin may be operating on privately assigned (not routable on the internet) IP Addresses that someone can only know by the logs? Since you noted that, “To find the IP addresses (of the remote sites), use the “Test” button on remote sites while Logs are enabled and check the local log results.”

The IP Address showing in the error logs is not an IP Address that I recognized and could not confirm whether it belongs to either my server or CDN provider. Any IP Address that comes up in events like this usually, I’m able to track that and confirm who owns it and know whether they belong to my server or CDN provider.

Thank you!

• This reply was modified 1 month, 3 weeks ago by xtensions.
• This reply was modified 1 month, 3 weeks ago by xtensions.

The line “To find the IP addresses (of the remote sites), use the “Test” button on remote sites while Logs are enabled and check the local log results.” is here to account for CDNs and proxies that can be hit along the way when the sender’s request reaches destination and give some indication (but nothing guaranteed) to configure the plugin; that’s pretty much it. The plugin does not manipulate anything on the network: it takes what it gets and rolls with it to check what it can.

I guess you could check with another source: if the source IP detected at destination is the same, then you would know that something is happening internally on the destination’s server.

The rest is entirely dependent on the servers’ setup, something that is I am afraid out of scope of this forum.

• This reply was modified 1 month, 3 weeks ago by Alexandre Froger.

@frogerme The fact is that all the sites are running on the same server. However, the IP address that is coming up in the error logs is not the one of the server. WHOIS is showing that the strange IP address as reserved IP address. And when I contacted our server provider, they also confirmed that the IP address is a class E IP address range and is generally reserved for experimental purposes.

Do you use experimental IP addresses to test your plugin? At this point I’m wondering if the IP showing in the error logs is not of the server, our CDN provider, and data center or server provider, and is not being detected or showing in any other plugins on the sites, then it must be particular or related to your plugin. Any suggestions?

Thank you.

My suggestion would be for you to investigate the code: the plugin only uses the standard $_SERVER['REMOTE_ADDR']. Nothing more. No IP manipulation.

You could use a code snippet plugin and output the $_SERVER variable somewhere in the php logs, on screen, a file, etc. You could test several cases (calling the homepage from a browser, on VPN or not, then calling the homepage with a request in code from the problematic remote server with wp_remote_get function for instance, and compare the content of the variable). There could be many ways to do that. All of them that I can think of involve code. If you are not a programmer, I would invite you to hire the services of one.

I cannot troubleshoot your specific server installation. Feel free to report back if you find an explanation to your issue, and a solution.

• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.

Hello @frogerme, do you think DHCP (Dynamic Host Configuration Protocol) can also be the challenge in this? Does your plugin require Static IP Address to work?

Strangely, I have noticed a new or another IP Address in the error logs of WP Remote Users Sync, which is different from the first one that was showing in the error logs, and not the IP addresses of the server. The error says, “The remote website encountered the following error: Unauthorized access (invalid remote IP address XXX.XXX.XXX.XXX) – https://xxxxxxxxxx.com

Thank you

• This reply was modified 1 month, 2 weeks ago by xtensions.

Hi xtensions,

Web hosting environments are generally set up so that—even if DHCP is used internally—the IP address that external sites see remains consistent and controlled by the host.

How DHCP Is Used by Web Hosts

• Internal vs. External IPs:
  Many web hosts might use DHCP within their internal networks to assign IP addresses to servers or devices dynamically. However, these internal IP addresses are not usually the ones used for communicating with the public Internet.
• Public (Static) IP Addresses:
  Outgoing requests from a web server are typically sent from a public IP address that is either statically assigned or managed in a way that it appears static to the outside world. Even if the server’s internal IP is assigned via DHCP, Network Address Translation (NAT) or other routing mechanisms ensure that external requests use the public IP address provided by the hosting provider.

Impact on $_SERVER[‘REMOTE_ADDR’]

• What $_SERVER[‘REMOTE_ADDR’] Represents:
  On the receiving end of an HTTP request, $_SERVER['REMOTE_ADDR'] contains the IP address of the client making the request. In the context of a request from one server to another, this will be the public IP address of the originating server.
• DHCP’s Role:
  Whether a web host uses DHCP to manage its internal network does not affect the public-facing IP address. The public IP—what shows up in $_SERVER['REMOTE_ADDR']—is determined by the outgoing interface (and any intervening NAT or proxy), not by the internal DHCP process. Thus, even if the web host uses DHCP internally, the external request’s IP address remains that of the server’s public interface.

I don’t see why DHCP would have an impact here. Either way, this is a conversation you should be having with your sys admin, not on this forum.

Please avoid using @ unless you have found an explanation or a solution for your specific setup.
I cannot afford to be involved with troubleshooting issues specific to the servers and networks where the plugin is installed.

• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.

Hello. Thanks for the reply.

I’m just trying to understand why is only in your plugin that those reserved IP addresses are showing. Usually, these would be our CDN or proxy provider IP Addresses showing. I contacted our server provider also and they confirmed that those IP Addresses are reserved IP Addresses that don’t belong to them and were not supposed to be in operation by anyone since they are reserved for experimental purposes.

I doubt those reserved IP Addresses are coming from our server because many other web applications running on the same server either show the server’s IP Addresses or the proxy IP Addresses… In this case, the plugin is just showing these resevered IP Addresses that don’t belong to the server provider, or the CDN provider.

Also, I have noticed a couple of people ran into the same type of issue and posted support requested, but unfortunately there were no replies to those support queries so it seems be a dead end.

Thank you

Hi xtensions

I understand the frustration. It is also present on my side, since I cannot reproduce the behavior at all. All I can do is inform you of how the plugin operates, and there is no more standard way than what it does: use $_SERVER[‘REMOTE_ADDR’]. Other headers could be checked but they may be tricky to rely on, so instead I make the IP whitelist an extra safeguard, not a requirement, and mostly rely on strong encryption of the communications. Security in layers and all that.

I would advise you to consider checking the following headers and see if the real IP is in there, using something like:

// Add an action to the init hook
add_action( 'init', function () {

    // Check if the wprus_log function exists and if the request is for the wprus plugin
    if (
        ! function_exists( 'wprus_log' ) ||
        false === strpos( $_SERVER['REQUEST_URI'], '/wprus/' )
    ) {
        return;
    }

    // Initialize the possible headers that can contain the IP
    $headers = array(
        'HTTP_CF_CONNECTING_IP',
        'HTTP_CLIENT_IP',
        'HTTP_X_FORWARDED_FOR',
        'HTTP_X_FORWARDED',
        'HTTP_X_CLUSTER_CLIENT_IP',
        'HTTP_FORWARDED_FOR',
        'HTTP_FORWARDED',
        'REMOTE_ADDR',
    );

    // Loop through the headers and check if the IP is valid
    foreach ( $headers as $header ) {

        // Check if the header is set
        if ( ! empty( $_SERVER[ $header ] ) ) {
            // Split the IP list
            $ip_list = explode( ',', $_SERVER[ $header ] );
            // Get the first IP
            $ip = trim( $ip_list[0] );

            // Check if the IP is valid
            if (
                filter_var(
                    $ip,
                    FILTER_VALIDATE_IP,
                    // Exclude private and reserved ranges
                    FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE
                )
            ) {
                // Log the IP
                wprus_log( "Found a proper IP [$ip] for header [$header]", 'info', 'db_log' );
            } else {
                // Log the invalid IP
                wprus_log( "Private, reserved, or invalid IP [$ip] for header [$header]", 'info', 'db_log' );
            }
        } else {
            // Log that the header is not set
            wprus_log( "Header [$header] is not set", 'info', 'db_log' );
        }
    }
} );

You can use the Code Snippets plugin for that, for example. Then, from there, you could report here, and we could work together in finding ways to maybe use the header that works in your case. But please, never blindly copy-paste code you see online, this one included: understand and double-check it, maybe with AI tools, better with a professional.

That’s what I mean by hiring a programmer or a sysadmin, or devOps. The issue you are describing here is not preventing the plugin from working safely, is about an optional feature, is specific to your install, and requires studying the code (and producing some, as seen above) to troubleshoot, which takes up resources (time being one of them).

I sincerely hope you find the source and suggest a fix for the issue, so that it can be a contribution for the other users you mention as well.

Hello.

I should also add though… That while the connection testing under “Remote Sites” has been failing and showing the unknown and reserved IP addreses, the cross login itself is working… For example, if I login one site, it automatically logs me in all the sites.

One thing I also noticed is that when I login the first site, it tries to redirect me to the second site… I’m not sure where that redirect is coming from, but I will check on that and keep you updated.

To the IP showing in the header report… I checked the header and confirmed that the remote IP Address showing is one of our CDN/Proxy provider’s IP Addresses.

I don’t mind whitelisting an IP Address, but my concern is allowing an IP Address that I don’t know who it belong to since it shows is a reserved IP Address that is only reserved for experimental purposes.

Do you have a support email or how can I send you that IP Address that the plugin is showing so you can also evaluate it?

Thank you

• This reply was modified 1 month, 1 week ago by xtensions.

Hi xtension!

Glad you found the source of this IP!
It is as suspected: part of the network setup, and not related to WPRUS proper.

This plugin is free, and does not have a premium tier. It is maintained, but it is up to you to spend the resources to integrate it with your specific environment.

A stated in the main plugin page’s description:

Each bug report will be addressed in a timely manner if properly documented – previously unanswered general inquiries and issues reported on the WordPress forum may take significantly longer to receive a response (if any).

Only issues occurring with included plugin features mentioned in “Synchronise all user data”, core WordPress and default WordPress themes (incl. WooCommerce Storefront) will be considered.

Only bugs are addressed, if and only if properly documented ; they are addressed either here or on Github, but must have a reliable way to be reproduced with 2 minimal installs of WordPress ; better if the report actually pinpoints where in the code it occurs (and unlikely to be addressed otherwise).

There is no email support, no troubleshoot of user installs, no experimenting and testing based on non-technical or anecdotal description. This would be the case if I closed the plugin here and charged for updates, maintenance, and hands-on support, which I have no plan to do so far. This is why you need to find your own proper technical support. I am including this here to manage your expectations regarding the redirect issue you’re referring to in your last message.

When you have been able to properly document your issue, you are welcome to open a new topic, I would be glad to improve the plugin for everyone.
I am considering this one as resolved.

Best,
Alexandre Froger

Hello.

The issue is not resolved.

You misunderstood the second part of my reply… The reserved IP Addresses the plugin is showing in the error logs ARE NOT part of our server/network or website… That was in response to your suggestion to check the header to confirm the real IP address of the website. So, I was saying that I have confirmed that the headers are showing the real IP Address of our CDN/Proxy provider as it should be. In other words, the plugin was supposed to be showing that IP Address from our CDN/Proxy provider and not an unknown reserved IP Address.

Also, nothing was noted about the redirect action I mentioned. What’s the best way to handle the login redirect since the plugin seems to be redirecting to the first subsite after login? I saw “show_welcome_panel” under “List of metadata to transfer”. But leaving that empty does not still resolve the redirect to the subsite either.

Thank you

• This reply was modified 1 month, 1 week ago by xtensions.
• This reply was modified 1 month, 1 week ago by xtensions.
• This reply was modified 1 month, 1 week ago by xtensions.

Oh I think I did understand: if any of the headers I suggested to test (and it would be useful to know which one) is showing the right IP, it does mean that, internally, on the network somewhere, the header with the REMOTE_ADDR key was set to a different value.

How, I can’t know, and I don’t think it matters in the context of WPRUS ; that IP is what is set in REMOTE_ADDR everywhere else on the receiving site when a request from your source site is received (and possibly in other cases). If this is a concern for you, then you may want to keep investigating, by sending test requests yourself from the source site with your own code, and checking the headers on the receiving site in your own code (no need to rely on WPRUS in any way for that, and it is entirely out of scope).

Anyway ; now that you know what header to check, you can create your own plugin, or a code snippet, and use the provided filters, something like:

// add this code during init hook, with a priority greater than PHP_INT_MIN + 100
// change 'MY_HEADER_KEY' to the header value you want to check
add_action(
    'init',
    function () {
        add_filter(
            'wprus_is_authorized_remote',
            function ( $is_authorized_remote, $method, $remote_addr, $ip_whitelist ) {
                $header_to_check = 'MY_HEADER_KEY';

                if (
                    $is_authorized_remote ||
                    'POST' !== $method ||
                    ! isset( $_SERVER[ $header_to_check ] )
                ) {
                    return $is_authorized_remote;
                }

                $ip    = $_SERVER[ $header_to_check ];
                $match = function ( $ip, $range ) {
                    list ( $subnet, $bits ) = explode( '/', $range );
                    $ip                     = ip2long( $ip );
                    $subnet                 = ip2long( $subnet );

                    if ( ! $ip || ! $subnet || ! $bits ) {
                        return false;
                    }

                    $mask    = -1 << ( 32 - $bits );
                    $subnet &= $mask; // in case the supplied subnet was not correctly aligned

                    return ( $ip & $mask ) === $subnet;
                };

                foreach ( $ip_whitelist as $range ) {

                    if ( $match( $ip, $range ) ) {
                        $is_authorized_remote = true;

                        break;
                    }
                }

                return $is_authorized_remote;
            },
            10,
            4
        );
    },
    PHP_INT_MIN + 50
);

This is a proof of concept based on the documented wprus_is_authorized_remote filter.
The same piece of advice as before applies: do not simply execute code pasted here. Review it, understand it, and only then consider using it.

Cheers