Subscribe to receive notifications of new posts:

CloudFlare Now Supporting More Ports


2 min read

CloudFlare Now Supporting More Ports

CloudFlare protects and accelerates web traffic. As a result, we initially only proxied traffic for the two main web ports: 80 (HTTP) and 443 (HTTPS). One of the top customer service questions we receive is: "Why did my control panel stop working after I signed up?" The answer is that most control panels run on a non-standard web port that we don't proxy. As a result, if you try and connect to cPanel-like control panels through CloudFlare then your traffic will get blocked. Not a great first experience.

Access Control

The solution has always been to access the control panel via the IP address or a subdomain setup to route around CloudFlare's proxy. That works great, but it still requires an explanation and therefore increases the CloudFlare learning curve. We're always looking for ways to make CloudFlare easier. A few weeks ago we began supporting other standard ports used by web control panels. In addition to 80 and 443, the list of supported ports now includes:

  • 2052
  • 2053
  • 2082
  • 2083
  • 2086
  • 2087
  • 2095
  • 2096
  • 8080
  • 8443
  • 8880

This covers most the web major control panels. While we will now proxy traffic through these ports, we won't cache static content or perform any performance or app transformations on requests/responses that flow through them. If you don't use these, we'll also soon provide a method to easily shut down these ports at the CloudFlare level.

FTP, SSH, and Non-Web Protocols

Reading this you may wonder why we can't open ports like 20, 21, 22 and 23 to support protocols like FTP, SSH, Telnet, etc. Unfortunately, while this is an often-requested feature, the protocols don't support it. We know where to send traffic after it connects to CloudFlare's network based on a HOST header in web requests. Non-web protocols like the above don't include a HOST header. As a result, for these protocols we see the traffic connecting to our network and have no way to route it to the origin.

This means that you'll continue to need to SSH and FTP into your server using an IP address or a subdomain you mark as being CloudFlare disabled on your DNS manager (we setup "direct" by default, but you can change it for better security). While this may seem like an inconvenience, there is an upside. By not directly exposing your origin server to traffic over these ports, we add an additional layer of security.

We also monitor all the connections from SSH and other protocol scanners that regularly try to "dictionary attack" logins. We feed this data back into our system in order to better protect from attacks. In other words, while there may be a bit of a learning curve to using SSH or FTP after signing up for CloudFlare, having those protocols blocked by our network means the CloudFare system is always learning.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
PleskProduct News

Follow on X

Matthew Prince|@eastdakota

Related posts

May 30, 2024 12:12 PM

Cloudflare acquires BastionZero to extend Zero Trust access to IT infrastructure

We’re excited to announce that BastionZero, a Zero Trust infrastructure access platform, has joined Cloudflare. This acquisition extends our Zero Trust Network Access (ZTNA) flows with native access management for infrastructure like servers, Kubernetes clusters, and databases...