securedme
Active member
Why would people choose not enabling them? That is, what are the disadvantages?
Cloudflare optimizations for XenForo
- Thread starter digitalpoint
- Start date
-
- Tags
- cloudflare
Why would people choose not enabling them? That is, what are the disadvantages?
digitalpoint
Well-known member
If they didn’t want to use a proxy?
securedme
Active member
You mean there are people who don't mind having their IP exposed to the world?If they didn’t want to use a proxy?
Anyway I enabled them. Just two clicks anyway
dougdirac
Active member
To me this was never an XF issue but a server issue, since I had to do this fix back when I was on vB.Also before I go to sleep, does xf still have issues resolving visitors IP's from cloudflare? Or did XF push a fix for this? If not what is needed?
Using Cloudflare with various forums · Cloudflare Support docs
Many widely used forum platforms are compatible with Cloudflare.developers.cloudflare.com
I used to use mod_cloudflare, but have been using mod_remoteip for the past several years as described here:
Restoring original visitor IPs · Cloudflare Support docs
When your website traffic is routed through the Cloudflare network , we act as a reverse proxy. This allows Cloudflare to speed up page load time by …
developers.cloudflare.com
Wildcat Media
Well-known member
Still going well, but the larger forum I admin is hosted at a larger managed server, where we don't have root access. Our LetsEncrypt certificates expired and made a mess out of everything. Unfortunately they don't accept outside certs (although since I've been there nearly 24 years, they probably could be convinced--they instead want you to buy their certificates), but I don't know what is different about their setup vs. my other sites which are unmanaged (both run on Apache), as mine update every 60 days like clockwork. And both are behind Cloudflare. I had to disable the proxies for the sites on the managed server, get support to manually update the certificates (as they were using it on some sort of cron job once an hour), then reenable the proxy.
We might just move the managed instance over here to XF Cloud, once we can afford it. I could run the forum myself hosted at an unmanaged server (and I do for numerous other sites) but, since I'm not always available 24/7, and it is a very busy and active site, the owner wants that safety net. It's busy enough that if issues happen, they happen fast, and happen large. (Thing is, I'm probably taking on another job where I'll be nowhere near a computer, plus, I travel where I'm away from a computer for days at a time. I can see his point.)
I guess we'll see how it plays out. Main thing is, the expired certificates caused us a lot of grief with Cloudflare in the mix. I'm going to be digging in to see if I can find a way to fix this, while we decide what to do host-wise.
We might just move the managed instance over here to XF Cloud, once we can afford it. I could run the forum myself hosted at an unmanaged server (and I do for numerous other sites) but, since I'm not always available 24/7, and it is a very busy and active site, the owner wants that safety net. It's busy enough that if issues happen, they happen fast, and happen large. (Thing is, I'm probably taking on another job where I'll be nowhere near a computer, plus, I travel where I'm away from a computer for days at a time. I can see his point.)
I guess we'll see how it plays out. Main thing is, the expired certificates caused us a lot of grief with Cloudflare in the mix. I'm going to be digging in to see if I can find a way to fix this, while we decide what to do host-wise.
⭐ Alex ⭐
Well-known member
Cloudflare should continue working even with an expired cert because you have the option to tell it not to care about the expiration, just cares that the connection is encrypted.
The only time it cares is when you're using Full (strict) mode. In your case, since you can't automatically renew your certs, you should be using Full mode.
Wildcat Media
Well-known member
Cloudflare works with an expired cert, but our server doesn't. That's a problem with the host, not us.
Wildcat Media
Well-known member
I have a test subdomain for a XenForo instance. I was using Zero Trust to block the entire subdomain.
However, I think I could block just the XenForo installation (installed in the subdomain's root) setting the "application domains" (aka application paths) as follows:
test.domain.com/index*
test.domain.com/admin*
test.domain.com/install*
...as these fields can accept wildcards.
Cloudflare says:
So...this should work?
Somewhat related, I can't get a rule to work. I had deleted it a few weeks ago, but created a new one to replace it. But I can't get Zero Trust to block the subdomain I am using it on--I can access it from everywhere with no blocking.
The only difference is that this time, I used an access group with a list of emails vs. entering the emails individually. And, the same with staff IP addresses (which are used under a separate Bypass policy).
I am accessing the forum now, using a browser I haven't touched in a year, and a VPN to change my IP address, so I have a reliable means of testing it without any tokens being stored on the computer. Comparing to another rule, everything is set exactly the same.
Maybe the Access Group feature is broken? I am applying it correctly. The following "Assign a group" section appears when you add one or more access groups.
And the group is defined as such:
Yet, the problem I'm having is that the sudomain is not being blocked this time. So I can still access it from everywhere. It's not like everything is blocked, and no email or IP address will work.
I think it's a "me" problem (getting old sucks, folks) but for the life of me, I can't figure it out. I'll report back if I can get it fixed...
However, I think I could block just the XenForo installation (installed in the subdomain's root) setting the "application domains" (aka application paths) as follows:
test.domain.com/index*
test.domain.com/admin*
test.domain.com/install*
...as these fields can accept wildcards.
Cloudflare says:
So...this should work?
Somewhat related, I can't get a rule to work. I had deleted it a few weeks ago, but created a new one to replace it. But I can't get Zero Trust to block the subdomain I am using it on--I can access it from everywhere with no blocking.
The only difference is that this time, I used an access group with a list of emails vs. entering the emails individually. And, the same with staff IP addresses (which are used under a separate Bypass policy).
I am accessing the forum now, using a browser I haven't touched in a year, and a VPN to change my IP address, so I have a reliable means of testing it without any tokens being stored on the computer. Comparing to another rule, everything is set exactly the same.
Maybe the Access Group feature is broken? I am applying it correctly. The following "Assign a group" section appears when you add one or more access groups.
And the group is defined as such:
Yet, the problem I'm having is that the sudomain is not being blocked this time. So I can still access it from everywhere. It's not like everything is blocked, and no email or IP address will work.
I think it's a "me" problem (getting old sucks, folks) but for the life of me, I can't figure it out. I'll report back if I can get it fixed...
digitalpoint
Well-known member
I'd say it's fairly safe to say that your Zero Trust Access rule is either not matching the request, or you have a different rule taking priority that is letting it through.
If Cloudflare's Zero Trust Access system simply stopped working as designed it would be pretty catastrophic to the security of the entire Internet (it would be better for Cloudflare to stop routing ALL network traffic until they fixed it if they had to).
If Cloudflare's Zero Trust Access system simply stopped working as designed it would be pretty catastrophic to the security of the entire Internet (it would be better for Cloudflare to stop routing ALL network traffic until they fixed it if they had to).
Wildcat Media
Well-known member
I agree, there is something letting access through. I have only a single rule for this subdomain, and I'm not seeing why it won't work using a "clean" browser and a VPN (to rule out anything stored in a browser).
I only have the two policies--one works with email addresses, and the second bypasses based on IP. In two rules, they are in the same order, and the policies set up exactly the same, with the only difference being the Access Groups being used rather than individual emails or IPs.
One helpful thing I found is that we can go back and look at a log of our exact changes. It even includes showing what I deleted a couple of weeks ago. Once I'm in a clearer mindset, I may take a look at it.
digitalpoint
Well-known member
Well, what I would do is simplify everything and slowly add individual things until you fnid the culprit. Like start with blocking test.yourdomain.com/zero-trust-test for everyone. Check if that works as intended, if it does add one more thing... like allowing one user to access it. Check that... etc, etc...
You will find which exact part is causing an issue as you add one thing at a time.
You will find which exact part is causing an issue as you add one thing at a time.
Wildcat Media
Well-known member
Yeah, that's what I'm thinking also.
And I might even start over again with a blank slate and add one piece in at a time to find out what is "leaking."
Wildcat Media
Well-known member
I realized that I had to set the test subdomain to "Proxy" rather than "DNS only" in DNS settings. I changed the setting yesterday and now it seems to be working.
I also found that I don't need wildcards for Zero Trust protection--on the test subdomain, I can simply use
index.php, admin.php and install as paths, and those are all protected now.For the LetsEncrypt renewal issue, though, I need to get on the hosting company about it. I can't be the only one using CloudFlare and LetsEncrypt. I have to see if they will accept outside certificates (vs. selling us one of their own for each domain and subdomain).
digitalpoint
Well-known member
Oh ya... not routing the traffic through Cloudflare will definitely bypass anything you setup to do with the traffic in Cloudflare. 
Any pointer to configure to configure this?
Thanks for the tutorial.
digitalpoint
Well-known member
Easiest way is to use the App for Cloudflare addon and enable the option under Proxies.
Similar threads
- Solved
