I’ve always had to do that to get our Obihai SIP ATA to work. I can see that that conntrack helper is loaded in the route10. Can I disable it? I’ve also just ordered a Grandstream ATA since the Obihai hasn’t been supported in a while. Should be able to disable those helpers though.
uci set firewall.@defaults[0].conntrack_sip='0'
uci commit firewall
/etc/init.d/firewall restart
May I strongly recommend that you make notes about any changes you make with /cfg/post-cfg.sh such as the above script, as well? These changes can create complications when diagnosing other issues, even if unrelated.
Also we may disable this by default in the future, as it seems to be more trouble than it’s worth in current year.
I second the disable by default. It seems to cause way more problems than it solves.
1 Like
Thanks. Either that or some firewall change I made fixed it. For post_cfg.sh I just have
#!/bin/sh
cd $(dirname $0)
for f in post-cfg.d/*.sh; do
. $f
done
and then stick patches in separate files under post-cfg.d.
I get this warning when attempting to run these commands:
Warning: Option @defaults[0].conntrack_sip is unknown`
I do see it added when running uci show, though. It doesn’t seem to make a difference, and evidence of SIP ALG still exists afterwards.
When I run this script by hand, the setting sticks until a config reload. However I have this script in post-cfg.sh and it is not running on its own. Can I get some help with this sir?
Is this perhaps indicative of a problem?
OpenWrt daemon.alert cfg: run “/cfg/post-cfg.sh”
Feb 14 18:37:34 OpenWrt daemon.alert cfg: Warn: /cfg/pos… rc: 32256
Try adding some debug statements. The warning you posted is truncated so there isn’t anything to figure from it yet.
We see that when we restart the firewall.
root@route10:~# uci show firewall.@defaults[0].conntrack_sip
firewall.cfg04e63d.conntrack_sip='0'
root@route10:~# /etc/init.d/firewall restart
Warning: Option @defaults[0].conntrack_sip is unknown
Warning: Section @zone[2] (vpn) cannot resolve device of network 'xfrm0'
Warning: Section @zone[2] (vpn) cannot resolve device of network 'wg'
Warning: Section @rule[10] (isolate guest) does not specify a protocol, assuming TCP+UDP
Warning: Section @rule[11] (isolate iot) does not specify a protocol, assuming TCP+UDP
Warning: Section @rule[14] (isolate firewalled) does not specify a protocol, assuming TCP+UDP
Warning: Section @redirect[1] (SSL) does not specify a destination, assuming 'lan'
Warning: Section @redirect[2] (Submission) does not specify a destination, assuming 'lan'
Warning: Section @redirect[3] (imapssl) does not specify a destination, assuming 'lan'
Warning: Section @redirect[4] (dcc) does not specify a destination, assuming 'lan'
Warning: Section @redirect[5] (snail2 ssh) does not specify a destination, assuming 'lan'
Warning: Section @redirect[7] (smtps) does not specify a destination, assuming 'lan'
* Flushing IPv4 filter table
* Flushing IPv4 nat table
* Flushing IPv4 mangle table
* Flushing IPv4 raw table
* Flushing IPv6 filter table
* Flushing IPv6 mangle table
* Flushing IPv6 raw table
* Flushing conntrack table ...
* Populating IPv4 filter table
* Rule 'Allow DHCP renewals'
* Rule 'Allow Ping'
* Rule 'Allow IGMP'
* Rule 'IPsec IKE'
* Rule 'IPsec NAT-T'
* Rule 'IPsec ESP'
* Rule 'isolate guest'
* Rule 'isolate iot'
* Rule 'firewalled dhcp'
* Rule 'firewalled ntp'
* Rule 'isolate firewalled'
* Redirect 'HTTP'
* Redirect 'SSL'
* Redirect 'Submission'
* Redirect 'imapssl'
* Redirect 'dcc'
* Redirect 'snail2 ssh'
* Redirect 'video'
* Redirect 'smtps'
* Forward 'lan' -> 'wan'
* Forward 'vpn' -> 'lan'
* Forward 'vpn' -> 'wan'
* Zone 'lan'
* Zone 'wan'
* Zone 'vpn'
* Populating IPv4 nat table
* Redirect 'HTTP'
* Redirect 'SSL'
* Redirect 'Submission'
* Redirect 'imapssl'
* Redirect 'dcc'
* Redirect 'snail2 ssh'
* Redirect 'video'
* Redirect 'smtps'
* Zone 'lan'
* Zone 'wan'
* Zone 'vpn'
* Populating IPv4 mangle table
* Zone 'lan'
* Zone 'wan'
* Zone 'vpn'
* Populating IPv4 raw table
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
* Zone 'vpn'
* Populating IPv6 filter table
* Rule 'Allow DHCPv6'
* Rule 'Allow MLD'
* Rule 'Allow ICMPv6 input'
* Rule 'Allow ICMPv6 forward'
* Rule 'IPsec IKE'
* Rule 'IPsec NAT-T'
* Rule 'IPsec ESP'
* Rule 'isolate guest'
* Rule 'isolate iot'
* Rule 'firewalled dhcp'
! Skipping due to different family of ip address
* Rule 'firewalled ntp'
! Skipping due to different family of ip address
* Rule 'isolate firewalled'
* Forward 'lan' -> 'wan'
* Forward 'vpn' -> 'lan'
* Forward 'vpn' -> 'wan'
* Zone 'lan'
* Zone 'wan'
* Zone 'vpn'
* Populating IPv6 mangle table
* Zone 'lan'
* Zone 'wan'
* Zone 'vpn'
* Populating IPv6 raw table
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
* Zone 'vpn'
* Set tcp_ecn to off
* Set tcp_syncookies to on
* Set tcp_window_scaling to on
* Running script '/etc/firewall.user'
* Running script '/etc/firewall.d/qca-nss-ecm'
* Running script '/usr/share/miniupnpd/firewall.include'
root@route10:~#
I stand corrected with what I wrote earlier, and I’m sorry that I misspoke. Yes the modules will be loaded in that context, but the problem is that we can’t turn off SIP ALG using LuCI/fw3. I am testing something now.
Mike can we circle back to the main question you answered before, but is not working for me?
With my Route10 on firmware 1.3w, how do I permanently disable Sip ALG?
I misunderstood what I was looking at earlier. Checking something now…
I don’t have anything SIP based services at this moment. Is it behaving like it’s still enabled?
root@route10:~# conntrack --dump |grep sip
udp 17 3593 src=192.168.10.103 dst=208.100.60.40 sport=5060 dport=5060 packets=350 bytes=19985 src=208.100.60.40 dst=157.131.126.65 sport=5060 dport=5060 packets=4 bytes=2373 [ASSURED] mark=0 helper=sip use=1
192.168.10.103 is the ip address of our Grandstream ATA. The good news is that it’s working.
1 Like
Let’s try that again. We’re going to look at permanently disabling the modules from loading. That said, this might be a workaround but I don’t know that I can properly test it. The RingCentral app didn’t at least but unsure expectations (never checked that traffic)
So if you create a post-cfg.sh file, and include this:
# Remove SIP lines from modules.d
sed -i -e '/^nf_conntrack_sip$/d' -e '/^nf_nat_sip$/d' /etc/modules.d/nf-nathelper-extra
# Unload modules if they were already loaded
rmmod nf_nat_sip 2>/dev/null
rmmod nf_conntrack_sip 2>/dev/null
That may work, and will make it persistent across reboots. Technically we could also set a firewall chain to not track but… I’m not sure that’s a method to recommend.
The absolute path on Route10 including filename needs to be: /cfg/post-cfg.sh. You could use vi or nano directly on Route10 to create that file, or use your preferred editor on your computer, but line endings require to be line feed (LF) if going that route.
Once the file is in-place and you’re connected via shell, issue: chmod +x /cfg/post-cfg.sh. You should then just be able to run it with: /cfg/post-cfg.sh.
Thank you for looking into this @Alta-MikeD and @Alta-Josh. I just wanted to clarify that when I stated evidence of SIP ALG existing was not in reference to my Route10 itself, but the SIP services I use at my home. My wife works from home, for a whitelabel VoIP provider, and has a few IP phones. They are working okay, but it is clear that SIP ALG is not disabled. I also have a simple cmd program I run that tests for SIP ALG and it is failing.
Since the phones are working okay, I am not too pressed to dig around in the cfg but it would be good to have an easy, and permanent, way to disable SIP ALG.
1 Like
I don’t think that works. After rebooting:
root@route10:~# lsmod |grep sip
nf_conntrack 94208 34 ecm,xt_connlimit,nf_conncount,xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connbytes,xt_REDIRECT,xt_NETMAP,xt_MASQUERADE,xt_DSCP,xt_CT,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_nat,nf_flow_table,nf_conntrack_tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_rtcache,nf_conntrack_pptp,nf_conntrack_netlink,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,nf_conntrack_broadcast,nf_conntrack_amanda
nf_conntrack_sip 32768 4
root@route10:~#
root@route10:~# conntrack --dump |grep sip
udp 17 3583 src=192.168.10.103 dst=208.100.60.40 sport=5060 dport=5060 packets=25 bytes=3151 src=208.100.60.40 dst=157.131.126.65 sport=5060 dport=5060 packets=3 bytes=1827 [ASSURED] mark=0 helper=sip use=1
I’d guess editing nf-nathelper-extra after boot time has no effect and:
root@route10:~# rmmod nf_conntrack_sip
unloading the module failed
I don’t think this is a critical issue for me - unless SIP ALG weirdness is whats freezing my ATA every couple of weeks (to the point where it’s MAC address doesn’t show up). Hopefully just replacing it will make things good.
That said, seems like SIP ALG should at least be disabled by default. Do any voip providers recommend it?
1 Like
None that I have run across. My wife works for a whitelabel VoIP provider, and I work part time support for them, and we won’t even troubleshoot endpoints if SIP ALG is active. It’s a remnant from the past that, as far as I have seen, is no longer necessary. There may be some use cases for it that I am not aware of.
Are there any hooks - like post-cfg.sh - that get run much earlier in boot process?
Looks like putting that edit of nf-nathelper-extra in /cfg/fixup-config might work.
1 Like
I can confirm with 100% certainty that this is planned, but I don’t know timeline.
So, thanks a lot for properly testing this. I’m not sure what other system modifications I’m not allowed to officially confirm, but unofficially it looks like you’re looking in the right spot (at least if there is a script location that would be appropriate to run it).
That was still too late to fix the problem. /cfg isn’t mounted until after kmods are loaded.
What did work though was in post-cfg adding to the lan zone (is that always 0? If not need to extract it) :
uci set firewall.@zone[0].auto_helper='0'
uci set firewall.@zone[0].helper='amanda ftp RAS Q.931 irc pptp snmp tftp'
uci commit
/etc/init.d/firewall reload
It takes a list, and those are all the ones but sip that were previously active.
To see what’s enabled:
root@route10:~# iptables -traw -vL |grep helper
2220 344K zone_lan_helper all -- br-lan any anywhere anywhere /* !fw3: lan CT helper assignment */
16 1040 zone_lan_helper all -- br-lan_2 any anywhere anywhere /* !fw3: lan CT helper assignment */
87 11634 zone_lan_helper all -- br-lan_3 any anywhere anywhere /* !fw3: lan CT helper assignment */
131 31281 zone_lan_helper all -- br-lan_4 any anywhere anywhere /* !fw3: lan CT helper assignment */
Chain zone_lan_helper (4 references)
0 0 CT udp -- any any anywhere anywhere /* !fw3: Amanda backup and archiving proto */ udp dpt:10080 CT helper amanda
0 0 CT tcp -- any any anywhere anywhere /* !fw3: FTP passive connection tracking */ tcp dpt:ftp CT helper ftp
0 0 CT udp -- any any anywhere anywhere /* !fw3: RAS proto tracking */ udp dpt:1719 CT helper RAS
0 0 CT tcp -- any any anywhere anywhere /* !fw3: Q.931 proto tracking */ tcp dpt:1720 CT helper Q.931
0 0 CT tcp -- any any anywhere anywhere /* !fw3: IRC DCC connection tracking */ tcp dpt:ircd CT helper irc
0 0 CT tcp -- any any anywhere anywhere /* !fw3: PPTP VPN connection tracking */ tcp dpt:1723 CT helper pptp
0 0 CT udp -- any any anywhere anywhere /* !fw3: SNMP monitoring connection tracking */ udp dpt:snmp CT helper snmp
0 0 CT udp -- any any anywhere anywhere /* !fw3: TFTP connection tracking */ udp dpt:tftp CT helper tftp
2 Likes
If you want to disable all the helpers (I don’t see any that seem that useful), do
uci set firewall.@zone[0].helper=''
uci set firewall.@zone[0].auto_helper='0'
uci commit
if you don’t set auto_helper=‘0’, helper=‘’ implies all. (Not the cleanest semantics…)
2 Likes