Project

General

Profile

Actions

Bug #5845

closed

New URL Table (Ports) alias can cause invalid ruleset when alias changes not yet applied

Added by Alex Vergilis about 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
Rules / NAT
Target version:
Start date:
02/06/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

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.

Actions #1

Updated by Jim Thompson about 8 years ago

  • Assignee set to Anonymous
Actions #2

Updated by Anonymous about 8 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.

Actions #3

Updated by Alex Vergilis about 8 years ago

"URL Table (IPs)" list works fine.

The issue is only with the "URL Table (Ports)" alias entry

Actions #4

Updated by Anonymous about 8 years ago

Just to be sure, you are referring to: firewall_aliases_edit.php?tab=url and select Type = Port(s) ?

Actions #5

Updated by Alex Vergilis about 8 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)

Actions #6

Updated by Anonymous about 8 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.

Actions #7

Updated by Chris Buechler about 8 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.

Actions #8

Updated by Alex Vergilis about 8 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.

Actions #9

Updated by Chris Buechler about 8 years ago

could you email me the URL, Alex? cmb at pfsense dot org

Actions #10

Updated by Chris Buechler about 8 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.

Actions #11

Updated by Alex Vergilis about 8 years ago

FYI - In my case, the issue exists even after applying the changes of Alias creation, and then creating the rule.

Actions #12

Updated by Chris Buechler about 8 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.

Actions #13

Updated by Chris Buechler about 8 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.

Actions

Also available in: Atom PDF