pfBlocker v3.2.0_8_devel DNSBL VIP - Connection refused

[midnightoil2]

Hi all,

Long time user, first time poster. I've searched for the last few days but can't find a topic that accurately describes what I’m experiencing.

Recently I have re-built my entire pfSense installation from the ground up, due to some bugs and lack of love with the older install. My current setup is as follows;

pfSense 2.7.2 running as a VM on ESXi 6.7u3
pfBlocker_devel 3.2.0_8
Dedicated VMXNET3 NIC for WAN - FTTN in bridge mode to ISP modem (WAN vmx0)
Dedicated VMXNET3 NIC for LAN port out to l3 managed switch (TRUNK vmx1)
VLANs 1 (CORE on vmx1), 10 (LAN on vmx1), 40 (VPN on vmx1), 50 (IOT on vmx1), 80 (HEATH on vmx1), 100 (CCTV on vmx1)

My current config is working as expected. VLANs, traffic filtering, pfBlocker IP/DNSBL all functioning well and filtering traffic per policy.

I am struggling with the DNSBL VIP block page. No doubt it’s a configuration issue on my end, as it has not worked consistently on either the old or this fresh install.

For the first 10-20 seconds after a cold boot of pfsense, I am able to access the VIP page on 10.10.10.1. The expected default page is displayed with a not secure message in the browser. I can access on both HTTPS and HTTP as tested from LAN and IOT subnets. I have not changed the ports; they're set at default 80 and 443 respectively.

After this time passes, I can no longer access the default page. The browser changes to reporting ERR_CONNECTION_REFUSED. I am able to ping 10.10.10.1 from LAN subnet at all times, and have confirmed that the DNSBL VIP address is in a unique range with nothing else close. A traceroute to a blocked dns entry returns 10.10.10.1 on the first hop.

This also applies to any DNS entry that should be blocked per blocklists or policy. Instead of returning the VIP default page with the ruleset that was applied, the browser returns ERR_SSL_UNRECOGNIZED_NAME_ALERT or ERR_CONNECTION_REFUSED.

I have tried the following;

• Setting all DNSBL to disabled, in case the VIP address was included on one of those.
• Setting all IPv4 blocklists to disabled/permit both for the same reason.
• Complete uninstall of pfBlocker with the 'keep settings' checkbox disabled.
• Changing the Web Server Interface from localhost to 'LAN' and 'CORE'. Resulted in the page temporarily
  being available again until ~20secs had passed then same ERR_CONNECTION_REFUSED result.
• Clearing the cache and browsing data of the PC I’m testing from within LAN.
• Uninstalling _devel version and installing pfBlocker 3.2.0_8

Any guidance is very much appreciated, I’m at a loss at this point. Being that the default page can be displayed for some time after a cold boot/change to Web Server Interface I’ve seen that it’s not completely broken. I also feel like some filtering may be catching up after this time and denying access. Happy to provide any logs/screenshots that could assist.

Cheers! Jake

[Gertjan]

@midnightoil2

Read my reasoning after where I wrote "[ and scrap the rest ]" : https://forum.netgate.com/topic/189681/pfblockerng-dnsbl-not-going-to-the-block-page/2

which boils down to : forget about the usage of the "10.10.10.1" web page telling that a blocked DNSBL was requested.
Such a page shouldn't show up, as no one can (should able to) redirect TLS (https).

Btw : Still, 10.10.10.1 should work, it does so on my setup.

Test with

curl 10.10.10.1

on the command line (console, or SSH) when it works, wand when it doesn't.
Also

curl 127.0.0.1

as you use, like me the default localhost to which the pfBlocker webserver is listening.

[midnightoil2]

@Gertjan

Thanks for your reply, i've read that article and agree that it should not be possible and is not wanted to redirect https traffic. I still have interest should a http dns be attempted from a blocklist feed.

I have attached the output of the curl commands, which in itself was a little strange to capture. The terminal hangs on the "Working 10.10.10.1" until the VIP page no longer displays in the browser ~15secs and then the curl processes with the return..

That and the notable difference that loopback address was not able to connect when the page stops responding. Am i correct with the setting of 'localhost' on the DNSBL Webserver Configuration page if i wanted this to apply to all VLANS?

Appreciate your help! Jake

Not working 10.10.10.1.txt Not working 127.0.0.1.txt Working 10.10.10.1.txt Working 127.0.0.1.txt

[Gertjan]

@midnightoil2 said in pfBlocker v3.2.0_8_devel DNSBL VIP - Connection refused:

I still have interest should a http dns be attempted from a blocklist feed.

I insist (a bit) : if you 'see' that your LAN clients = you, and/or other people still use http sites, consider that as driving without attaching the seat beat. You should have a talk with these people as they will sooner or later a big problem.
Or, to help them to go https : block port 80 TCP outgoing traffic for a while. They will thank you later.

@midnightoil2 said in pfBlocker v3.2.0_8_devel DNSBL VIP - Connection refused:

I have attached the output of the curl commands, which in itself was a little strange to capture. The terminal hangs on the "Working 10.10.10.1" until the VIP page no longer displays in the browser ~15secs and then the curl processes with the return..

Looks like you have some sort of network issue.

@midnightoil2 said in pfBlocker v3.2.0_8_devel DNSBL VIP - Connection refused:

Am i correct with the setting of 'localhost' on the DNSBL Webserver Configuration page

That's what I have.

and that why it should work from 127.0.0.1 == localhost.
If it doesn't, look no further. You're right, there is an issue.

@midnightoil2 said in pfBlocker v3.2.0_8_devel DNSBL VIP - Connection refused:

if i wanted this to apply to all VLANS?

VLAN are like LAN.
You pick here on which LAN you want to show the "DNSBL Blocked DNSBL Webserver".

Keep in mind : this will place one or more Floating firewall rules.
If you already had some of these rules, ordering might be necessary.
These floating rules make sure that on a selected interface has access to 10.10.10.1.

[midnightoil2]

This post is deleted!

[midnightoil2]

@Gertjan

Thanks for all the info :) I'll likely follow up with the point of just blocking all http traffic and call it a night..

The curious side of me just keeps on.. wireshark isn't doing much here and results are inconsistent making it hard to pin down.

I have limited the scope while troubleshooting, and stayed on the default ports. I have selected only my LAN VLAN 192.168.10.x for the Web Server Interface, along with only allowing LAN for the permit/ping IP floating rules. I can see they are created and are in the right order. There are 2 scenarios that play out here;

--After changing Web Server Interface from localhost to LAN, but before Update>Reload>DNSBL--

1. The VIP page will display with the correct evaluated domain/feed and remains accessible, after i have changed the Web Server Interface from localhost (80/443) to LAN (80/443), browsing both 10.10.10.1 and http://ib.3lift.com/ (StevenBlack_ADs)
2. The VIP page will not display on 127.0.0.1
3. I cannot ping 10.10.10.1
4. I cannot curl 10.10.10.1 - terminal hangs
5. I can ping 127.0.0.1
6. I can curl 127.0.0.1 - output as working previously attached.

--After changing Web Server Interface from localhost to LAN, after Update>Reload>DNSBL--

1. The VIP page no longer displays browsing both 10.10.10.1 and http://ib.3lift.com/ (StevenBlack_ADs)
2. The VIP page will not display on 127.0.0.1
3. I can ping 10.10.10.1
4. I can curl 10.10.10.1 - output as working previously attached
5. I can ping 127.0.0.1
6. I can curl 127.0.0.1 - output as working previously attached.

The change seems to happen around the time that the log shows TLD finalize on the reload task (attached)