Is this expected for /31 ?
-
I have 193.118.53.194/31 in a pfBlockerNG 3.1.0_4 blacklist.
My logs show 193.118.53.194 was blocked but 193.118.53.195 was not.
Is this expected? -
It just happened again.
23.224.189.26/31 should be denied inbound but 23.224.189.27 was passed.I guess I'll have to write a program to process my aggregated blacklist so that all /31 are changed to two /32
I think pfSense and pfBlockerNG are excellent and I've been using them for the last two years.
It would be nice to know whether this is a bug or a feature or whether I'm misunderstanding something or doing something wrong.
I added my own custom blacklist to the PRI1 ipv4 source definitions. PRI1 is set to deny inbound. There is no doubt that the custom list is being used but anything /31 in my list doesn't block the second IP address.
-
Not sure what you are trying to block... /31 would be:194 = network address. 195 = broadcast address. No host addresses. Trying to block a P2P link?
-
@tzvia said in Is this expected for /31 ?:
Not sure what you are trying to block... /31 would be:194 = network address. 195 = broadcast address. No host addresses. Trying to block a P2P link?
https://datatracker.ietf.org/doc/html/rfc3021
@Anna-Count See the above. /31 are only for point to point links so pfBlocker most likely has no idea what they are.
-
Thank you for your reply.
I think perhaps some clarification of what I'm doing and how I'm doing it is required.
I have pfSense 2.6.0 and pfBlockerNG-devel 3.1.0_4 (virtual on Proxmox) in front of servers (also on Proxmox) running web, email and database services.
Ports such as 22 and 3306 use a whitelist so that only select IP addresses and networks can connect. This whitelist may have /32 and /24 but generally does not have any /31. I generally don't bother aggregating the whitelist because it is short.
This works perfectly and gives me peace of mind that brute forcers can't even connect, even if they did find a valid password or 0-day exploit.In Firewall / pfBlockerNG / IP I have CIDR Aggregation enabled.
Ports such as 25,80,443,587,993 cannot use a whitelist for inbound connections because it's not possible to know all specific IPs in advance.
However, there are plenty of countries which myself and my clients do no business with, so GeoIP is set up to deny those countries inbound access. These are generally countries in which English is rarely used but there are exceptions.
There are plenty of countries, including my own country, which I can't block and there are plenty of brute forcers and spammers in those countries. To fix that I compile my own blacklist. The blacklist currently has about 40,000 entries and it requires System / Advanced / Firewall & NAT Firewall Maximum Table Entries to be set higher than default. The blacklist is served from a web server on the same system and is included in the IPv4 Source Definitions list under Firewall / pfBlockerNG / IP / IPv4 PRI1 and PRI1 is set to Deny Inbound. PRI1 is the last entry in the rules list at Firewall / pfBlockerNG / IP / IPv4. In Firewall / Rules / WAN the pfB_PRI1_v4 rule is above the pass rules for 25,80,443,587,993.
I've now got the process of updating the blacklist down to a few minutes per day with the help of log filtering in pfSense (would be nice if it could save that). And it only takes a few minutes to check that port 25 didn't deny a wanted inbound email.
Before updating the blacklist on my server, I aggregate it as follows.
Just for example purposes, suppose I compile a list which includes the following. This is not a list I actually use and I'm not implying that these IP addresses are doing anything wrong or should be blocked. My actual list is 40,000 lines.
212.193.29.0/24
167.172.169.50/32
167.172.169.51/32
167.172.169.133/32
167.172.169.134/32
167.172.169.170/32Now I aggregate my list on a Debian bullseye server.
cat list | aggregate > blacklist.txt
This produces the following list which is used by pfSense in PRI1 as described above.
167.172.169.50/31
167.172.169.133/32
167.172.169.134/32
167.172.169.170/32
212.193.29.0/24I haven't tested this specific list but I will now likely find that 167.172.169.51 is not denied inbound.
If this is expected behavior of pfBlockerNG then I will have to write something to process my aggregated list so that all /31 are turned into two /32 entries.
It appears that other lists in PRI1 such as
https://www.spamhaus.org/drop/edrop.txt
don't contain any /31 -
@anna-count It's probably expected.
I guess the question would be "Why would you want to block a point to point?" but that's just a guess.
I use /31's for my VPN connections so pfSense does work with them but pfBlocker probably does not.
Just a guess though.