Firewall: Do I need to allow inbound traffic to the RTP portrange for NAT-detection to work?

[Benoit Panizzon]

Hi

Our default ufw settings are restrictive. Unneeded ports are blocked.

From my understanding, rtpengine should manage the firewall rules needed for rtp traffic to get through.

In a nat situation, a client advertises a wrong ip via SDP.

From my understanding rtpengine would allow trafffic from 'any' to the port it has advertised to that client, to 'learn' the source ip.

But from testing, this is not what seems to be happening. I only get nat detection to behave correctly, if I explicitly allow connections from 'any' to the portrange used by rtpengine with ufw.

Did I maybe miss something?

-Benoît-

[Richard Fuchs]

Are you talking about the firewall rule management done via the `iptables-chain` option?

I don't think there are any restrictions set on the source addresses. But you can pull up the firewall rules that are being created during runtime to verify.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/3b3bfb82-f316-46df-b0d5-bc7097509e0dn%40googlegroups.com.

[Benoit Panizzon]

I guess so. I somehow expected rtpengine to create input rules on the fly for the specific ports advertised via SDP.

Am I right, this is not the case?

I see:

table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy drop;
                ip protocol udp counter packets 94648 bytes 27896633 jump rtpengine

But then, created by UFW

        chain ufw-before-input { counter packets 30 bytes 1320 jump ufw-logging-deny
                iifname "lo" counter packets 43594 bytes 1023976921 accept
                ct state related,established counter packets 90236 bytes 34466871 acceptes 0 accept
                ct state invalid counter packets 30 bytes 1320 jump ufw-logging-denyccept
                ct state invalid counter packets 30 bytes 1320 dropr packets 0 bytes 0 accept

So I guess if traffic originates from a unknown IP as happens in NAT situation, this 'before input' is dropping them with state invalid, preventing rtpengine from learning the correct source.

I added an accept rule towards the port range used by rtpengine and now NAT detection works as expected.

[Richard Fuchs]

On 28/05/2024 10.25, Benoit Panizzon wrote:
> I guess so. I somehow expected rtpengine to create input rules on the
> fly for the specific ports advertised via SDP.
> Am I right, this is not the case?

No it doesn't do that. Firewall rule management must be enabled
explicitly, and then only local (destination) ports and addresses are
relevant.

Cheers