Project

General

Profile

Bug #5532

Edit floating rules wrong default values

Added by Robbert Rijkse over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Web Interface
Target version:
Start date:
11/24/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.3
Affected Architecture:

Description

When editing floating rules there seem to be a couple of default values loaded that are not what was saved.

1. The interfaces the rule applies to is not selected. Screenshot attached (Selection_003.jpg).
2. Under "Advanced options". The "In/Out Pipe" selection has the first option selected instead of "None". Screenshot attached (Selection_004.jpg).

The second issue prevents the page from saving (See Selection_002.jpg Screenshot), but if you don't select the interface each time this values is lost and the rule effectively becomes disabled.

You can easily reproduce this by creating any floating rule and then editing it.

Selection_003.jpg (23.3 KB) Selection_003.jpg Robbert Rijkse, 11/24/2015 06:10 PM
Selection_002.jpg (273 KB) Selection_002.jpg Robbert Rijkse, 11/24/2015 06:10 PM
Selection_004.jpg (85.2 KB) Selection_004.jpg Robbert Rijkse, 11/24/2015 06:10 PM
Selection_006.jpg (158 KB) Selection_006.jpg Robbert Rijkse, 11/25/2015 11:24 PM
floating rules snippet.txt (2.46 KB) floating rules snippet.txt Robbert Rijkse, 11/29/2015 11:02 AM
Selection_008.jpg (268 KB) Selection_008.jpg Robbert Rijkse, 11/29/2015 07:54 PM

Associated revisions

History

#1 Updated by Robbert Rijkse over 3 years ago

Additional finding is that the rules are not applied properly when you select an interface group as one of the selections (not sure if these should be an option).

#2 Updated by Chris Buechler over 3 years ago

  • Category changed from Rules/NAT to Web Interface
  • Status changed from New to Confirmed
  • Assignee set to Steve Beaver

Confirmed. To replicate, add a floating rule specifying one or more interfaces, on a system with limiters defined. Edit the rule, and no interfaces are selected, and it selects the limiters rather than "none".

Robbert: the interface groups not applying, is that with floating rules, or? Sounds like that's a separate issue.

#3 Updated by Robbert Rijkse over 3 years ago

Actually did some more testing today and it looks like the floating rule stops working all together after saving it in the interface. After a configuration restore the floating rules work fine, but as soon as I edit one of the rules it stops working after a save and apply.

In my case I have two rules that provide DNS and NTP access to all the internal VLANs and after editing the DNS rule had to manually add a rule on every interface to get the traffic to be allowed.

I have attached a screenshot of the rules and I have a status_output.tgz and have no issue providing it but I don't think I can mark the bug as private anymore.

#4 Updated by Steve Beaver over 3 years ago

Corrected the interface selector initial values for floating rules.

#5 Updated by Steve Beaver over 3 years ago

  • Status changed from Confirmed to Feedback
  • Assignee changed from Steve Beaver to Robbert Rijkse

#6 Updated by Steve Beaver over 3 years ago

  • % Done changed from 0 to 100

#7 Updated by Robbert Rijkse over 3 years ago

I Upgraded to 20151128-2200 and this is what I noticed:

1. The correct interfaces are now selected by default on Floating rules, so that is fixed.
2. The interface selection is now missing the "Interface Groups" and this is true for all floating and non-floating rules, which means you can no longer edit/create rules for "Interface Groups".
3. The first limiter is still selected instead of "None"
4. The saved floating rules are still not working, which I will open up a separate bug for.

Thanks,

Robbert

#8 Updated by Robbert Rijkse over 3 years ago

Found a couple more things and don't think this needs a new bug report after all.

1. The option under Quick: "Apply the action immediately on match." does not save.
2. There is a "Floating" section whithout any options.

I think #1 is actually causing my floating rules not to function. My two rules are below, the first one I edited in the interface and second I have not touched, the only difference is that the quick option is not saved.

