Bug #136
closed
Issues with linked filter/NAT rules
100%
Description
1) Multiple NAT rules can be assigned the same filter rule
2) when removing the link (i.e. switching to "pass" or "none", the linked rule isn't deleted (should it be? probably yes)
3) The destination IP and port of linked rules can be edited in firewall_rules_edit.php and shouldn't be. Source should be editable but not destination, since that should strictly be tied to the NAT rule.
4) If you edit the source in a linked firewall rule, it gets overwritten when you edit the NAT rule. The NAT rule should never touch the firewall rule source after the rule exists.
Updated by Pierre POMES over 14 years ago
- Status changed from New to Assigned
- Assignee set to Pierre POMES
Updated by Chris Buechler over 14 years ago
there is a merge request that fixes this.
http://rcs.pfsense.org/projects/pfsense/repos/mainline/merge_requests/45
just needs to be committed, not sure if merges are working again.
Updated by Pierre POMES over 14 years ago
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
Ok, merge done manually (since the merge is not functionnal)
Updated by Chris Buechler over 14 years ago
- Status changed from Feedback to Resolved
this is all good now (after a minor fix I just committed)
Updated by Scott Ullrich over 14 years ago
- Status changed from Resolved to New
Unfortunately there is a new problem with the link on the firewall nat edit screen.
In my case the id of the rule is 0 but the link points to id 1 which does not exist.
Updated by Chris Buechler over 14 years ago
You on the latest code? I fixed the ID being off by one yesterday, it's working for me now.
Updated by Scott Ullrich over 14 years ago
Yes, latest code. Just sync'd again to make sure.
You can see the rule on my primary firewall. It's @thompsa's rule.
Updated by Pierre POMES over 14 years ago
Maybe another issue: if you delete a firewall rule linked to a NAT rule, the NAT rule remains associated to this (deleted) rule. "Filter rule association" should be set to NONE here ?
Updated by Scott Ullrich over 14 years ago
Yes, need to unassociate the rule upon deletion.
Updated by Chris Buechler over 14 years ago
I'd prefer prohibiting deletion of a linked firewall rule. If the NAT rule is deleted, the associated firewall rule is deleted. Unassociating in the NAT rule also removes the firewall rule.
Updated by Pierre POMES over 14 years ago
Ok Chris, that sounds logical.
Just a note for Scott: I am also unable to reproduce the problem you reported about the link id on my box. Do you still have it ?
Updated by Chris Buechler over 14 years ago
I also can't reproduce that problem, and don't appear to have access to Scott's firewall at the moment. Scott, if you can add me on your WAN rules I'll take a look.
Updated by Scott Ullrich over 14 years ago
Firewall rule added for HTTPS from 74.132.200.XXX
Updated by Scott Ullrich over 14 years ago
- Status changed from New to Feedback
I deleted the original entry and added a new one and its working. I think that was artifacts from the entry created prior to the fix.
Updated by Scott Ullrich over 14 years ago
- Status changed from Feedback to New
Spoke too soon. I deleted a rule and now its pointing to a new entry.
This is probably the wrong approach altogether. When creating the firewall nat port forward we should use the GUID library to create a GUID and use that value to link the two rules.
Updated by Scott Ullrich over 14 years ago
Information about our UUID library: http://www.shapeshifter.se/2008/09/29/uuid-generator-for-php/
filename is uuid.inc
Updated by Ermal Luçi over 14 years ago
There is no need for guid since its slow.
Take a look at the schedules code it uses something like this with uinque()
Updated by Chris Buechler about 14 years ago
- Status changed from Feedback to Resolved
everything here seems to be taken care of, though there is at least one minor issue related to this code, we'll open new tickets for any outstanding issues.