connectivity.cloudflareclient.com IP Addresses

[jamie-sandbox]

Existing documentation URL(s)

https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/deployment/firewall/#connectivity-check

What changes are you suggesting?

The documentation states the following:

“Because this check happens inside of the tunnel, you do not need to add connectivity.cloudflareclient.com to your firewall allowlist.”

This is not necessarily correct, since on a Windows system with a firewall policy where outbound traffic is blocked by default, a rule must be added to allow warp-svc.exe to generate outbound network traffic to connectivity.cloudflareclient.com.

The hostname connectivity.cloudflareclient.com currently resolves to 162.159.138.65 and 162.159.137.65. However, these IPs are not referenced or contained elsewhere within the documentation.

Please can clarification be provided? Are 162.159.138.65 and 162.159.137.65 static addresses which we can create a firewall rule for? Or are they part of a range which we need to include the entirety of? If so, what is the range?

Additional information

No response

[jamie-sandbox]

Resolves to 162.159.138.65 and 162.159.137.65 when queried both inside and outside of the tunnel.

Hopefully these are static. 🙏

[deansundquist]

The client doesn't use DNS resolution for its inside tunnel connectivity checks, and it doesn't use 162.159.138.65 nor 162.159.137.65.

[deansundquist]

@jamie-sandbox and @deadlypants1973 I apologize but my last comment was incorrect. We do utilize DNS resolution for this, and we will attempt to connect to that IP address. (I was thinking about the outside tunnel checks, which are handled differently).

This traffic to this endpoint though should always be inside of the tunnel, when we connect to it. If it is not, the client will not be able to connect (unless you disable connectivity checks).

The reason we do not list this on our WARP with Firewall page is because it should be in the WARP tunnel, and not visible to any firewall that might sit between the Client and the Internet.

If you see connections to connectivity.cloudflareclient.com outside of the tunnel, we'd suggest opening a support case, as this is unexpected.

[jamie-sandbox]

@deansundquist Thanks for your response.

From my original description:

on a Windows system with a firewall policy where outbound traffic is blocked by default, a rule must be added to allow warp-svc.exe to generate outbound network traffic to connectivity.cloudflareclient.com.

Unfortunately the question still is not fully answered. Even when the traffic is within the tunnel, we still need to configure the local Windows Firewall to allow warp-svc.exe to send traffic to the relevant addresses.

The documentation should state what these addresses are.

[deadlypants1973]

#16241 (comment)

[deadlypants1973]

@jamie-sandbox thank you for your reply. I have alerted the engineering team about this and they are looking into it. Will update!

[deadlypants1973]

Hey @jamie-sandbox , I responded here: #16241 (comment) Let me know if that answers your questions and I can close this out. Thank you!

[github-actions]

This issue was closed automatically because there has been no response from the original author. As it stands currently, we don't have enough information to take action. If you believe this issue was closed in error, a) apologies and b) open a new issue and reference this one in the body.

[jamie-sandbox]

Hey @jamie-sandbox , I responded here: #16241 (comment) Let me know if that answers your questions and I can close this out. Thank you!

Unfortunately this still isn't answered. Traffic that goes through the tunnel is still passed through Windows Firewall. When outbound traffic is blocked by default in Windows Firewall, you need to permit warp-svc.exe to send traffic to the relevant addresses for the connectivity check.

Currently we have whitelisted 162.159.138.65 and 162.159.137.65 however it is not clear if these are truly static or not.

I've noticed that the documentation has been updated recently to add some new IPs to the connectivity requirements. These IPs seem to have been taken from the MASQUE range. I'm not sure of the context behind this and how/if it relates to this issue?

@ranbel @deadlypants1973 Please re-open.