Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Maybe a bug with sync of descriptions of firewall rules

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    3 Posts 1 Posters 427 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pete.s.
      last edited by pete.s.

      I have two firewalls running in HA. Firewall rules are synced from the master to the backup but there are characters missing on the backup in the description of each rule.

      It seems like . > and non-english characters like åäö are not transmitted. There are probably others as well.

      Just a guess but maybe firewall rule descriptions aren't encoded/decoded in the xml files so some characters are stripped instead.

      Don't know if it's a bug or not and I don't know how to fix it but wanted to give a heads up at least. 🍻

      1 Reply Last reply Reply Quote 0
      • P
        pete.s.
        last edited by

        Seems like this thread might address the same issue:
        https://forum.netgate.com/topic/139331/illegal-characters-in-firewall-rule-descriptions/3

        However I wouldn't consider non-english characters being illegal as they are allowed to use in the descriptions.

        1 Reply Last reply Reply Quote 0
        • P
          pete.s.
          last edited by pete.s.

          OK, I found the problem.

          https://github.com/pfsense/pfsense/blob/master/src/etc/rc.filter_synchronize

          A bunch of these lines:

          $config_copy['nat']['outbound']['rule'][$x]['descr'] = remove_special_characters($config_copy['nat']['outbound']['rule'][$x]['descr']);
          

          The function remove_special_characters strips out everything but a-z, A-Z, 0-9 _ - +

          Should have maybe used the function htmlspecialchars instead to get special characters encoded instead of stripping them. Also having the xml in UTF-8 allows you to put a lot of international characters in the xml file.

          Anyway, it's looks like it's been working like this for years.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.