11:16 a.m.
I see in upcoming versions, firewalld.policy is to replace the functionality of
iptables and firewalld.direct.
Browsing through the documentation, I can't see how I would replace the following
with policies as I can't find how to have a custom (module provided) TARGET.
The following supports the Sipwise NGCP RTPengine iptables kernel module:
https://github.com/sipwise/rtpengine
# direct.xml
<?xml version="1.0" encoding="utf-8"?>
<direct>
<!-- RTPengine managed iptables chain and kernel module forwarding-->
<chain ipv="ipv4" table="filter"
chain="RTPENGINE_allow"/>
<chain ipv="ipv6" table="filter"
chain="RTPENGINE_allow"/>
<passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE_allow</passthrough>
<passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE --id 0</passthrough>
<passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE_allow</passthrough>
<passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE --id 0</passthrough>
</direct>
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
8:19 a.m.
On Sat, Feb 27, 2021 at 11:16:04AM -0600, Anthony Joseph Messina wrote:
I see in upcoming versions, firewalld.policy is to replace the
functionality of
iptables and firewalld.direct.
For 90% of use cases I think they can replace direct rules.
Browsing through the documentation, I can't see how I would
replace the following
with policies as I can't find how to have a custom (module provided) TARGET.
The following supports the Sipwise NGCP RTPengine iptables kernel module:
https://github.com/sipwise/rtpengine
# direct.xml
<?xml version="1.0" encoding="utf-8"?>
<direct>
<!-- RTPengine managed iptables chain and kernel module forwarding-->
<chain ipv="ipv4" table="filter"
chain="RTPENGINE_allow"/>
<chain ipv="ipv6" table="filter"
chain="RTPENGINE_allow"/>
<passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE_allow</passthrough>
<passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE --id 0</passthrough>
<passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE_allow</passthrough>
<passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000 -j
RTPENGINE --id 0</passthrough>
</direct>
There is no way to jump to an iptables chain without using direct rules.
Policies don't allow jumping.
10:48 a.m.
On Monday, March 1, 2021 8:19:30 AM CST Eric Garver wrote:
On Sat, Feb 27, 2021 at 11:16:04AM -0600, Anthony Joseph Messina
wrote:
> I see in upcoming versions, firewalld.policy is to replace the
> functionality of iptables and firewalld.direct.
For 90% of use cases I think they can replace direct rules.
Ok thank you. So direct rule functionality will continue to be available,
with recommendations to use policies where appropriate?
> Browsing through the documentation, I can't see how I would
replace the
> following with policies as I can't find how to have a custom (module
> provided) TARGET.
>
> The following supports the Sipwise NGCP RTPengine iptables kernel module:
> https://github.com/sipwise/rtpengine
>
> # direct.xml
> <?xml version="1.0" encoding="utf-8"?>
> <direct>
>
> <!-- RTPengine managed iptables chain and kernel module forwarding-->
> <chain ipv="ipv4" table="filter"
chain="RTPENGINE_allow"/>
> <chain ipv="ipv6" table="filter"
chain="RTPENGINE_allow"/>
> <passthrough ipv="ipv4">-I INPUT -p udp -m udp --dport 30000:40000
-j
> RTPENGINE_allow</passthrough> <passthrough ipv="ipv4">-I
INPUT -p udp
> -m udp --dport 30000:40000 -j RTPENGINE --id 0</passthrough>
> <passthrough ipv="ipv6">-I INPUT -p udp -m udp --dport 30000:40000
-j
> RTPENGINE_allow</passthrough> <passthrough ipv="ipv6">-I
INPUT -p udp
> -m udp --dport 30000:40000 -j RTPENGINE --id 0</passthrough>>
> </direct>
There is no way to jump to an iptables chain without using direct rules.
Policies don't allow jumping.
Thank you for this clarification.
11:30 a.m.
On Mon, Mar 01, 2021 at 10:48:03AM -0600, Anthony Joseph Messina wrote:
On Monday, March 1, 2021 8:19:30 AM CST Eric Garver wrote:
> On Sat, Feb 27, 2021 at 11:16:04AM -0600, Anthony Joseph Messina wrote:
> > I see in upcoming versions, firewalld.policy is to replace the
> > functionality of iptables and firewalld.direct.
>
> For 90% of use cases I think they can replace direct rules.
Ok thank you. So direct rule functionality will continue to be available,
with recommendations to use policies where appropriate?
direct rules are deprecated as of the un-released v1.0.0, but they'll
still be around for a long time (years). They'll eventually be dropped,
presumably in v2.0.0.
Since policy objects are available I'm hoping projects start using them
to have full integration instead of using iptables and partial firewalld
integration.
6:10 p.m.
On Monday, March 1, 2021 11:30:03 AM CST Eric Garver wrote:
On Mon, Mar 01, 2021 at 10:48:03AM -0600, Anthony Joseph Messina
wrote:
> On Monday, March 1, 2021 8:19:30 AM CST Eric Garver wrote:
> > On Sat, Feb 27, 2021 at 11:16:04AM -0600, Anthony Joseph Messina wrote:
> > > I see in upcoming versions, firewalld.policy is to replace the
> > > functionality of iptables and firewalld.direct.
> >
> > For 90% of use cases I think they can replace direct rules.
>
> Ok thank you. So direct rule functionality will continue to be available,
> with recommendations to use policies where appropriate?
direct rules are deprecated as of the un-released v1.0.0, but they'll
still be around for a long time (years). They'll eventually be dropped,
presumably in v2.0.0.
Since policy objects are available I'm hoping projects start using them
to have full integration instead of using iptables and partial firewalld
integration.
I think in cases like this one, where the project implements an out-of-tree
kernel module that creates a custom RTPENGINE iptables target and uses
iptables rules to route traffic in to and out of the module, there currently
isn't a way to use firewalld directly.
I've put up a simple issue https://github.com/sipwise/rtpengine/issues/984 but
externally others have been talking about eBPF, rather than nftables.
Either way, I'm glad to hear firewalld.direct wont be leaving quite yet.
Thank you for your quick responses!
1151
days inactive
1154
days old
firewalld-users@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
Anthony Joseph Messina -
Eric Garver