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



  • Hello,

    Whenever I go into the general DNSBL settings (to add white listed domains in this example), and try to save, I get the above message.

    The virtual IP = 10.10.10.1, the LAN is 192.168.2.1/24.

    In the past this never was a problem in the stable version of pfBlockerNG, now that I uninstalled that and installed the -dev version, I notice this problem.

    How could I fix this? Because now it refuses to save my changes to the whitelist.

    (Trying disable DNSBL in order to next re-enable it doesn't work: it generates the same error and refuses to save anything).

    (Adding a DNSBL feed is working fine, so it is just this general settings tab that gives problems).



  • What other interfaces are configured on your system Status / Interfaces ?

    You can choose a different VIP then the default suggested in the settings.



  • Thank you Ron ✍

    No other interfaces. The weird thing now is: I did as you suggested, change the VIP.

    10.10.10.1 doesn't work.

    172.16.0.1 is fine.

    "This is not a bug, it is a feature".



  • Any NAT ? VIP ? VPN ?

    And what if you change it back to 10.10.10.1 ? 🤓



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

    Any NAT ? VIP ? VPN ?

    And what if you change it back to 10.10.10.1 ? 🤓

    There is nothing 10...* in NAT, I don't have virtual IP's, but I do have a VPN client to PIA, which has 10.10.0.3 as IP.

    Is 10.10.0.3 in the same range as 10.10.10.1?

    (Changing back to 10.10.10.1 doesn't work: same error complaint).



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

    Is 10.10.0.3 in the same range as 10.10.10.1?

    It depends on the 10.10.0.3 netmask, but I guess it's in the same network.



  • It is getting strange.

    The virtual IP is 172.16.0.1, but the 10.10.10.1 gets hit by the firewall rule.

    (And pfBlockerNG did not create a new firewall rule and delete the old one when I changed 10.10.10.1 into 172.16.0.1, so there currently isn't a firewall rule for the 172.16.0.1 on LAN)pfb_vip_fw_basic_settings.jpg .

    And the old firewall rule that was still there:

    pfb_vip_fw_rule.jpg

    And the most recent logs:

    pfb_vip_fw_log.jpg



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

    And you don't have TLD enabled ?! 🤔

    When you save DNSBL, you have to do a Force Reload DNSBL



  • @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:

    pfb_vip_fw_basic_settings2.jpg



  • This post is deleted!


  • @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. 😌



  • 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.

    7b777de3-1f97-47ca-8221-2811ece0270c-image.png

    59b21f8e-50d6-4e8b-a177-6c3c2f1b9291-image.png

    71b4f814-70c4-4677-b4b1-a4564e259b0c-image.png



  • 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.';
    			}
    		}
    


  • @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.*).


  • LAYER 8 Global Moderator

    @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



  • @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
    51778853-6e71-446d-aa93-f1e5d6aa7eba-image.png

    OvpnClient
    cb32dd3d-5933-46fd-b8c0-79f0e4adb7e1-image.png
    0e557e4e-066a-4ed6-b155-257c887a9056-image.png
    e1120933-8218-4b0f-9c93-61806c4f9181-image.png


  • Moderator

    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.


  • LAYER 8 Global Moderator

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

    vpninterface.png



  • @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?


  • LAYER 8 Global Moderator

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

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



  • @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?


  • LAYER 8 Global Moderator

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



  • @johnpoz

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

    BTW, Thanks @johnpoz and @BBcan177


  • LAYER 8 Global Moderator

    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.


  • Moderator

    @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 @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 🤘 🤘 🤘 🤘
    750faf8c-b339-4cfe-95aa-9b2ba17949bb-image.png

    fa50f79e-51c8-4a6a-847c-d1dd1cfb5f5e-image.png

    78b89de5-53f0-4c92-9b49-41d1fed91aea-image.png


  • LAYER 8 Global Moderator

    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..



  • @johnpoz

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



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

    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..

    Hello,
    
    To be fair, we are nowhere at that point, at most I've seen 200-300
    users on servers that has the highest load  (8 core 10GbE)
    
    Most servers have way below that and can use a /24 with no problem,
    however we do want to design in a way so we do not run into issues later on.
    
    Best regards
    

  • LAYER 8 Global Moderator

    So their servers or cluster at each pop can handle 65k users - yeah find that unlikely ;) This just a perfect example of how misuse of ipv4 space ran us into a shortage of ipv4 way before it should of ever happened..

    Network space should be assigned appropriately for the amount of devices that will be using that space.. Even when inside rfc1918 space (which has limits as well) Sure you allow for growth and such.. But come on their 8 core 10ge box could handle anywhere close to even 8k users? That would leave you at most 1.25mbps each user ;) Let alone 64k users ;)


Log in to reply