Issue with SIP NAT passthrough disabled

[davros1999]

Hi

I upgraded to 380.57 and I notice a change in behaviour which I don't think is correct.

Disabling SIP Passthrough in WAN > NAT Passthrough causes an iptables rule to be added to the FORWARD chain which blocks UDP SIP:

Chain FORWARD (policy DROP)
target prot opt source destination
DROP udp -- anywhere anywhere udp dpt:5060

I think that passthrough off should only disable the SIP ALG. It should not result in blocking of SIP on UDP 5060. That was the behaviour in previous builds.

Thanks
Dave

 

[RMerlin]

The problem is that the passthrough option should, as its name implies, only control whether that type of traffic should be allowed in or not. Unfortunately, that option also controls whether the router loads the NAT helpers or not. In GPL 858, Asus fixed what was actually a bug - the SIP passthrough setting wasn't dropping port 5060 traffic when disabled, as it should (all other passthrough settings do so).

In fixing this, this created a new issue, where people now can only have passthrough + NAT helper, or no SIP traffic at all.

For the short term, 380.58 will revert to the original (broken) behaviour of allowing port 5060 traffic regardless of the state of that setting. Eventually, I'm considering splitting the passthrough and NAT helpers into separate settings, so they can work as expected: passthrough only controlling whether or not to allow a certain type of traffic, and NAT helper controlling whether or not to load the NAT helper.

In the mean time, users should enable the SIP passthrough whenever using a SIP client/ATA on their LAN.

 

[davros1999]

That all makes sense. Thanks for the reply. It would be useful to have a separate control to disable NAT helper. I haven't used it in a while but there are definite problems with ASUS' SIP implementation.

Thanks
Dave

 

[Authority]

The problem is that the passthrough option should, as its name implies, only control whether that type of traffic should be allowed in or not. Unfortunately, that option also controls whether the router loads the NAT helpers or not. In GPL 858, Asus fixed what was actually a bug - the SIP passthrough setting wasn't dropping port 5060 traffic when disabled, as it should (all other passthrough settings do so).

In fixing this, this created a new issue, where people now can only have passthrough + NAT helper, or no SIP traffic at all.

For the short term, 380.58 will revert to the original (broken) behaviour of allowing port 5060 traffic regardless of the state of that setting. Eventually, I'm considering splitting the passthrough and NAT helpers into separate settings, so they can work as expected: passthrough only controlling whether or not to allow a certain type of traffic, and NAT helper controlling whether or not to load the NAT helper.

In the mean time, users should enable the SIP passthrough whenever using a SIP client/ATA on their LAN.

I'm so confused. So to have ALG off do I set it to "disable" or "enabled" (without "helpers")?

 

[RMerlin]

I'm so confused. So to have ALG off do I set it to "disable" or "enabled" (without "helpers")?

That's because you are answering a very old post. Things have changed since 380.58.

Yes, "disabled" and "Enabled without helpers" means there won't be any ALG loaded.

 

[Authority]

That's because you are answering a very old post. Things have changed since 380.58.

Yes, "disabled" and "Enabled without helpers" means there won't be any ALG loaded.

Doesn't that mean that with "disabled" SIP Passthrough shouldn't work at all (it does)?

What am I missing?

 

[RMerlin]

Doesn't that mean that with "disabled" SIP Passthrough shouldn't work at all (it does)?

What am I missing?

Some of the NAT passthrough settings in Asus's original code will actively block traffic on that protocol's port. That's the case for instance with the PPTP passthrough. However for some unknown reason, that's not the case for SIP, so Disabled and Enabled are the same - only with NAT Helper does it behave differently (loading the Netfilter module).

 

[Authority]

Some of the NAT passthrough settings in Asus's original code will actively block traffic on that protocol's port. That's the case for instance with the PPTP passthrough. However for some unknown reason, that's not the case for SIP, so Disabled and Enabled are the same - only with NAT Helper does it behave differently (loading the Netfilter module).

...and the "netfilter" module is the ALG? Got it.

This was in fact the part that I didn't understand, that "enabled" and "disabled" are the same. May I suggest you edit the NAT-Helper text to say ALG? Thanks!

 

[HypnoDog]

Is it possible to get SIP phones, Cisco IP Phone in my case, without need to disable NAT Acceleration? I'm on 1Gbps WAN connection and disabling NAT Acceleration effectively reduces the bandwidth to 200Mbps. But it seems the only way that allow Cisco IP phone to connect to the server.

 

[NautiqueSkiBum]

Some of the NAT passthrough settings in Asus's original code will actively block traffic on that protocol's port. That's the case for instance with the PPTP passthrough. However for some unknown reason, that's not the case for SIP, so Disabled and Enabled are the same - only with NAT Helper does it behave differently (loading the Netfilter module).

