DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.

snore

@RonpfS said in DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.:

That rules isn't generated by pfblockerNG. pfblockerNG use 177000* numbers.

And you don't have TLD enabled ?!

Ok, then I must have added it by myself a long time ago based on some (probably misunderstood) forum post. But the fact remains: it does get hit.

No, I don't have TLD enabled:

RonpfS

This post is deleted!

RonpfS

@snore said in DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.:

But the fact remains: it does get hit.

When was the last time you rebooted, maybe you have something that is hanged.

You could try to stop and restart pfBlockerNG DNSBL service from the Status/Services tab

Again, you what to do a Force Reload DNSBL when you change DNSBL settings.

cybrnook

Bumping an older thread, but seeing the same behavior.

I am running 2.4.4 p3, and have been for some time. I have a dual WAN config with a WAN failover group. I also have a VPN interface with Mullvad that is acting as my default gateway. Mullvad is being provision on a 10.10.0.* IP.

Until yesterday I was running fine with pfblockerng 2.1.4_17. I decided to make the jump to devel, and followed the advice on @BBcan177 's blog to make sure "save settings" was checked, perform the uninstall, then install the new devel. That all went fine, and every was seemingly working fine.

Today I decided I wanted to add one more block list to my feed, and remove an old one (Zeus which is no longer maintained). I made that update, and also decided to disable Top 1M domain whitelist. When I went to "Save" the change, I got barked at that my DNSBL IP needed to be in its own isolated range, even though this is the same config it's been for almost 2 years now? Only difference is I uninstalled and installed the new devel. I have now had to change to 10.0.0.1 (from what was 10.10.10.1) and that seems to work, I can save and force reload. But now I am wondering why it thinks the 10.10.10 subnet is in use on my network?

Any help would be appreciated.

cybrnook

My brains tired, but trying to figure out how the check is coming to the conclusion that 10.10.10.1 is in use. I've checked my state table, my ARP Table, active sessions, only thing close is my VPN on 10.10.0.*, but that's a different subnet, so it should not be flagged. I don't see "where_is_ipaddr_configured" as a stored procedure, so not sure what logic it's using? :

https://github.com/pfsense/FreeBSD-ports/blob/76b7ae7ab673f8e255bcdce91ee4d044071ccd20/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/www/pfblockerng/pfblockerng_dnsbl.php#L156-L165

		// Validate DNSBL VIP address
		if (!is_ipaddrv4($_POST['pfb_dnsvip'])) {
			$input_errors[] = 'DNSBL Virtual IP: A valid IPv4 address must be specified.';
		}
		else {
			$ip_validate = where_is_ipaddr_configured($_POST['pfb_dnsvip'], '' , true, true, '');
			if (count($ip_validate)) {
				$input_errors[] = 'DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.';
			}
		}

cybrnook

@BBcan177 , looking at this line:

$ip_validate = where_is_ipaddr_configured($_POST['pfb_dnsvip'], '' , true, true, '');

Am I reading it correctly, you are defining variable ip_validate by comparing where_is_ipaddr_configured output, and then the logic is then to take the output ($_POST) of value pfb_dnsvip (which is already defined as 10.10.10.1 in line 114 of your php already)? I am trying to google php and figure out what's happening with the double quotes and the true true double quotes, but I see you are taking the output of that and counting the value in the next line to conclude is pfb_dnsvip is isloated or not. Just a little help on how you are doing this, so I can trace down on my end where the determination was made that 10.10.10.1 is NOT isolated on my env, please?

A friend help me find the procedure of where_is_ip_configured, via a bug: https://redmine.pfsense.org/issues/7430
But that still doesn't make sense, since my Interfaces are LAN (192.168.1.1/24), WAN1, WAN2, and MULLVAD, and only MULLVAD comes in with a subnet of 10.10.0.* (not 10.10.10.*).

johnpoz

@cybrnook said in DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.:

LAN (192.168.1.1/32), WAN1, WAN2, and MULLVAD, and only MULLVAD comes in with a subnet of 10.10.0.* (not 10.10.10.*).

Your lan is a /32??? How is that suppose to work? And what is your subnet on this 10.10.0/16 would overlap 10.10.10.x

cybrnook

@johnpoz

