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.