https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162021-11-18T13:09:56ZpfSense bugtrackerpfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574572021-11-18T13:09:56ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Rejected</i></li></ul><p>I can't replicate this as stated and there isn't nearly enough detail to guess what might be happening in your environment. I can use groups starting with a digit without error. If the config rolls back that's typically from a non-XML-safe character being used (like an international accented character, unicode, etc) in a field that doesn't get CDATA escaped, not from a leading digit.</p>
<p>This site is not for support or diagnostic discussion.</p>
<p>For assistance in solving problems, please post on the <a href="https://forum.netgate.com" class="external">Netgate Forum</a> and include the <strong>full</strong> error message along with relevant portions of your configuration.</p>
<p>See <a href="https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html" class="external">Reporting Issues with pfSense Software</a> for more information.</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574592021-11-18T14:06:14ZJens Groh
<ul></ul><p>I didn't think it would be hard to reproduce. Nice if it works for you, Jim, but no it is nothing about special characters.<br />I just did test it again on different systems - same problem again:</p>
<p>1) Interface Assignments, Interface Groups<br />2) Create Group with name "0Test", added 3 Vlans to it<br />3) Got to Firewall/Rules<br />4) Add+ Rule on 0Test Tab<br />5) add simplest rule (pass from 1.2.3.4 port any to any - simple)<br />6) save (<a class="external" href="https://i.imgur.com/x5ri5hS.png">https://i.imgur.com/x5ri5hS.png</a>)<br />7) you get to the 0Rule tab with NO rule visible but you get an red error bubble immediatly</p>
<p>Message: pfSense is restoring the configuration /cf/conf/backup/config-1637265144.xml @ 2021-11-18 20:58:19</p>
<p>System log shows errors:<br /><pre>
Nov 18 20:58:19 php-fpm 13739 /firewall_rules_edit.php: New alert found: pfSense is restoring the configuration /cf/conf/backup/config-1637265144.xml
Nov 18 20:58:19 php-fpm 13739 /firewall_rules_edit.php: pfSense is restoring the configuration /cf/conf/backup/config-1637265144.xml
Nov 18 20:58:19 php-fpm 13739 /firewall_rules_edit.php: XML error: XML_ERR_NAME_REQUIRED at line 8487 in /conf/config.xml
</pre></p>
<p>Same behavior on my testbox with SG2100 on 21.05.1</p>
<p>When you check the rules.debug file in /tmp, you'll find no trace of an Alias or IF Group named "0Test". If you go to the Interface Group and rename it to e.g. "ATest" and do the steps again -> all working. Rule gets saved. If you rename the Group back to "0Test" the rule is still there, but if you try to save you get an error again. If you check the /tmp/rules.debug the pf.conf still has the last working Group name (ATest) in it, 0Test wasn't even correctly saved and written to rules.debug or pf.conf.</p>
<p>So if that works for you, great but I'm very much interested in how that is a problem with special character or umlauts or something along those lines if everything we did while testing was use the exact allowed character set as quoted from the group interface page. :)</p>
<p>Cheers</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574632021-11-18T14:26:00ZJim Pingle
<ul><li><strong>File</strong> <a href="/attachments/3944">clipboard-202111181525-fvlzj.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3944/clipboard-202111181525-fvlzj.png">clipboard-202111181525-fvlzj.png</a> added</li></ul><p>Maybe it's already been fixed on 22.01 then. I get a rule in the GUI tab and in /tmp/rules.debug.</p>
<pre>
0blah = "{ 0blah }"
pass in quick on $0blah inet proto tcp from any to any tracker 1637262430 flags S/SA keep state label "USER_RULE: blah test"
</pre><br /><img src="https://redmine.pfsense.org/attachments/download/3944/clipboard-202111181525-fvlzj.png" alt="" /> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574642021-11-18T14:47:27ZJens Groh
<ul></ul><p>Please have a look at <a class="external" href="https://forum.netgate.com/topic/167988/pot-bug-s-with-interface-groups-firewall-rules">https://forum.netgate.com/topic/167988/pot-bug-s-with-interface-groups-firewall-rules</a></p>
<p>I did a further check and I can reproduce the problems on either 21.05.x and 2.5.2. Starting a group name with a digit initially like your 0blah throws errors and problems if you want to add the first rule. If you manage to make a save/apply that actually writes the filter config, then it seems the group name gets written down (what seems to be missing initially) and rules can be created without problems. But a groupname starting with a digit that gets freshly created seems to miss some pointers as it somehow writes the groups tag on the interfaces correctly but seems to have problems with the first rule being written to rules.debug and the filter config.</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574652021-11-18T14:58:58ZJim Pingle
<ul><li><strong>Subject</strong> changed from <i>creation of groups numbers allowed but rules create errors and rollbacks</i> to <i>Interface group name starting with a digit creates invalid XML for rule separators</i></li><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Confirmed</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Very Low</i></li></ul><p>That isn't quite right either, see my reply on your forum thread. The problem is actually separators being in the configuration:</p>
<pre><code class="xml syntaxhl"> <span class="nt"><separator></span>
<span class="nt"><wan></wan></span>
<span class="nt"><openvpn></openvpn></span>
<span class="nt"><wireguard></wireguard></span>
<span class="err"><</span>0test><span class="err"><</span>/0test>
<span class="nt"></separator></span>
</code></pre>
<p>The XML tag name can't start with a digit, so it is invalid XML. Whatever you have done with edits/renames probably only prolonged the issue until it happens to update the separators again.</p>
<pre>
: xmllint /conf/config.xml.bad
/conf/config.xml.bad:965: parser error : StartTag: invalid element name
<0test></0test>
^
/conf/config.xml.bad:965: parser error : expected '>'
<0test></0test>
^
/conf/config.xml.bad:965: parser error : Opening and ending tag mismatch: separator line 961 and unparseable
<0test></0test>
^
[...]
</pre>
<p>There may not be a good way around that other than preventing groups from starting with a digit. Seems like changing the way separators are handled may be too drastic to accommodate them, but that's not code I've worked with so I'll defer to others there.</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574662021-11-18T15:14:12ZJens Groh
<ul></ul><p>I'd agree that simply disallowing them to start and end with a digit would be easier. Even if that means that a great way of adding some sorting to groups would be unavailable then.</p>
<p>Sorry about not supplying enough data in the first place. Should have known better myself as that's what I always tell my customers, too. Not my best day it seems. No offence meant!</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=574742021-11-20T02:41:20ZViktor Gurov
<ul></ul><p>input validation improvements:<br /><a class="external" href="https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/468">https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/468</a></p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=575032021-11-22T08:20:51ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Pull Request Review</i></li><li><strong>Assignee</strong> set to <i>Viktor Gurov</i></li><li><strong>Target version</strong> set to <i>2.6.0</i></li><li><strong>Plus Target Version</strong> set to <i>22.01</i></li></ul> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=575112021-11-22T11:15:09ZViktor Gurov
<ul><li><strong>Status</strong> changed from <i>Pull Request Review</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Applied in changeset <a class="changeset" title="Interface Groups start digit input validation. Fixes #12529" href="https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/b58cb30a0881a221c9c5ff1eb5752ac0660271b9">b58cb30a0881a221c9c5ff1eb5752ac0660271b9</a>.</p> pfSense - Bug #12529: Interface group name starting with a digit creates invalid XML for rule separatorshttps://redmine.pfsense.org/issues/12529?journal_id=575142021-11-23T01:35:52ZDanilo Zrenjanin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>Tested against:<br /><pre>
2.6.0-DEVELOPMENT (amd64)
built on Tue Nov 23 06:23:34 UTC 2021
FreeBSD 12.3-PRERELEASE
</pre></p>
<p>The input validation works as expected. Ticket resolved.</p>