Thanks a ton for the response (I know you are quite knowledgeable here in the forums), and sorry I updated the last reply (it's 24 not 32) my apologies on dumping incorrect info in too quick I guess, mind goes faster than my fingers.

So, you are hitting right where I am suspecting, that the subnet that mullvad is pushing is what is the trigger. However, from my end, I don't believe that is a configurable, more a server push. Would you happen to know where I can find that out?

I want to note, DNSBL is working fine for me, and has been for years. It's just after upgrading to the devel package, the config I have been using for years is suddenly not good enough anymore. So perhaps the fact that I added the VPN later in time after pfblocker was installed, it was a chicken/egg scenario? Since mullvad likes to be on 10.10.0, perhaps any new modification I made in pfblocker would have barked at me, but I wouldn't know since it's been set it and forget it for so long. So, VPN is on 10.10.0, pfblocker says 10.10.10 is too close, and I changed to 10.0.0.1 and that works fine. I am just more focused on the "why", and maybe either it really IS overlapping subnet, OR perhaps one layer deeper could be used in pfblockers qualification of an isolated subnet? I am just a sticky person as my friend always says, that's all.

The base config for that interface is rather bare bones, no asking of subnet to be specified so I think it's pushed or either assigned by pfsense by default. The last octet for Mullvad is always the floating variable. I have never once seen it assign me an IP in the third octet, that's always 0:

Interface

OvpnClient

BBcan177

Goto pfSense Diagnostics / Execute PHP Commands and enter the following:

$ip_validate = where_is_ipaddr_configured('10.10.10.1', '' , true, true, '');
print_r($ip_validate);

Then hit "Execute"

This will report back if the DNSBL VIP address overlaps with any existing IPs that you have configured.

johnpoz

Looking at the status interfaces should show you what your mullvad interface is.

cybrnook

@BBcan177 said in DNSBL Virtual IP: Address must be in an isolated Range that is not used in your Network.:

Goto pfSense Diagnostics / Execute PHP Commands and enter the following:
$ip_validate = where_is_ipaddr_configured('10.10.10.1', '' , true, true, '');
print_r($ip_validate);
Then hit "Execute"

This will report back if the DNSBL VIP address overlaps with any existing IPs that you have configured.

Well, that answers that :-) Just like your sig says, experience is something you don't get until after you need it!

Array
(
    [0] => Array
        (
            [if] => opt2
            [ip_or_subnet] => 10.10.0.5/16
        )

)

So, it IS my Mullvad VPN that it is colliding with.

With that now being brought to light and confirmed, is there anything that I, or other users, can do to avoid that and stick with your hard coded default?

johnpoz

That they would use a /16 is just moronic!!!

So they have 65k some clients hitting the same vpn server?

cybrnook

@johnpoz

Yeah....... but, what's a user to do? They offer wireguard, as well as OVPN, port forwarding, and the service is pretty stable.... I wish there was a way on the client side I could override?

johnpoz

Can you ask them why they are using a /16 - say it overlaps one of your local networks.

cybrnook

@johnpoz

Sure, worth a shot. If they come back, I'll update.

BTW, Thanks @johnpoz and @BBcan177

johnpoz

No problem, glad you got it worked out what it was ;) My way in finding it easier, but have to admit bbcan177 way more geeky - hehehe

Not sure why they would be even using normal rfc1918 space... Why would they not just use say part of 100.64.0.0/10 (https://tools.ietf.org/html/rfc6598), they should be sure it doesn't overlap with users local rfc1918 space that way.

BBcan177

@cybrnook

With that now being brought to light and confirmed, is there anything to I, or other users, can do to avoid that and stick with your hard coded default?

Its just a default setting. There is no magic in using that IP or any other RFC1918 address.

cybrnook

@cybrnook @johnpoz @BBcan177

Here is the response, not bad.

/16 was selected due to the fact that /24 is too small, and the 10
network was used primarily because it was the default (for OpenVPN) and
also assigning in the 100.64/10 can create more conflicts with devices
that use cgnat.

That said, each OpenVPN server port uses a different /16, so a simple
solution is to connect to for instance port 1194, which would then give
you 10.8.0.0/16 range, and you would not have the conflict in your network.

Here are the ranges used:

tcp_1401_10.22.0.0
tcp_443_10.5.0.0
tcp_80_10.6.0.0
udp_1194_10.8.0.0
udp_1195_10.9.0.0
udp_1196_10.10.0.0
udp_1197_10.11.0.0
udp_1300_10.14.0.0
udp_1301_10.15.0.0
udp_1302_10.16.0.0
udp_1303_10.17.0.0
udp_1400_10.21.0.0
udp_53_10.7.0.0

And of course

johnpoz

So they didn't answer about the /16 - so they have some 65k some clients connecting to the same server?

/24 yeah ok too small what about a /20 or 19, etc.. /19 would be 8k some IPs..

cybrnook

@johnpoz

Nope! I did follow up, but haven't gotten a response yet.