| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #2892
I made a "nasty" list as follows:
192.168.100.0-192.168.101.255
192.168.103.8-192.168.103.23
192.168.104.1-192.168.104.254
192.168.105.22-192.168.106.66
192.168.107.3-192.168.107.33
And this code turns it into:
192.168.100.0/23
192.168.103.8/29
192.168.103.16/29
192.168.104.1/32
192.168.104.2/31
192.168.104.4/30
192.168.104.8/29
192.168.104.16/28
192.168.104.32/27
192.168.104.64/26
192.168.104.128/26
192.168.104.192/27
192.168.104.224/28
192.168.104.240/29
192.168.104.248/30
192.168.104.252/31
192.168.104.254/32
192.168.105.22/31
192.168.105.24/29
192.168.105.32/27
192.168.105.64/26
192.168.105.128/25
192.168.106.0/26
192.168.106.64/31
192.168.106.66/32
192.168.107.3/32
192.168.107.4/30
192.168.107.8/29
192.168.107.16/28
192.168.107.32/31
Which is the correct group of CIDRs to represent the given ranges.
|
|
|
| |
Small cleanup for readability
|
|
|
| |
Net masking math was off by 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because all three cases (CIDR, IP Range, and Single IP Address) are always
tested, it is possible that more than one will have a positive match.
Examples:
172.16.0.0/12 matches both for CIDR and Individual IP Address
169.254.0.0-169.254.255.255 matches for both Address Range and Individual IP
By doing if, elseif, elseif instead of if, if, if testing, the later tests
will only be performed if the former tests fail. Because the Individual IP
Address test will return a result, even for CIDRs and IP Ranges, that test
has been moved to the end of the elseif list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several IP address ranges were being calculated improperly.
Examples:
10.0.0.0-10.255.255.255 became 160.0.0.0/8
65.113.241.0-65.113.241.255 became 130.227.226.0/24
72.165.61.0-72.165.61.255 became 145.74.122.0/24
The use of complicated string and regular expressions to calculate netmasks
has been replaced with basic and proper bit masking.
|
|
|
| |
Sorry guys - I missed out an equals sign here, the logic ended up only applying rules to the first interface, and not for others.
|
|
|
|
| |
If users move rules around in the GUI, the the rules for 1 interface can end up in separate blocks in config.xml. This causes pfBlocker code to put a set of pfBlocker rules before each separate block of rules for an interface, as they are processed out of config.xml.
The code here fixes that, ensuring that pfBlocker rules are only added once to an interface, the first time the interface is found in a rule.
|
| |
|
|
|
|
| |
This reverts commit 4149a349b894688723810e4886c95205dc34058f.
|
| |
|
|\
| |
| | |
Code formatting of pfblocker.inc
|
| |
| |
| |
| | |
consistent throughout. This should make it easier to debug in future, as it is now easy to see which code is nested in which loops.
|
|/ |
|
|
|
|
| |
floating rules with interface="" mixed in the config filter rule list.
|
|
|
|
| |
otherwise warnings are reported when the array is empty.
|
| |
|
| |
|
| |
|
|
|
|
| |
rules and update country lists
|
| |
|
| |
|
| |
|
|
|
|
| |
rule package count
|
| |
|
|
|
|
| |
package function
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|