4 ms·

As a result of the complexity and requirements, we realized we would like to have a solution for CDN, WAF, and DDOS protection with one vendor. Depending on yo

As a result of the complexity and requirements, we realized we would like to have a solution for CDN, WAF, and DDOS protection with one vendor. Depending on your definition of ddos protection Fastly has those things along with granular and semi scriptable configurability via vcl. Granted it’s been 2-3 years since I last did a comparison between Fastly and Cloudflare but I can’t understand why a company with presumably a need for configurability at the edge would make this choice. Cloudflare’s entry tiers are unbeatable in price but beyond that it’s extremely bulky.

eganist 7y ago
Is there anything you wish Cloudflare offered with Workers (https://developers.cloudflare.com/workers/ https://developers.cloudflare.com/workers/) or VCL->Workers conversion (https://developers.cloudflare.com/workers/archive/recipes/vcl-conversion/ https://developers.cloudflare.com/workers/archive/recipes/vc...) specifically?
T4cC0re 7y ago
One of the key reasons we decided to utilize Cloudflare as our vendor for WAF and CDN was, that they uniquely offer to run SSH (or any TCP application, really) and HTTP(s) on the same hostname.
- secondo 7y ago
  You’re setting yourself up for some future and potentially hard to introspect problems for yourself and your users with this setup. There are good reasons to keep those endpoints separate. As an example, the anycast solution you’ll rely on on that host, while great for short lived tcp sessions (https) will be problematic for your long lived sessions (ssh) which will be disconnected during routing changes in cloudflares network - ddos or operational changes. That is unless you establish sub flows for those sessions using a unicast IP address but now you’re accumulating additional complexity for the sake of wanting it all on a single hostname.
  - T4cC0re 7y ago
    From a technical perspective, you are right. Anycast IPs are more fragile when routing within an open session, as a route change might cause traffic to go to a different PoP and thus break the connection. The point of argument here was, however, the usability side. We offer our SSH services on port 22 on gitlab.com and HTTP(s) on 80/443. We do not want to change this. Because if we did, we would need to tell everyone to use a different URL to check out projects via SSH. And that is out of the question. And to be honest, the complexity on our end is limited. And for the complexity within Cloudflare to handle routing, etc., we pay them. We will also work with them do debug any connectivity issues a client might have.

eganist 7y ago

Is there anything you wish Cloudflare offered with Workers (https://developers.cloudflare.com/workers/ https://developers.cloudflare.com/workers/) or VCL->Workers conversion (https://developers.cloudflare.com/workers/archive/recipes/vcl-conversion/ https://developers.cloudflare.com/workers/archive/recipes/vc...) specifically?

T4cC0re 7y ago

One of the key reasons we decided to utilize Cloudflare as our vendor for WAF and CDN was, that they uniquely offer to run SSH (or any TCP application, really) and HTTP(s) on the same hostname.

secondo 7y ago
You’re setting yourself up for some future and potentially hard to introspect problems for yourself and your users with this setup. There are good reasons to keep those endpoints separate. As an example, the anycast solution you’ll rely on on that host, while great for short lived tcp sessions (https) will be problematic for your long lived sessions (ssh) which will be disconnected during routing changes in cloudflares network - ddos or operational changes. That is unless you establish sub flows for those sessions using a unicast IP address but now you’re accumulating additional complexity for the sake of wanting it all on a single hostname.
- T4cC0re 7y ago
  From a technical perspective, you are right. Anycast IPs are more fragile when routing within an open session, as a route change might cause traffic to go to a different PoP and thus break the connection. The point of argument here was, however, the usability side. We offer our SSH services on port 22 on gitlab.com and HTTP(s) on 80/443. We do not want to change this. Because if we did, we would need to tell everyone to use a different URL to check out projects via SSH. And that is out of the question. And to be honest, the complexity on our end is limited. And for the complexity within Cloudflare to handle routing, etc., we pay them. We will also work with them do debug any connectivity issues a client might have.