Jetpack attempting to connect from unexpected IP’s

Note: when we allow all connections to xmlrpc we still can’t connect, but receive a 504 from the reconnect endpoint at /wp-json/jetpack/v4/connection/reconnect

I deactivated, then re-activated the Jetpack plugin. Then I was able to make it all the way through the reconnection flow. Woocommerce is working now, which is our main concern. But we still see an error on the ‘My Jetpack’ page: “It looks like your Jetpack connection is broken. Try disconnecting from WordPress.com then reconnecting.” Could this be due to a 500 error requesting /wp-json/jetpack/v4/stats-app/sites/224773428/stats/highlights?_locale=user

Is there a way to resolve this error?

How can we be confident Jetpack (and therefor Woocommerce) will continue working?

Hi there. Your site does not appear to be publicly accessible at the moment, it is redirecting to a login page. Jetpack’s connection will not work properly if your site is not publicly accessible. Jetpack relies on WordPress.com’s servers to communicate with your site, which requires the ability to access your site’s XML-RPC endpoints. If your site is behind a login or otherwise restricted, these connections will fail.

As a first step, you’ll want to make sure your site is publicly accessible, then you can let us know if you continue to have trouble connecting.

Hi Dan,

Thanks for jumping in. I believe you are incorrect about the requirement that the site be public. Our site has never been public–it’s a company store, open only to employees, so the web UI is behind Okta SAML auth. Jetpack worked just fine until this week. Our XML-RPC endpoint was restricted to the IP’s on Jetpack’s published allow list until now.

Now I’ve had to make the XML-RPC endpoints fully public, deactivate and reactivate Jetpack, then complete the reconnect flow to get Jetpack + Woocommerce working. But we’ve still got Jetpack saying we’re not connected, though clearly we are, or Woo would not be working.

We shouldn’t have to make XML-RPC fully public. We should be able to allow only Jetpack by using the published IP’s, as described here: https://jetpack.com/support/how-to-add-jetpack-ips-allowlist/

It seems pretty clear something has changed on Jetpack’s end. There were no code or config changes on our end. We manage our own AWS ECS stuff, so it’s not a hosting issue.

Hi there, @grandpaslab,

Thanks for following up and providing more information. We ran some tests and changed how the connection between your servers and Jetpack is established.

We switched to an alternate endpoint instead of the traditional one, which seems to have fixed the connection.

Can you check at our end if you can now see the My Jetpack page and all the related Jetpack pages and features? I trust WooCommerce hasn’t changed and keeps working as expected, as before the Jetpack connection breaks.

Look forward to your reply, and thanks for sorting this out with us!

(internal ref: if Jetpack works okay, we can close ticket 9158926)

Hi Stef,

Thanks for looking at this issue. Jetpack does appear to be happy now–no more connection warning. Woocommerce does seem to be working still.

When you say ‘alternate endpoint’, do you mean something other than XML-RPC? If so, does that mean we can lock down access to XML-RPC now?

Hi there, @grandpaslab,

I am glad to hear Jetpack is set up okay also at your end ??

When you say ‘alternate endpoint’, do you mean something other than XML-RPC? If so, does that mean we can lock down access to XML-RPC now?

Yes, we are using an alternate point provided by your hosting provider that relies on REST API. There are still more advantages in using the xmlrpc.php file, so I’d recommend not to block it entirely. If your connection is now stable by using the alternate endpoint, it’s good to have the xmlrpc.php option ready if the alternate endpoint disconnects for whatever reasons.

Hope that answers your question!

That doesn’t answer my original question: why is Jetpack making requests from IPs outside of the published allow list?

I’d be fine with keeping xmlrps.php open to Jetpack only. I can’t do that if Jetpack doesn’t stick to the allow list IPs. I work for a massive, risk-averse corporation. Our sites are subject to regular security audits. Keeping an xml-rpc endpoint open to the entire internet is not something I can get away with.

Hi @grandpaslab

I don’t have the answer to that right at this second, but I’ve asked some of our developers for their thoughts on this. I’ll update here as soon as they respond.

I did notice that they two addresses you mention above – 64.252.77.14 and 3.172.38.104 both seem to be related to Amazon Cloudfront. I’m not sure how that factors in here, and on which end.

Hey there – Right now the connection between the site and Jetpack is looking good but we see some issues with the Jetpack Sync which is creating problem for Jetpack to connect properly with the site. Our developers have looked into the situation and have a few points of consideration that may help resolve the issue.

1. Changes and Logs: Our team is curious if there have been any changes on your side or if you’ve observed any errors in your logs that might shed light on the Jetpack Sync error situation.
2. Could you please also let us know what endpoints are being hit with those IPs (64.252.77.14 and 3.172.38.104)? We just want to check if those IPs are for Jetpack Sync or not.

Looking forward to your response!

Hello @grandpaslab,

Do you have updates about that? We usually close inactive threads after one week of no activity, but we want to make sure we’re all set before marking it as solved. Thanks!

1. There have been no changes on our side other than opening the xmlrpc endpoint.
2. We are no longer seeing requests from those specific endpoints. However, I think we were specifically seeing those when trying to reconnect Jetpack via the UI.

We are still seeing what appear to be Jetpack requests to the xmlrpc endpoint from IPs outside the allow list. Below are requests matching “xmlrpc” and “Jetpack” for the past week. Please let me know if these look legit.

