Interface Groups - change name loses rules

[dszp]

In the snapshot from the evening of August 1st, I have an Interface Group called NoWifi. I've added one rule to the interface group. Then I went to the Interface Group tab on If->(assign) and edited the group, changed the name by one character (to NotWifi), and saved it. When I go to Firewall->Rules, now the new group name is there but there are no rules. I also started getting messages in the system log like:

Aug 3 17:07:17	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em3 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'
Aug 3 17:07:17	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em2_vlan3456 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'
Aug 3 17:07:17	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em2_vlan7 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'
Aug 3 17:07:17	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em1 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'
Aug 3 13:51:37	check_reload_status: syncing firewall
Aug 3 13:51:08	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em2_vlan7 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'
Aug 3 13:51:08	php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em1 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'

Changing the name of the group back to NoWifi (original name) brings back the firewall rule that was "missing" and the error stops logging in the System log. I did not add or change any rules while the interface was renamed. Obviously the expected behavior is that changing the interface group name should update all rules and everything should look/work the same as if the name were never changed, only displaying the new name now.

I assume this is a bug, and haven't seen it mentioned, but I haven't searched redmine thoroughly. Make sense? New issue?

Also, I haven't seen documentation on whether rules in Interface Groups are considered to be above or below direct interface rules order-wise, since most of the docs are for 1.2.3 still, and I know I've seen somewhere that mentioned whether floating rules were before or after interface rules…but can't recall. Any brief insight? Thanks.

[cmb]

http://redmine.pfsense.org/issues/792

[eri--]

Group rules are the same as interface rules no difference there.

[dszp]

I haven't tried renaming an interface after creating rules for it, but I assume if I did so, the rules that applied to the interface under the old name would still apply to the same interface with the new name, right? Anyway, since the rules become inaccessible via the GUI after a group name change but still exist (since they show back up after it's renamed back to the original), I fail to see how that would not be a bug, to allow rules to exist but not be displayed anywhere or be editable without remembering what an old interface group was named?

[eri--]

For interfaces is different anyway.
Please update anew snapshot to chek if renaming groups is ok or not.

[dszp]

Updated in redmine, no change observed.

[dszp]

@ermal:

Group rules are the same as interface rules no difference there.

If this is the answer you were referring to in the other thread, I didn't realize it was a response to my rule order question until just now when I went back and looked based on the other thread. But order should matter…within an interface, if I put an deny rule first and a pass rule second, the traffic will still be blocked because the deny matched first. Interface group rules would need to be positioned either "above" or "below" rules in an interface when evaluated. So my question is, if I put a deny rule on an interface, and a pass rule on a group containing that interface, which would be evaluated first? Would the traffic pass or not? And vice versa. I don't think that's an unreasonable question, and I don't understand how your answer addresses that question if it does.

[eri--]

Oh you mean in the firewall itself, pf(4)!

I though you meant from the GUI prespective. Than the answer is the interface wins over groups.

[dszp]

Excellent, thanks. Working with 7+ interfaces and trying to design some fun routing/rules, will make use of Interface Groups heavily I think, but need to know how to visualize their interactions with interface rules in my head when putting them together and troubleshooting! Where do Floating rules fit in, do they lose to both interfaces and groups, or do they come "first?"

[Efonnes]

If the floating rules do come first, you can either have rules that are overridden by the next matching rule or that take effect without checking any further rules.

In 2.0, internal firewall rules actually come before all user-defined rules (possibly with some small exceptions), but are setup so they are overridden if another rule matches.

[dszp]

Thanks. I haven't done much with Floating rules yet because they are new and I'm working on understanding everything else first :-) Though I've seen them in a few examples around the 'net including the IRC channel and forums–been reading the pfSense book but obviously that doesn't cover them yet since they're new to 2.0.

Also, confirmed that the original bug from this thread is fixed in the latest snapshot from Friday (Aug. 6th afternoon).

[Efonnes]

I just realized while working on something else that if you look at the ID numbers, that may tell you the order the rules will be parsed.  I haven't looked at the code to confirm this, though.