NAT & Filter Association Comes Loose
-
NAT & Filter association comes loose when rules order is changed.
- Create a new associative NAT rule, save and apply changes.
- Move the new NAT rule from the bottom of the NAT rules list to the top, and apply changes.
- Go to the firewall rules and move the NAT associated rule from the bottom of Firewall rules list to the top, and apply changes.
- Edit the NAT rule to add a source address, save and apply changes.
- The source address is not applied / updated to the firewall filter rule.
Prior to moving the order of the rules adding and changing NAT rule source address works and is applied to the firewall rule.
There is still an association between the two though because deleting the NAT rule also still deletes the firewall rule.
-
Is there something special about moving it that causes it? Does it happen to you if you don't move them? Meaning if you add a nat rule and then immediately go back and edit the source.
-
". . . if you add a nat rule and then immediately go back and edit the source."
Yes that works (until they are moved).Apparently there is something about moving them that changes because until they are moved it works.
-
Is it isolated to just moving the filter rule, or just moving the nat rule? Or does it have to be both?
They use a random associated ID tag, so I don't see how moving them would really make any difference, but if you can narrow it down and then do a before/after config diff, it may help shed some light on what is happening.
-
Okay little narrower case here.
Problem is consistently reproducible by creating a NAT with source restriction, then moving the associated rule from the bottom to the top of rules list (right below the private and bogon rules). Then changing source restriction via NAT. The source restriction changes in NAT but not in rule.
Moving another rule to the top spot (above the NAT associated rule) and it again works.
Seems the NAT associated rule has problems being first in the list.
-
Ah, I see what happened there.
The function tests if the result == false, but if the result is 0, that is equal to false in PHP. It needs a more strict type match (=== not ==).
Try this:
https://github.com/bsdperimeter/pfsense/commit/752c6ca8117e05e6bb74115d2199dab7ff99168d -
That works. Good job. Thanks.