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

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

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.

cybrnook

@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

johnpoz

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 ;)