<filter>
<rule>
<id/>
<tracker>1422128822</tracker>
<type>pass</type>
<interface>opt3,opt4,opt5,opt9,opt10,opt11,opt12,opt13,opt14,opt15,opt16,opt17,opt18</interface>
<ipprotocol>inet46</ipprotocol>
<tag/>
<tagged/>
<direction>any</direction>
<floating>yes</floating>
<max/>
<max-src-nodes/>
<max-src-conn/>
<max-src-states/>
<statetimeout/>
<statetype>keep state</statetype>
<os/>
<protocol>tcp/udp</protocol>
<source>
<any/>
</source>
<destination>
<address>Server_DNS_Resolver</address>
<port>53</port>
</destination>
<descr><![CDATA[Allow all clients access to Internal DNS Resolvers]]></descr>
<vlanprio>0</vlanprio>
<vlanprioset>0</vlanprioset>
<created>
<time>1422128822</time>
<username></username>
</created>
<updated>
<time>1448814945</time>
<username></username>
</updated>
</rule>
<rule>
<id/>
<tracker>1423429022</tracker>
<type>pass</type>
<interface>Servers,opt4,opt5,opt6,opt7,opt8,opt9,opt10,opt11,opt12,opt13,opt14,opt15,opt16,opt17,opt18</interface>
<ipprotocol>inet46</ipprotocol>
<tag/>
<tagged/>
<direction>any</direction>
<quick>yes</quick>
<floating>yes</floating>
<max/>
<max-src-nodes/>
<max-src-conn/>
<max-src-states/>
<statetimeout/>
<statetype>keep state</statetype>
<os/>
<protocol>tcp/udp</protocol>
<source>
<any/>
</source>
<destination>
<address>Server_Time</address>
<port>123</port>
</destination>
<descr><![CDATA[Allow all clients access to Internal NTP Server]]></descr>
<updated>
<time>1423429022</time>
<username></username>
</updated>
<created>
<time>1423429022</time>
<username></username>
</created>
</rule>

I can confirm this if I look at /tmp/rules.debug using the tracker numbers from the config.

[2.3-ALPHA][]/tmp: cat rules.debug | grep 1422128822
pass on { em2 em1 em3 em4 em5 em6 em7 em8 em9 em10 em11 em12 } inet proto { tcp udp } from any to $Server_DNS_Resolver port 53 tracker 1422128822 keep state label "USER_RULE: Allow all clients access to Internal DNS Resolvers"
pass on { em2 em1 em3 em4 em5 em6 em7 em8 em9 em10 em11 em12 } inet6 proto { tcp udp } from any to $Server_DNS_Resolver port 53 tracker 1422128822 keep state label "USER_RULE: Allow all clients access to Internal DNS Resolvers"
[2.3-ALPHA][]/tmp: cat rules.debug | grep 1423429022
pass quick on { Servers em2 em1 em3 em4 em5 em6 em7 em8 em9 em10 em11 em12 } inet proto { tcp udp } from any to $Server_Time port 123 tracker 1423429022 keep state label "USER_RULE: Allow all clients access to Internal NTP Server"
pass quick on { Servers em2 em1 em3 em4 em5 em6 em7 em8 em9 em10 em11 em12 } inet6 proto { tcp udp } from any to $Server_Time port 123 tracker 1423429022 keep state label "USER_RULE: Allow all clients access to Internal NTP Server"
[2.3-ALPHA][]/tmp:

#9 Updated by Robbert Rijkse over 3 years ago

Well that doesn't seem to have saved properly since I forgot to put "pre" around it. To make it easier I have attached it as a txt file.

#10 Updated by Steve Beaver over 3 years ago

Thanks for the thorough report and the text file. That will really help. This file was converted to Bootstrap early on in the project and I think a lot has been learned since then :)

I'll look into the items you have listed here later today.

#11 Updated by Steve Beaver over 3 years ago

A typo prevented the IF Groups from loading, the "Quick" input had the wrong name, and the wrong array type was being used for the limiters. (A simple array was being used when an associative array of options => values is required.)

Hopefully this will work better for you. Please let me know.

#13 Updated by Robbert Rijkse over 3 years ago

The quick input part has definitely been fixed, which also means that the rules work now! The in/out limiter still has the first limiter in the list selected instead of none. When trying to save the rule without fixing the selection I get the input error "You can not use limiters in Floating rules without choosing a direction.", but also the PHP error below and all the selections are empty.

Warning: explode() expects parameter 2 to be string, array given in /usr/local/www/firewall_rules_edit.php on line 1151 Call Stack: 0.0001 257872 1. {main}() /usr/local/www/firewall_rules_edit.php:0 0.3623 2708128 2. explode() /usr/local/www/firewall_rules_edit.php:1151

I attached a screen shot and uploaded the crash report.

The rules do save fine when you fix the in/out limiter and set it to "none".

Thanks for all the help fixing this.

#14 Updated by Steve Beaver over 3 years ago

I am checking with the 2.2 devs, but from what I can see the code in 2.2 more or less works by accident :) When the file was converted to bootstrap it was replicated in a way that no longer worked.

I have made some changes that I think may correspond to what was originally intended. Let me know if it helps please.

#16 Updated by Robbert Rijkse over 3 years ago

That seems to have done it! The floating rules save/apply properly and the default selection for the in/out,quick and interfaces is correct.

Thanks!

#17 Updated by Steve Beaver over 3 years ago

  • Status changed from Feedback to Resolved

Yay!

Thanks for the clear instruction and for the testing.

Also available in: Atom PDF