All,
I have read a few threads about upgrading to newer versions of OpenWrt (post-17.01.4) - that connection trackers were needed for certain protocols. Perviously they did not have to be explicitly enabled/installed.
My questions are:
Thanks @jeff ...and now I'm unsure if I should follow my thread or the previous one.
LOL...In any case, this package is installed - it appears to be included in the default OpenWrt firmware. Would I need to make some kind of custom firewall rule?
In my experience sip connection tracking type stuff is something you want to steer clear of as much as possible usually it hurts more than helps.
If you explain your setup in some more detail I can give you some hints as to what might be needed. Do you have a SIP server
do you have clients (check all that apply)
Do your clients or server support ipv6 and do you have ipv6 connectivity with low latency?
Do you have any actual issues with your SIP set up at the moment? dropped calls, one way audio, etc?
I have a SIP client and server that conencts directly to registrations AND SIP endpoints on the Interent.
A server and client in LAN, and a client that registers to my SIP server via a Wireguard tunnel. There are no inbound SIP connections, everything is behind a firewall.
None, everything was working until one day I went to make a telephone call to a POTS number. I should also note that I'm using a applet in my server that provides Google Voice. Since it's not standard SIP, I may have to simply revert to 17.01.4 in order to ensure that the it isn't a non-standard port problem (or that the service has been ended).
When actually testing and making endpoint calls using SIP protocol, have not observed any issues. In addition, the endpoint connected via Wireguard can make internal calls to my LAN endpoints (which calls are set up calls via the SIP server).
second that!
i was fighting with sip aswell until i set net.netfilter.nf_conntrack_helper=0 and never looked back
Can you explain why disabling that helped your situation?
My understanding is that the sip conntrack modules rewrite the sip packets to fiddle around with port numbers... this rarely works as intended, and it FULLY BREAKS when ipv6 is in use.
did not bother after "it works"
net.netfilter.nf_conntrack_helper = 0
Mine already appears set...LOL.
AAAH!!! This could be an issue.
Since I have no ct enabled...I'm unsure (I'm lost about the CT helpers noted in the RAW table work now)...but thanks guys!
I'd definitely look into whether that GV feature just isn't working anymore. My impression is that Google isn't putting much effort into that now that they've amassed the massive database of voice calls they've been using to train their voice recognition system. That was always the plan from the start.
As @dlakelan said, stay away from and connection tracking stuff as it does more harm than good in 99.9% of all cases. Unless your client is really old and crusty it'll handle NAT just fine by its own, if you're a bit "lucky" it might even support UPNP which can help a bit.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.