firewall-config (firewalld GUI) fails to generate correct service/helper XML-files

English Network/Internet
1

Tumbleweed 20190708 x86_64
firewall-config 0.6.3
Linux xxx 5.1.16-1-default #1 SMP Wed Jul 3 12:37:47 UTC 2019 (2af8a22) x86_64 x86_64 x86_64 GNU/Linux

Because my openVPN configuration kills off my SIP softphone I need to reconfigure my local firewall.
For this I decided to mark all packets pertaining to the SIP service and route them with a rule through an alternative routing table.
However, I need to configure my local softphone to work on port 5160 instead of 5060.
Hence, I set off with firewall-config 0.6.3 in permanent mode and

  1. created a new helper “sip-5160”, port 5160/udp, port 5160/tcp, module “nf_conntrack_sip”
  2. created a new service “sip-5160”, port 5160/udp, port 5160/tcp, modules “sip-5160”
  3. included service “sip-5160” in my device’s “zone”.
  4. rcfirewalld restart

Alas, iptables-save|less did no render the expected result.

After some digging I realized, that the GUI did not generate the respective XML-files correctly:

This is the sip.xml from /usr/lib/firewalld/services/sip.xml:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SIP</short>
  <description>The Session Initiation Protocol (SIP) is a communications protocol for signaling and controlling multimedia communication sessions. 
The most common applications of SIP are in Internet telephony for voice and video calls, as well as instant messaging, over Internet Protocol (IP) 
networks.</description>
  <port protocol="tcp" port="5060"/>
  <port protocol="udp" port="5060"/>
  <module name="nf_conntrack_sip"/>
</service>

This is the sip-5160.xml file from /etc/firewalld/services I generated with the GUI’s help:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SIP</short>
  <description>The Session Initiation Protocol (SIP) is a communications protocol for signaling and controlling multimedia communication sessions. 
The most common applications of SIP are in Internet telephony for voice and video calls, as well as instant messaging, over Internet Protocol (IP) 
networks.  like SIP but for port 5160 (the sipgate port)</description>
  <port port="5160" protocol="tcp"/>
  <port port="5160" protocol="udp"/>
  <module name="sip-5160"/>
</service>

Obviously, in the last line it says “nf_conntrack_sip” in the “original”, and “sip-5160” in the GUI-generated service.

With module name=“sip-5160” the iptables-entries are not generated.
Even if I manually change the XML-file to contain the nf_conntrack_sip entry the corresponding iptables commands are not issued, apparently the logic seeks the first “helper” being connected to the module and applies its port settings.
That means the connection between services and modules/helpers in the XML logic is broken! Beware! Not even manually generating the correct XML-files would help!

This is an excerpt from the correctly generated iptables list:

*raw
...
-A PREROUTING_ZONES -i enp3s0 -g PRE_internal
-A PREROUTING_ZONES -g PRE_public
-A PRE_internal -j PRE_internal_log
-A PRE_internal -j PRE_internal_deny
-A PRE_internal -j PRE_internal_allow
-A PRE_internal_allow -p tcp -m tcp --dport 5160 -j CT --helper sip
-A PRE_internal_allow -p udp -m udp --dport 5160 -j CT --helper sip
...
*filter
...
-A IN_internal_allow -p tcp -m tcp --dport 5160 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_internal_allow -p udp -m udp --dport 5160 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
...

This result I could only accomplish by changing the port settings of the original entry in the GUI.

Is this a known bug? Am I missing something here?

2

I suspect you may be over-thinking your approach.

Looks like you’ve tried a few ways to add a new custom sip service different ways, and each way you tried looks correct, should work.

The remaining possible cause for your problem may be as you describe… The original sip service is interfering with your new service with your custom settings (although I can’t think of a reason why that should be a problem).

So,
To my eye you haven’t tried the remaining try which should work…
Instead of adding a new, second custom service that would run concurrently with the original service,

Just modify the original service (and restart).
Instead of multiple concurrent services, you’ll only be running the one service.

Of course this assumes that you don’t need sip service support on multiple ports…
But even if you required multiple ports, then I’d look at specifying multiple ports in the single sip service… Instead of running separate services for each port which appears to be what you’re trying to do.

Good Luck,
TSU

3

Thanks for taking the time to read and think about my issues.

Actually I managed to set the firewall up as I needed.

The point I was trying to make is that the firewall script does not properly work. The XML-files are not generated as they are supposed to.

While I enjoy a good GUI tool for setting up my system I loathe doing research behind the GUI-scenes to find why it fails to accomplish what it promised to deliver!

Regards

4

Then you should have contacted firewalld developers, not post rant in random forum.

The XML-files are not generated as they are supposed to.

The XML files are exactly as they are supposed to be. It just that you misinterpret them and their usage in firewalld.

While I enjoy a good GUI tool for setting up my system I loathe doing research behind the GUI-scenes to find why it fails to accomplish what it promised to deliver!

Actually it delivers exactly what it promises. If you expect something else, you should discuss it with developers. This includes better documentation how helpers work in firewalld.

P.S. did not it occur to you that describing your solution would be useful to future users? You came here expecting help, it would be prudent to offer something in return.