Why is the Cloudflare WARP client binding to port 53 on IPv4 address 192.0.2.2

Hello Cloudflare Community,

I noticed the above in my firewall software’s flow monitor the other day and found that the Cloudflare WARP process is binding itself to port 53 under a udp4 loop back address using the IANA Special Use IPv4 address 192.0.2.2. I didn’t see this IP address listed under the Cloudflare Zero Trust documents and was curious to know if anyone else has run into this and if it is common practice that the WARP client follows. I normally wouldn’t be concerned, but saw that it was attempting connections to the bounded 53 port with increasing ephemeral ports under the same bounded IPv4 address.

lo0:
inet 192.0.2.2 netmask 0xffffff00

From netstat -anv output:
Proto Recv-Q Send-Q Local Address Foreign Address
udp4 0 0 192.0.2.2.53 .

From WARP with firewall documentation:

  • IPv4 API Endpoint: 162.159.192.1
  • IPv4 Ingress Range: 162.159.193.0/24
    WARP utilizes UDP for all of its communications. By default, the UDP Port required for WARP is: UDP 2408. WARP can fallback to: UDP 500, UDP 1701, or UDP 4500.
    I apologize if this was already asked. I wasn’t seeing the above address when I attempted to search earlier under the community site or on the Zero Trust documentation.

Thank you for the insight,
Wade

:wave: hi @DersonProductions we are checking that internally and we will let you know.
Is this specific binding creating any issues in your FW ?

Looks like it’s a local IP used for DNS caching (at a glance)

Thanks Stefano1. No, this doesn’t appear to be messing with the software other than being weird traffic to me. I wasn’t sure what the client was attempting to do here, hence my post. I did discover the IP addresses 192.0.2.2 and 192.0.2.3 are related to the client effectively working since I will lose internet if I blocked the 192.0.2.2, 192.0.2.3 individually or the entire 192.0.2.0/24 CIDR range in the firewall itself. I blocked those since they were what was being defined in the /etc/resolv.conf file and I wasn’t seeing a defined use listed in the documentation, which I admit I might of missed it somewhere. To make it more confusing for me, I had installed a DNS profile to my Mac that is setup to use the Server URL and IP addresses defined for the Gateway I’m attempting to use from the Zero Trust application portal. I was attempting to force all DNS queries over HTTPS, DoH, so I was surprised when the /etc/resolv.conf was being updated from the ip addresses I setup within the profile and within the DNS settings for my network adapters themselves.

Then add in the the increasing port numbers I was seeing to the bounded 53 port on the loopback address 192.0.2.2 and started pondering about what was going on. Thanks once again for taking a look at this with me.

yeah, it appears that way to me now too mark_07 after some digging and breaking of the client when blocking the ip addresses, but I became curious when the CIDR block being used isn’t designed for ‘local’ use. I was seeing within the IETF RFC 5737 for the 192.0.2.0/24 CIDR block, TEST-NET-1, that this address range isn’t supposed to be used in practice. At least that’s what I gathered from the introduction and abstract of the RFC,

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks.

This might be some tomfoolery on Apples part now that I think about it. From what I’ve gathered on Paul Miller’s GitHub pages is that MacOS has supported DoH and DoT since version 11, Big Sur. Then looking at Apple’s developer documentation it appears that DNS over a secure fashion can be setup system wide, but I’m wondering if the system is mad that I broke port 53 by blocking it outright. This traffic might just be a part of the OS hijacking the configuration and modifying traffic direction since it really wants to have telemetry over port 53 for some reason.

Paul Miller’s GitHub for setting up DoH or DoT with a profile:
https_github_com_paulmillr_encrypted-dns

Apple Deceloper docs on Secure DNS:
https_developer_apple_com_documentation_networkextension_dns_settings

It was for our local DNS proxy. Note that as of version 2022.5.x of the client this is has now changed to 127.0.2.2, 127.0.2.3, fd01:db8:1111::2, and fd01:db8:1111::3 consistently across platforms.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.