pfsense keeps blocking Cloudflare sever IP range
I bought a cam???.com domain from Godaddy and transferred it nameserver to Cloudflare
and set up my DNS record within Cloudflare's DNS app.
A cam???.com points to 14.???.???.???(my pfsense public address) grey cloud selected = not using Cloudflare reverse proxy: DNS+HTTP
CNAME firewall is an alias of cam???.com orange cloud selected
CNAME pfsense is an alias of cam???.com orange cloud selected
CNAME www is an alias of cam???.com orange cloud selected
Note: Grey cloud means only DNS traffic is allowed to go through Cloudflare network.
Note: Orange cloud means reverse proxy: DNS + HTTP traffic is allow to go through Cloudflare network.
Testing without using Cloudflare reverse proxy...........
If I type in the URL: https://cam???.com, in my chrome browser, using my remote laptop,
my browser was able to reach my pfsense web GUI (pfsense firewall running at home)
I decided to try Cloudflare's reversing proxy, for DNS HTTP traffic.
The main reason having Cloudflare reverse proxy is to hide
real my public pfsense WAN interface IP address: [14.???.???.???(my pfsense public address)] with Cloudflare's public IP.
If I run a command nslookup in Windows command prompt, for: pfsense.cam???.com
The domain will resolve to:
Which is Cloudflare's IP address.
In order to get Cloudflare reverse proxying to work, I set an alias in pfsense for the: Cloudflare IP range:
22.214.171.124/15 = Range: 126.96.36.199 - 188.8.131.52
184.108.40.206/13 = Range: 220.127.116.11 - 18.104.22.168
The above Information is obtained from: https://www.cloudflare.com/ips/
Next, I set up a port forwarding rule -a PASS rule for the alias: Cloudflare IP range.
These PASS rule was placed at the very top order of the firewall rule.
I am based in one of the countries in Asia region.
Problem: pfsense keeps blocking all the Cloudflare's IP address range,
(see below) even though, I have double checked the IP ranges
are included in the alias, and used in the PASS rule.
I went to system logs, and check on the firewall tab.
Below are the Cloudflare's Singapore IP address range which pfsense keep on blocking.
- 22.214.171.124/15 ->Range: 126.96.36.199 - 188.8.131.52
- 184.108.40.206/13 ->Range: 220.127.116.11 - 18.104.22.168
If I type in the URL: firewall.cam???.com or pfsense.cam???.com into Chrome browser, the connection will time out.
and I get ERROR 522 message on the browser, indicating: Connection timed out.
Any idea which is the problem here?
Appreciated if some can give some advice.
I have attached some screen shots:
Public IP address: 22.214.171.124 belongs to Cloudflare's Singapore branch.
For unknown reason, pfsense blocked the connection, even though I have a pass rule for
CIDR: 126.96.36.199/13 = range: 188.8.131.52 -> 184.108.40.206 specified in my alias: CloulflareHTTPReverseProxyIPs
chpalmer last edited by
Can you show a screen shot of your WAN rule?
Sure, here is the attachment, btw, I always wonder why the order of the automatically shifted to the bottom by pfsense?
I saved the PASS rules (with the green tick) above the pfblock wan rules, but somehow it will move them back to the bottom.
Finally, after after spending lots of hours playing around and trouble shooting..............I finally found the problem
The problem lies within pfblockerNG ( I was using pfblockerNG dev.)
Disabling pfblockerNG did not help............same old problem keeps on blocking..........until I uninstall it from pfsense
Once uninstalled pfblockerNG dev from pfsense, reboot the router.........then.......every works like clockworks.
Now, if I am outside my local network(at the WAN side) can access my pfsense Web GUI securely.
Anyone one provided that the domain name was given, can access my pfsense Web GUI using SSL.
My real WAN address of the firewall will be hiding behind Cloudflare reverse proxy server.
My next question how to create a whitelist of the following Cloudflare IP addresses, in pfblockerNG,
at the very top order in WAN rule.
In PfblockerNG --> General there is the Option Rule order.
I think you should define a custom ip list (under ipv4 section) with action "pass" and than define the rule order so pass come before block/reject.