Bug #3854
closedpf on 2.2 should not have an upper table entry limit, but generates errors with large datasets
0%
Description
On 2.2 (FreeBSD 10.x base), pf is not supposed to have an upper table size limit. The knob to set it has been removed, and yet if a sufficiently large dataset is configured, an error is produced:
pfctl: Bad address.
See https://forum.pfsense.org/index.php?topic=80856.0 for more info.
Files
Updated by Ermal Luçi over 9 years ago
- Status changed from New to Closed
The table entries limit is still there
maximumtableentries os system->Advanced.
What has changed is that there is no more a limit on number of tables present in a ruleset.
Updated by Bill Crowder over 9 years ago
Ermal,
When I ran the tests shown in forum post I had tried from 1000000 to 20000000 in System: Advanced: Firewall and NAT: Firewall Maximum Table Entries.
If you will look at Bug#3791 i have more details.
Firewall Maximum Table Entries has no effect on pfSense 2.2 as of yesterdays snapshot. This is easily repeatable.
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(8): ls -la pfB_BTLevel1.txt
-rw-r--r-- 1 root wheel 3817312 Sep 8 16:20 pfB_BTLevel1.txt
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(9): pfctl -t pfB_BTLevel1 -T replace -f /var/db/aliastables/pfB_BTLevel1.txt
pfctl: Bad address.
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(10):
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(12): pfctl -sm
states hard limit 1000000
src-nodes hard limit 1000000
frags hard limit 5000
table-entries hard limit 2000000
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(13):
Updated by Bill Crowder over 9 years ago
Better more concise details with Table-entries set at 1,000,000, have also tried 10,000,000.
This list will load correctly initially, but fails upon updating with pfctl -t ALIASNAME -T replace -f FILE with bad alias.
This list is 227,380 IP's.
pa-r- pfB_BTLevel1
Addresses: 227380
Cleared: Tue Sep 9 19:49:40 2014
References: [ Anchors: 0 Rules: 1 ]
Evaluations: [ NoMatch: 1432 Match: 42 ]
In/Block: [ Packets: 42 Bytes: 3760 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
In/XPass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
Out/XPass: [ Packets: 0 Bytes: 0 ]
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(9): pfctl -t pfB_BTLevel1 -T replace -f /var/db/aliastables/pfB_BTLevel1.txt
pfctl: Bad address.
2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(12): pfctl -sm
states hard limit 1000000
src-nodes hard limit 1000000
frags hard limit 5000
table-entries hard limit 2000000
[2.2-ALPHA][root@router.crowderfarm.local]/var/db/aliastables(13):
Updated by Bill Crowder over 9 years ago
To show that it works on 2.1.4... This is the same exact list being replaced on 2.1.4. The list has a different alias name on my 2.1.4 VM then my 2.2 VM, but it is the same list being updated with a copy of the list that fails on 2.2. This is to show this is a regression++ and to show the the /pfB_BTLevel1.txt in the above examples is functional on 2.1.4.
[2.1.4-RELEASE][root@router.crowderfarm.local]/var/db/aliastables(6): pfctl -t pfBlockerP2P -T replace -f /var/db/aliastables/pfB_BTLevel1.txt
3702 addresses added.
33472 addresses deleted.
Updated by Bill Crowder over 9 years ago
This is an issue that needs to be addressed before 2.2 is released. This problem does not exist in 2.1.4.
Updated by Ermal Luçi over 9 years ago
- Status changed from New to Feedback
Patch has been merged in to fix the wrong ioctl handling.
Please test newer snapshots.
Updated by Bill Crowder over 9 years ago
Tested this with several very large lists. I think it can be changed to resolved. Thanks.
Updating: pfB_IBlock
68 addresses added.1070 addresses deleted.
Updating: pfB_PRI2
31 addresses added.456 addresses deleted.
Updating: pfB_SEC1
8 addresses added.330 addresses deleted.
Updating: pfB_ET_IPrep
51 addresses added.1696 addresses deleted.
Updating: pfB_BT_Level1
75 addresses added.
Updating: pfB_IPv6Test
no changes.
Updated by Ermal Luçi over 9 years ago
- Status changed from Feedback to Resolved
This can be marked as resolved.
Though general issues are to be solved in FreeBSD for this....