Problems With Natted Phones

Home » Asterisk Users » Problems With Natted Phones
Asterisk Users 54 Comments

Hello,

I have an asterisk setup using pjsip. Everything used to work correctly until one remote site changed internet provider and thier router does not support sip protocol algorithms.

It works for some time, but then suddenly audio stops working both directions. When this happens I see RTP responses going out to the local address of the natted phone, not to the natted address. The problem appears for the phones independently.

The asterisk is connected to the internet with public static IP address.

The pjsip config contains:

[aor]
type=aor qualify_frequency = 60
max_contacts=1
remove_existing = yes

[endpoint]
type = endpoint context = internal dtmf_mode = rfc4733
disallow = all allow = alaw allow = ilbc allow = g729
allow = gsm allow = g723
direct_media = no allow_subscribe = yes subscribe_context = blf rewrite_contact = yes rtp_symmetric = yes force_rport = yes

Am I missing something? Why the communication breaks suddenly?

Thanks

Marek

—

54 thoughts on - Problems With Natted Phones

  • Have you tried to see if the router has any SIP ALG enabled this might create such issues, Thanks.

    Best Regards,

  • Hello,

    yes SIP ALG are anbled on the router. Should I disable?

    Transport config looks like that:

    [transport-udp]
    type = transport protocol = udp bind = 0.0.0.0
    domain = mydomain.com

    Asterisk itself is not natted.

    Marek

    2021-07-08 21:14 GMT+02:00, Michael L. Young :
    —

  • In my opinion, always.

    Antony.

    —
    I don’t know, maybe if we all waited then cosmic rays would write all our software for us. Of course it might take a while.

    – Ron Minnich, Los Alamos National Laboratory

    Please reply to the list;
    please *don’t* CC me.

    —

  • Hello,

    I just disabled. Currently it is working. I shloud give it some time to confirm the problem has gone. Maybe one month would be enough to confirm.

    Thanks

    Marek

    2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
    —

  • Hello,

    your suggestion to turn off SIP ALG on provider’s router was probably correct. no problem until now. Thank you very much.

    I just found out another issue. I had a pjsue client in that network which called specific number when turned on. It was working perfectly with the old provider with working SIP ALG. But now with this provider and SIP ALG disabled I am not able to make the call using pjsua client.

    My pjsua config looks like this:
    –id sip:ext@asterisk.domain
    –registrar sip:asterisk.domain
    –proxy sip:asterisk.domain
    –outbound sip:asterisk.domain
    –realm *
    –username username
    –password password
    –null-audio
    –no-tcp
    –max-calls=1
    –no-vad

    The pjsua client successfully registers but is unable to call.

    I see the following:
    IP address change detected for account 1
    (localip:5060–>nattedip:newport). Updating registration (using method
    4)
    Temporary failure in sending Request msg INVITE/cseq=…., will try next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)

    What could be the problem? How can I convince pjsue to work correctly behind nat?

    Thanks

    Marek

    2021-07-10 11:08 GMT+02:00, Marek Greško :

    —

  • I achieved a partial success adding –use-compact-form option.

    Marek

    2021-07-23 13:47 GMT+02:00, Marek Greško :
    —

  • Hmm, back to original problem. My happines was premature. Today one of the phones have no audio again. I see packets from lan segment again.

    I double checked the router configuration. SIP ALG is disabled. There are also another ALGs present:

    NAT ALG
    RTSP ALG
    PPTP ALG
    IPSEC ALG

    Which of them are neede to be disabled?

    As of my observations these problems are triggered by reboots on asterisk side. How could this be related? (I may be wrong.)

    Thanks

    Marek

    2021-07-23 14:54 GMT+02:00, Marek Greško :

    —

  • I currently disabled also RTSP ALG and rebooted the router. Fixed for now. I do not know for how long.

    Marek

    2021-07-26 8:54 GMT+02:00, Marek Greško :
    —

  • Hello,

    it triggered again. Even disabling RTSp ALG did not help. My fantasy ends here. It agains seems to be reboot triggered on asterisk side. Not every one. But there was surely one before it was last working. Reboot of the router on the phone side fixes the problem. Any other suggestions?

    Thanks

    Marek

    2021-07-26 9:31 GMT+02:00, Marek Greško :

    —

  • happening on the asterisk box. sngrep is focussed on sip dialogs and is probably easier than tcpdump when you are just interested in sip

    If you use sngrep on the asterisk server sip port you will see the SIP
    packet flows for registration and call setups. You can check the addresses given out for rtp to respond to and the codecs. Is an address incorrect? Is a code incorrect? You will see in the session description protocol what codecs the client is requesting and what the replies are

    asterisk works well around the world with many nat scenarios so I
    imagine its either config or firewall. A firewall with ALGs is often problematic but your log suggests a lack of negotiation of agreed codecs.

    Good luck, you will learn some interesting things.

    —

  • Hello,

    I looked into tcpdumps. When problem starts (after some asterisk reboot) the call looks like this:

    provider:25298 -> asterisk:5060
    SIP: SIP/2.0 200 OK
    Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=… From: ;tag=… To: ;tag=… Call-ID: … CSeq: … INVITE
    Contact:
    Supported: replaces Allow-Events: message-sumary, refer, ua-profile, talk, check-sync Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
    Content-Type: application/sdp Content-Length: …

    v=0
    o=… 5010 … IN IP4 lan s=Mapping c=IN IP4 lan t=0 0
    m=audio 5010 RTP/AVP 8 101
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=sendrcv a=ptime:20

    asterisk:5060 -> provider:25298
    Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=… From: ;tag=… To: ;tag=… Call-ID: … CSeq: … ACK
    Max-Forwards: 70
    User-Agent: Asterisk PBX 18.2.0
    Content-Length: 0

    Then I see RTP packets:
    asterisk:18892 -> lan:5010
    provider:25420 -> asterisk:18892

    I hear no audio. I heard stream towards the asterisk prior to SIP ALG
    disabling. Now silence both directions. It should not be a codec problem. After providers router reboot I can hear both directions but it still seems weird:

    provider:32260 -> asterisk:5060
    SIP: SIP/2.0 200 OK
    Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=… From: ;tag=… To: ;tag=… Call-ID: … CSeq: … INVITE
    Contact:
    Supported: replaces Allow-Events: message-sumary, refer, ua-profile, talk, check-sync Allow: INVITE, ACK, CANCEL, BYE, OPTIONS. INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
    Content-Type: application/sdp Content-Length: …

    v=0
    o=… 5016 … IN IP4 lan s=Mapping c=IN IP4 lan t=0 0
    m=audio 5016 RTP/AVP 8 101
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=sendrcv a=ptime:20

    asterisk:5060 -> provider:32260
    Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=… From: ;tag=… To: ;tag=… Call-ID: … CSeq: … ACK
    Max-Forwards: 70
    User-Agent: Asterisk PBX 18.2.0
    Content-Length: 0

    Then I see several RTP packets:
    asterisk:13786 -> lan:5016
    provider:32327 -> asterisk:13786
    for a while and the suddenly asterisk:13786 -> provider:32327
    provider:32327 -> asterisk:13786

    The user experience for that scenario is OK.

    I suspect some configuration error on asterisk side, since also for working scenario I see RTP packets to the lan. But I cannot figure out what it is. When I was using another provider which had working SIP
    ALG I had no problem even without nat configuration on the asterisk side.

    The experience is clearly better after disabling SIP ALG, but we still face problems after asterisk side reboots.

    Could you point me for what should I look in the asterisk configuration? And why the problems are gone after provider’s router reboot?

    Thanks

    Marek

    2021-08-13 15:31 GMT+02:00, Duncan Turnbull :

    —

  • This bit here tells where the rtp has to go to. I don’t think you want it to be IP4 lan. It would be a lot more helpful if you had the ip address but the use of the word LAN suggests its a private IP which asterisk is not going to be able to route to

    As above for RTP to work they have to go to/from the end points. Asterisk is sending to 18892 instead of the provider 25420

    Why is your provider sending you an sdp with rtp with a private ip address?
    Or are they sending the right address and your ALG or something else is changing it? Ask your provider what they are sending you? Then find out who/what is messing up the SDP

  • So you suspect something is messing up SIP protocol? Maybe the phone itself is not working properly. The phone itself is not aware of the internet address, so is sending lan private address in the sip protocol. I would expect asterisk itself is pairing the provider address with the lan address. I was asked to disable all the SIP ALG
    on the provider’s router in the previous discussion. And it made a big improvement in the experience.

    Marek

    2021-09-03 12:19 GMT+02:00, Duncan Turnbull :
    —

  • I doubt it’s the phone. You need to check your data again and ideally explain what you mean by the names you have substituted for the ip addresses

    C = is telling the asterisk what ip to send rtp to. So if ip4 lan is a valid external address then that’s ok but if not your provider is sending you an IP address that asterisk doesn’t know how to connect to and therefore rtp will go nowhere leaving you with no sound

    —

  • My advice (regarding the IP addresses) is:

    – where you have https://tools.ietf.org/html/rfc1918 addresses, leave them as they are – you’re not giving away any sensitive information by telling us about your internal addresses which can’t be routed over the Internet

    – where you have public addresses and would prefer not to reveal what these are, substitute with https://tools.ietf.org/html/rfc5737 addresses instead.

    – always ensure that you substitute address A in the same way each time, and address B, etc.

    Antony.

    —
    You can spend the whole of your life trying to be popular, but at the end of the day the size of the crowd at your funeral will be largely dictated by the weather.

    – Frank Skinner

    Please reply to the list;
    please *don’t* CC me.

    —

  • Ok,

    let substitute lan for 192.168.100.235, provider with 192.0.2.1 and asterisk with 198.51.100.1.

    In the working scenario understand that asterisk is not aware of the providers ip address 192.0.2.1 in the sip protocol, and it should pick it from the network layer. It is harder to calcutale port, so it should probably listen for incoming rtp stream? Until then it is just sending to private address? But I thing it is futile, since it is known from the sip protocol there is nat involved and thus the packets are destined to nowhere.

    But I still cannot imagine what goes wrong in non working scenario and how the asterisk reboot (not every one and not sure this is the real trigger). The sip communication seems identical to me. The provider’s router does not touch SIP now as observed after disabling SIP ALG.

    Thanks

    Marek

    2021-09-04 0:40 GMT+02:00, Antony Stone :

    —

  • Can you provide the previous packet details with these addresses filled in If the call goes provider – asterisk – phone then asterisk is absolutely aware of the provider ip. I think you need to get more familiar with sip and rtp

    The sdp in the sip packet tells the rtp ip and port to connect to

    You need to realise that this works normally everyday all over the place so what you are imagining is incorrect

    It is very unclear as to how you are justifying these statements. You don’t yet understand how sip and call setup with media works. If you provide the whole sip packet capture with the substituted ips it should be easier to point out where the error is

    You need to be really clear on what’s ip is what and where the conversations are captured

    It will become clear once you provide all the details

    —

  • Hello,

    I agree my knowledge of SIP itself is poor, but I have quite well general tcp/ip understanding. What sip parameters should be anonymized? How about tag, branch, call-id, cseq values?

    Thanks

    Marek

    2021-09-04 12:36 GMT+02:00, Duncan Turnbull :

    —

  • Hi Marek

    The way it works is that the sip message will carry the sdp and in that will be the instructions for where to route the rtp

    If systems don’t know their external address or are misconfigured they send an internal address that is not reachable from the far end. This is where lack of audio issues occur

    The main thing to show are the sip to/from addresses, anonymised but consistent, and the sdp data particularly the c and the media attributes

    Here is some background

    https://support.yeastar.com/hc/en-us/articles/360009806434-Brief-Introduction-of-SIP-and-SDP-Protocol-?mobile_site=true

    If the c attribute has an address that is not routeable from the device that received it then you won’t get any audio

    It’s confusing at this stage but once you get a little more familiar it will start to make a lot of sense

  • Show us your packet captures with meaningful addresses (not necessarily accurate ones, but at least unambiguous – see my previous suggestion re RFC5737) and we can help you to understand them and what they mean.

    Antony.

    —
    Heisenberg, Gödel, and Chomsky walk in to a bar. Heisenberg says, “Clearly this is a joke, but how can we work out if it’s funny or not?”
    Gödel replies, “We can’t know that because we’re inside the joke.”
    Chomsky says, “Of course it’s funny. You’re just saying it wrong.”

    Please reply to the list;
    please *don’t* CC me.

    —

  • Hello,

    could you please answer my previous question about anonymizing several parameters? I have the data ready, but will post after answer. I have no clue whether I could disclose some important data not deleting them.

    Regarding sdp, the address will be the internal one, since the phone is behind nat and it is not aware of the nat. The provider’s nat device is configured as dump nat, no application tweaking is done. So the asterisk will see the lan address in the sip.

    In the working scenario it is sending rtp packets to the internal address which is wrong, but after receiving cca 5 rtp packets from the phone it somehow discovers correct nat ip/port and switches to it. In non-working scenario it never switches and still sends to the lan address. Strange there is no audio, even one direction. Another strange thing is there are 2 phones (different vendors) behind the same nat and the problem appearance on them is independent, sometimes the first has problem, sometimes the second and sometimes both.

    The tcpdumps are made on the asterisk side. I have currently no means of capturing on phone side.

    Marek

    2021-09-04 23:56 GMT+02:00, Antony Stone :

    —

  • Nothing other than IP addresses (if you consider those to be sensitive) needs to be anonymised.

    I suspect that is in fact ideal.

    Antony.

    —
    I thought I had type A blood, but it turned out to be a typo.

    Please reply to the list;
    please *don’t* CC me.

    —

  • I’m slightly bothered by the word “algorithms” in that comment, but I do wonder whether it simply means that this is a connectivity provider (possibly a mobile phone network?) which actively blocks SIP.

    Some of them (in my experience) do this by blocking UDP port 5060, but others are more subtle about it, and (for example) block the authentication responses to a Register request, thereby meaning that UDP port 5060 is in general accessible, but any attempt to Register to it using SIP will fail.

    Have you asked the new Internet connectivity provider whether they support or block SIP across their network?

    Antony

    —
    “Remember: the S in IoT stands for Security.”

    – Jan-Piet Mens

    Please reply to the list;
    please *don’t* CC me.

    —

  • So, what do the two addresses which you have labelled in the packet captures as 198.51.100.1 and 192.0.2.2 correspond to?

    I see nothing at all in your packet captures which indicate IPv6.

    Please tell us which address means what:

    – which is the public address of the Asterisk server?

    – which is the public address of the telephone?

    (I’m assuming that the private address of the telephone is 192.168.100.235, please confirm).

    We really do need to understand enough about your network arrangement to be able to help here.

    Antony.

    —
    Your work is both good and original. Unfortunately the parts that are good aren’t original, and the parts that are original aren’t good.

    – Samuel Johnson

    Please reply to the list;
    please *don’t* CC me.

    —

  • There are two conversations to look at Provider to Asterisk Asterisk to Phone You need the packet captures of both.

    Your statements are mixing them up

    I don’t know what you mean by LAN address, that’s an ambiguous term. The ip your asterisk receives from the provider should be the providers external ip or in the sdp the external address of the media server which may or may not be the same device

    —

  • Hello,

    regarding the ipv6, you see nothing about that it should be some type of ipv6 tunnelling, because also MTU is lower than expected. You should not see any ipv6 related communication in the sniff. Phone is not aware of it.

    The asterisk’s static public ip address is 198.51.100.1. The remote provider’s dynamic nat pool is 192.0.2.0/24. By provider we mean internet provider the remote phones are behind. We are not complaining about voip provider, we have no problem with that. Only communication between asterisk and remote phones behind some internet provider. This is the only conversation to look at. The phone private address is 192.168.100.235.

    Thanks

    Marek

    2021-09-05 1:11 GMT+02:00, Duncan Turnbull :

    —

  • Hi Marek

    I didn’t understand your setup originally.

    Can you confirm this is correct:

    You provide asterisk for a number of remote phones. I assume they register to the asterisk

    Asterisk ( 198.51.100.1) <==> Phone Provider ( 192.0.2.0/24 ) <==> Phone (
    192.168.100.235 )

    Your call that fail is coming from asterisk to the phone offering G711A, G729, iLBC, GSM, G723 and rtp on port 18892

    Its unclear to me still whether the remote provider has a SIP device in front of the phones or just a firewall. The user agent for the reply is A540 which I am not familiar with

    The call that works shows the Asterisk sending to the internal ip until it receives rtp from the remote phone from which it learns its address and port and redirects the rtp to. This is fairly standard

    For the case of the call that doesn’t work, your asterisk receives the rtp with the external address but doesn’t learn from it.

    You haven’t provided the full call data including the close down of the call and the registrations would have been helpful too but no matter.

    The question is why your asterisk didn’t learn the external address and port from the received rtp packet

    You can look at your logs with debug to see what decisions its making. You can see if different rtp ports have different results. Your phone provider has rtp on 5010 unsuccessfully and 5016 successfully. Your asterisk uses rtp 13786 successfully and fails when using 18892. Is it possible your firewall is blocking port 18892 and so asterisk never sees the returned packet and can’t learn from it?

    In any event you should put your debug on and look at your logs in asterisk to see what it sees and why it doesn’t react to the rtp packet, if it gets it

    Have fun, its all good learning.

  • Hello,

    2021-09-06 2:51 GMT+02:00, Duncan Turnbull :

    Exactly correct.

    It is just a firewall. I disabled SIP ALG on it. The nat is performed probably somewhere in the provider’s network. I see only ipv6 tunnel to the provider’s netwrork.

    The second phone is Cisco SPA502G. Same problems.

    I would expect that when asterisk is aware of nat, it does not send the rtp until it receives rtp from other side to learn the port, but OK, no problem to accept the behavior.

    Yes exactly, but I do not undestand why. And why the reboot of the provider’s router helps to solve the problem for several days?

    It is very unprobable. I see no reason for blocking the port. The problem is asterisk never learns the correct port, so there is nothing to block.

    Could you point me how the debug should be conducted?

    Is my suspection that the problem could be caused by nat ip addres changing reasonable? How should asterisk handle the situation?

    Thanks

    Marek

    —

  • That’s not how things work. You should google how sip rtp and Nat work as it will help you Focus on problem, once you know what’s happening to rtp you will get the other answers It wasn’t what is probable, look at the asterisk logs and see what it’s actually doing. If asterisk never sees the reply then you will know something is blocking or stealing the port for some other service

    Using the asterisk cli turn on debug for the peer and rtp and see what happens. Match it with the asterisk processes. You have to do this, you can look at cli or the log files, follow it through to see the rtp packet being received. Lots of debug advice on google. I can’t see anything to support that. Everything is looking normal except asterisk doesn’t appear to beseeing the rtp packet

    —

  • Hello,

    no problem if it is intended.

    If it is stolen port for rtp, the next call would solve it, since it will use different one, and it does not solve it.

    Asterisk cli did not show anything interesting. I tried pjsip set logger verbose on, but no logs showed anywhere. What am I doing wrong?

    Marek

    —

  • Sorry rtp set debug on showed something. So let try for the problem to arise again.

    Marek

    2021-09-06 11:48 GMT+02:00, Marek Greško :
    —

  • Hello,

    so when debugging RTP in asterisk there was no rtp income from the remote site. I did check remote nat ip address and it was same as the one in the pjsip show aors. So it is not due to ip address change. It seems the local firewall sip module does not allow rtp stream to get into. It was working previously with the other provider because of working SIP ALG on their gateways. But now with this provider and disabled SIP ALG it is not allowed. As I remeber in the past these setups did work. What are your experiences on this?

    Thanks

    Marek

    2021-09-06 11:50 GMT+02:00, Marek Greško :

    —

  • You would need to provide a lot more explanation here. What is your firewall? I am assuming you configure it so find the configuration that’s blocking the ports and change it. My experience as before was that something is blocking rtp, now you know what that something is and it’s under your control so you need to check it’s configuration and fix it. I don’t use a sip firewall. If I have external sip clients I use a proxy.

    —

  • Hello,

    it is only local nftables with nf_conntrack_sip on the asterisk server. Probably a kernel bug? It did not trigger with previous providers since they had working SIP ALG. Now I hear no audio in both directions because outgoing rtp stream from asterisk goes to private address space and incoming stream is blocked. So the outgoing rtp could not be learnt to send to nat addess.

    Marek

    2021-09-06 22:17 GMT+02:00, Duncan Turnbull :

    —

  • Try temporarily simply turning the firewall off – allow all traffic through
    (although leave in place any NAT rules).

    If you then find that RTP works, you know where the problem lies.

    Antony.

    —
    Perfection in design is achieved not when there is nothing left to add, but rather when there is nothing left to take away.

    – Antoine de Saint-Exupery

    Please reply to the list;
    please *don’t* CC me.

    —

  • Hello,

    I confirm temporarily allowing all the udp communication from the nat ip address solved the problem, so the problem lies in the nftables. This is probably not the right forum to continue. Or is it? Does anybody have wide experience with nftables and sip?

    Thanks

    Marek

    2021-09-07 10:40 GMT+02:00, Antony Stone :

    —

  • If you publish your rule set then we could look. Did you write the rules? What have you checked so far?

    —

  • Hello,

    I did converted from iptables by automatical script and then rewritten myself, because not everything was rewritten successfully.

    Relevant parts:

    table ip filter {
    ct helper sip {
    type “sip” protocol udp
    l3proto ip
    }

    chain PREROUTING {
    type filter hook prerouting priority filter; policy accept;
    udp port 5060 ct helper set “sip”
    }

    chain INPUT {
    …
    ct state invalid drop
    ct state related accept
    ct state established accept
    …
    iifname “ppp0” jump i-inet
    }

    chain OUTPUT {
    type filter hook output priority filter; policy accept;
    udp port 5060 ct helper set “sip”
    …
    }

    chain i-inet {
    …
    udp port 5060 jump r-sip
    …
    }

    chain r-sip {
    ip saddr 192.0.2.0/24 accept
    }
    }

    table ip mangle {
    chain PREROUTING {
    type filter hook prerouting priority mangle; policy accept;
    …
    udp sport 5060 ip dscp set 0x04
    }

    chain OUTPUT {
    type route hook output priority mangle; policy accept;
    …
    udp dport 5060 ip dscp set 0x04
    …
    }
    }

    table ip6 filter {
    ct helper sip {
    type “sip” protocol udp
    l3proto ip6
    }

    … pretty the same, but I have no ipv6 internet connectivity, so this should not match …

    }

    Is there something incorrect?

    Thanks

    Marek

    2021-09-08 21:17 GMT+02:00, Duncan Turnbull :

    —

  • Where are the rules for rtp? This is an rtp problem. What ports are allowed for them? And what other udp rules exist that could be interfering On your asterisk what ports do you have assigned for rtp? What are the matching firewall rules?

    —

  • Hi. Our rules:

    Le 08/09/2021 à 22:43, Marek Greško a écrit :

    set world_udp.eth0 {
                    type inet_service
                    flags interval
                    elements = { iax, sip, sip-tls, 10000-30000 }
            }

    chain input {
                    type filter hook input priority 0; policy drop;
                    iif “eth0” ip daddr udp dport
    @world_udp.eth0 counter packets 15394440 bytes 3738156190 accept
                    ….

    As you see we take care on RTP port range defined in rtp,conf

    chain output {
                    type filter hook output priority 0; policy drop;
                    oif “eth0” ct state established,related,new counter packets 17542533 bytes 6033494909 accept

    our default policy is to drop so we add new in ct state

    Regards

    —
    Daniel

    —

  • Hello,

    I would not like to open whole range of udp ports for rtp. I use nf_conntrack_sip module for dynamically opening relevant ports. And there is probably some bug in it.

    Marek

    2021-09-08 23:12 GMT+02:00, Administrator :

    —

  • Why not? What is the risk?

    What would possibly be listening on UDP ports 10000 – 20000 (the Asterisk default range) which an external scanner / attacker could make use of?

    Antony.

    —
    Too many people spend money they haven’t earned to buy things they don’t want, to impress people they don’t like.

    – Will Rogers

    Please reply to the list;
    please *don’t* CC me.

    —

  • There is always some risk. If there is a solution that should work, it is best to use it. We just need the root cause, why it fails sometimes.

    Marek

    2021-09-09 18:01 GMT+02:00, Antony Stone :

    —

  • Le 09/09/2021 à 18:15, Marek Greško a écrit :

    Like SIP ALG ? 😉 Please explain which risk are existing if there is nothing listening on those ports ?

    —
    Daniel

    —

  • There are other systems running on the same hardware. It would just leave open ports here.

    Do not compare SIP ALG on a closed source device to an opensource software with active development. I had no such problems in the past when using iptables. The nftables is a pretty new software, so some bugs could be present and I accept. I just wanted to be sure I am not doing anything wrong. Now I am pretty sure it is a bug.

    Thanks

    Marek

    2021-09-09 18:30 GMT+02:00, Administrator :

    —

1 2