70.132.33.134 – – [08/Jan/2025:20:31:03 +0000] 1246 “POST /xmlrpc.php HTTP/1.1” 200 443 “https://store.lucasfilm.com/xmlrpc.php” “Jetpack by WordPress.com”
70.132.33.151 – – [08/Jan/2025:20:31:03 +0000] 1378 “POST /xmlrpc.php HTTP/1.1” 200 443 “https://store.lucasfilm.com/xmlrpc.php” “Jetpack by WordPress.com”
70.132.33.134 – – [08/Jan/2025:20:31:04 +0000] 1081 “POST /xmlrpc.php?for=jetpack&rand=938017596 HTTP/1.1” 200 525 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&rand=938017596” “Jetpack by WordPress.com”
70.132.33.151 – – [08/Jan/2025:20:31:04 +0000] 1084 “POST /xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368264&nonce=Us25CQlwJP&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=qKAGAQMDVT4JKoFyaoXroOtXgW8%3D HTTP/1.1” 200 631 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368264&nonce=Us25CQlwJP&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=qKAGAQMDVT4JKoFyaoXroOtXgW8%3D” “Jetpack by WordPress.com”
70.132.33.133 – – [08/Jan/2025:20:31:03 +0000] 2079 “POST /xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368263&nonce=kehzmBZrDn&body-hash=ISPbflQMuRZ2bt%2BXlkF1TgU7RNk%3D&signature=KzAuQSZMRjvSqGuQJ5Pq8Q08iUQ%3D HTTP/1.1” 200 1009 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368263&nonce=kehzmBZrDn&body-hash=ISPbflQMuRZ2bt%2BXlkF1TgU7RNk%3D&signature=KzAuQSZMRjvSqGuQJ5Pq8Q08iUQ%3D” “Jetpack by WordPress.com”
70.132.33.133 – – [08/Jan/2025:20:31:05 +0000] 919 “POST /xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368264&nonce=GMoqzQZUyB&body-hash=pdst%2B%2B8gjpsEsdzTGdS19%2BYN3g4%3D&signature=8NOYgsBzdBWAquHwS0hQhomDKiM%3D HTTP/1.1” 200 441 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368264&nonce=GMoqzQZUyB&body-hash=pdst%2B%2B8gjpsEsdzTGdS19%2BYN3g4%3D&signature=8NOYgsBzdBWAquHwS0hQhomDKiM%3D” “Jetpack by WordPress.com”
70.132.33.151 – – [08/Jan/2025:20:31:05 +0000] 767 “POST /xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368265&nonce=rx31c2E7IB&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=HD2UcEkDd35fbYFhSp0as%2F8ucjY%3D HTTP/1.1” 200 631 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368265&nonce=rx31c2E7IB&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=HD2UcEkDd35fbYFhSp0as%2F8ucjY%3D” “Jetpack by WordPress.com”
70.132.33.133 – – [08/Jan/2025:20:31:05 +0000] 777 “POST /xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368265&nonce=0VIuoD64m8&body-hash=METbiCw%2BtMQdctk0fdLMNlXOKKM%3D&signature=aZRzD9SeELOMBMloEt83lGXVL7A%3D HTTP/1.1” 200 1356 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=9S6u7%26u5%29zBLAnPx2%26%21S%2ACd8P%40F2VC%28v%3A1%3A0&timestamp=1736368265&nonce=0VIuoD64m8&body-hash=METbiCw%2BtMQdctk0fdLMNlXOKKM%3D&signature=aZRzD9SeELOMBMloEt83lGXVL7A%3D” “Jetpack by WordPress.com”
70.132.33.134 – – [08/Jan/2025:20:31:06 +0000] 890 “POST /xmlrpc.php?for=jetpack&token=YN%23sXnC0JCo%5ER%21w%2A831%2Amlrcsc%25emb%25s%3A1%3A2&timestamp=1736368266&nonce=B9IqRDFnlP&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=xX2FG8HNPnAeb2TjA9%2BY8e%2FK6a8%3D HTTP/1.1” 200 699 “https://store.lucasfilm.com/xmlrpc.php?for=jetpack&token=YN%23sXnC0JCo%5ER%21w%2A831%2Amlrcsc%25emb%25s%3A1%3A2&timestamp=1736368266&nonce=B9IqRDFnlP&body-hash=l5MGKDtBMCRLlbhRxcm3udBaUGk%3D&signature=xX2FG8HNPnAeb2TjA9%2BY8e%2FK6a8%3D” “Jetpack by WordPress.com”

Hi @grandpaslab,

Thank you for the details shared.

Thanks for your patience while we looked into this!

Currently, Jetpack is successfully connected to your site via the traditional XML-RPC endpoint, and all systems are functioning as expected. The Jetpack Debugger confirms the connection is stable, so there’s no further action needed on this front.

Regarding the IP addresses (70.132.33.133 and 70.132.33.134) you shared, while they are not part of Jetpack’s official allowlist, the activity observed in your logs appears consistent with legitimate Jetpack requests. Based on your infrastructure’s scale, it’s possible these IPs belong to intermediary services like proxies or load balancers within your environment.

For now, everything seems to be running smoothly. If you notice any anomalies or experience connection issues again, don’t hesitate to reach out—we’ll be happy to assist.

Best regards,
Alin