Hi Merlin, I have no other options and going on 36 hours no sleep.

I have an ASUS RT-AC68U and did a firmware upgrade to the 3.0.0.4.380.4164 (the 12/23/2016 I presume since it was through the interface)

Now I'm unable to receive calls on my ip phone that plugs in router.

I have done gone all the way through tech support with Star2Star and reset the phone.

I have spoken to to two people at ASUS tech support (weary of this) and mentioned this post. They have no clue what it is referring to.

I've stepped back the firmware 2x with no success to versions;
3.0.0.4.380.3831 and
3.0.0.4.380.3264

- Called BHN/Spectrum To see if any changes in modem which is in bridge mode and they do not block anything.
- I have verified firewall is off
- Tried different combinations/settings on WAN =>>Nat Passthrough and rebooted each time (dozens if not a 100+)

I have looked all over for ALG and NAT Helper as well as netfilter. Only reference to filter I can find is on the firewall section and the additional Tabs.

For almost two years this has worked great. Now I have not been able to work for two days and that is a big problem if it happens again on Monday.

Can you help? Any suggestions? I'll be checking this page till I finally collapse for a reply. I can pay or send you a Starbucks gift.

 

[RMerlin]

Can you help? Any suggestions?

Switch to my firmware, I allow the router to be configured without the NAT helper, but without also blocking port 5060.

 

[StephenB-uk]

Switch to my firmware, I allow the router to be configured without the NAT helper, but without also blocking port 5060.

I'm using your firmware, but still having problems with sipgate.co.uk on an ASUS RT-AC68 running your version 380.65

I've tried SIP Passthrough in all three settings. What am I missing here?

 

[TOD]

I've tried SIP Passthrough in all three settings. What am I missing here?

SIP much more complex then switching one toggle.
Without diagnostics network level and knowledge of SIP(and sometimes the specifics of hardware/software SIP implementations), it's like a play with blackbox.
You should switch "SIP Passthrough" to Enable(without NAT Helper) and contact the technical support of your ITSP, so that they had a diagnosis according to examples of your attempts to register/make calls. Perhaps they will be able tell you how to configure the IP-phone/softphone.

 

[MDB_Knox]

Something is broken in 380.65 with regards to SIP Passthrough. Specifically, for whatever reason, SIP INIT's are not getting passed back downstream (i.e. outbound calls work, but no notification of inbound calls ever gets received). I'm using a dedicated SIP Trunk tied to a FreePBX Asterisk server. With 380.62_1 everything works perfectly. SIP and RTSP Passthrough are set to Enable (no NAT Helper -- it almost invariably fubars the audio stream in at least on direction [and always has, and also does it in Tomato as well]).

Try downgrading back to an earlier version of Merlin and see if your issues get better.

 

[bluechris]

Something is broken in 380.65 with regards to SIP Passthrough. Specifically, for whatever reason, SIP INIT's are not getting passed back downstream (i.e. outbound calls work, but no notification of inbound calls ever gets received). I'm using a dedicated SIP Trunk tied to a FreePBX Asterisk server. With 380.62_1 everything works perfectly. SIP and RTSP Passthrough are set to Enable (no NAT Helper -- it almost invariably fubars the audio stream in at least on direction [and always has, and also does it in Tomato as well]).

Try downgrading back to an earlier version of Merlin and see if your issues get better.

My 1st post here and i registered simple to say thx to MDB_Knox for his suggestion.
I had a R7000 with 360.65 and 2 days i wasnt able to connect to my Freepbx server with my Voip phones no matter what i did in NAT Passthrough so his suggestion to rollback to 380.62_1 worked for me fine.

Really thx for this and i hope the problem will be fixed in latest editions. Atm i have the sip nat helper to enable and is working fine.

Also Merlin thx for your great work m8... long time DDwrt user but now i switched to asuswrt of yours and i really like it.

 

[bluechris]

Something is broken in 380.65 with regards to SIP Passthrough. Specifically, for whatever reason, SIP INIT's are not getting passed back downstream (i.e. outbound calls work, but no notification of inbound calls ever gets received). I'm using a dedicated SIP Trunk tied to a FreePBX Asterisk server. With 380.62_1 everything works perfectly. SIP and RTSP Passthrough are set to Enable (no NAT Helper -- it almost invariably fubars the audio stream in at least on direction [and always has, and also does it in Tomato as well]).

Try downgrading back to an earlier version of Merlin and see if your issues get better.

Switch to my firmware, I allow the router to be configured without the NAT helper, but without also blocking port 5060.

M8 at start thx for your work.

You found why its broken in 380.65 but works ok in 380.62_1?

Sent using tapatalk

 

[RMerlin]

You found why its broken in 380.65 but works ok in 380.62_1?

No idea, my own ATA is working fine.