Bug #5845
closed
New URL Table (Ports) alias can cause invalid ruleset when alias changes not yet applied
Added by Alex Vergilis almost 9 years ago. Updated almost 9 years ago.
0%
Description
When creating new URL Table (Ports) Alias entry, the entry needs to be saved twice in order for the values to be downloaded, otherwise newly created rules with the new Alias entry will not be resolved, and will produce an error.
Updated by
Updated by Anonymous almost 9 years ago
- Status changed from New to Feedback
- Assignee changed from Anonymous to Alex Vergilis
Unable to reproduce.
Created file sbeaver.com/iplist.txt
Created new URL alias speifying that URL
Clicked "Save" and the IPs listed in the file appeared in the alias and in config.xml
Clicked "Apply"
Left the file in place for others to test.
Updated by Alex Vergilis almost 9 years ago
"URL Table (IPs)" list works fine.
The issue is only with the "URL Table (Ports)" alias entry
Updated by Anonymous almost 9 years ago
Just to be sure, you are referring to: firewall_aliases_edit.php?tab=url and select Type = Port(s) ?
Updated by Alex Vergilis almost 9 years ago
The issue is not with "Port(s)"
The issue is with "URL Table (Ports)"
In firewall_aliases_edit.php
Firewall > Aliases > Add
Type = URL Table (Ports)
Updated by Anonymous almost 9 years ago
Sorry but we are still unable to reproduce this. A list of ports in a text file saved on an HTTP server is download and added to the ruleset immediately.
Updated by Chris Buechler almost 9 years ago
also not seeing any way of making that happen, on 2.2.x nor 2.3. Add a ports URL table alias, and it's in the ruleset immediately after applying changes.
There is an issue if you give it a URL that returns bogus data, it puts it into the ruleset and could leave you with a broken ruleset. That wouldn't change on the second attempt to fetch though, unless the web server in question is somehow returning bunk data on the first download only.
Updated by Alex Vergilis almost 9 years ago
Its your call for fix deliverability to a specific version. I have "work around".
I can definitely reproduce this on every singe firewall for every single "URL Table (Ports)" entry.
Not a problem with a web server as AWS S3 with Cloudfront is used without any errors in the logs.
I use https to retrieve the URL.
Steps:
1 - create an alias entry of "URL Table (Ports)" and call it TestPorts pointing to https://pfsense.example.com/config/test_tcp_ports.txt, for example
2 - Save and Apply
3 - Create a rule, say allow all tcp ports in and set "Destination port range" to be TestPorts
4 - Save and Apply
5 - Wait for filters to reload
6 - goto to system log, and you will see an entry similar to:
php-fpm[]: /rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:193: syntax error - The line in question reads [193]: pass in quick on $WAN reply-to ( em1 10.0.0.1 ) inet proto tcp from any to any port $TestPorts tracker 1454966370 flags S/SA keep state label "USER_RULE"
7 - Edit the TestPorts alias entry
8 - do not make any changes
9 - repeat steps 2 - 4 above and everything will work fine
I can certainly provide my URL through a PM
Please let me know if I can assist further.
Updated by Chris Buechler almost 9 years ago
could you email me the URL, Alex? cmb at pfsense dot org
Updated by Chris Buechler almost 9 years ago
- Subject changed from New URL Table (Ports) Alias entries need to be saved twice to New URL Table (Ports) alias can cause invalid ruleset when alias changes not yet applied
- Status changed from Feedback to Confirmed
- Assignee changed from Alex Vergilis to Chris Buechler
- Affected Version changed from 2.2.5 to All
Finally found a way to replicate. This is what happens when you add a URL Table ports alias, don't apply changes in aliases, then go add a firewall rule using the new alias and apply the firewall rule changes without applying the alias changes. The first filter reload after applying changes on aliases is fine.
It only applies to ports URL table aliases by the nature of how they work, the other URL table types use pf tables and aren't affected. They won't be populated until after applying changes, but their absence won't cause an invalid ruleset.
There is a secondary issue that falls under #5848, Alex's alias file had CR+LF newlines, which end up getting trimmed out but only after the second processing of the file. I'll cover that in #5848.
Updated by Alex Vergilis almost 9 years ago
FYI - In my case, the issue exists even after applying the changes of Alias creation, and then creating the rule.
Updated by Chris Buechler almost 9 years ago
Alex Vergilis wrote:
FYI - In my case, the issue exists even after applying the changes of Alias creation, and then creating the rule.
In that case that's just because the CR+LF doesn't get stripped until the second processing and its presence also makes the ruleset fail to load. So I actually changed the issue here, but your original issue is covered by #5848.
Updated by Chris Buechler almost 9 years ago
- Status changed from Confirmed to Resolved
the remaining issue here outside all the validation added in #5848 fixed by validating URL table ports alias is valid before using it in a rule.