[tedm]

I noticed this on r62240 when I updated a pair of Netgear routers but I don't think it's hardware specific and I suspect it's been happening for a number of builds. The last builds I had on these devices were from around March of this year I think and there were no problems with them.

Anyway, what is going on is this. I have these 2 setup to create an OpenVPN VPN between 2 sites. I have a PBX at one site and 6 phone extensions at the other. Some of those extensions register into chan_sip running on port 5160 on the PBX the others register into chan_pjsip running on port 5060 on the PBX.

Immediately after updating all phones using chan_pjsip lost registration. As a test I changed the port on the extensions using chan_pjsip on 5060 over to chan_sip on port 5160 and those extensions immediately re-registered. Needless to say, extensions on the PBX side that were registered into port 5060 were not affected, showing the problem wasn't the PBX

I know that there's been many reports saying "ALG" or "sip ALG" on routers will screw up SIP. But I do not see any kind of option in the current build to turn anything of this nature on, unless it is the so-called SPI Firewall but that shouldn't affect anything going through a VPN.

And I also can confirm that OpenVPN itself has always been a pain when it comes to SIP traffic.

I've got wireguard setups on both sides but it's a pain to set these up and it's only going to tell me that something in the VPN is screwing packets up. This is a dd-wrt problem for sure, any suggestions on where to start digging? (backreving dd-wrt is risky since I have to do both devices, one is remote, and could go offline and be unreachable during an update)

[egc]

[tedm]

The SPI Firewall is turned off on both routers.

It's either something in OpenVPN that's doing it or it's something in the router OS

If Brainslayer was using newer code from Broadcom for a newer kernel, whether binary blob or source, then something that intercepts the SIP port 5060 came along for the ride. And that something is undoubtedly SIP ALG:

https://www.voicehost.co.uk/help/sip-alg-and-why-it-should-be-disabled-most-routers

ALG is part of the address translation code and I know from experience that even though OpenVPN on these routers can be configured to turn OpenVPN's internal NAT off, that configuration setting for OpenVPN is only available if DD-WRT is setup as a client OpenVPN. If DD-WRT is setup as a server, it's not available - however, in my setup the server side of my VPN is a DD-WRT router configured as a router not a gateway, so translation is off.

So, it's got to be the client side that's doing it since the OpenVPN nat is disabled. I do have hardware NAT selected on the client VPN side. It's possible the port 5060 interception is happening there.

But the overall problem going on here is when a DD-WRT router is setup as either an OpenVPN server or OpenVPN client, packets going in and out of the VPN need to NOT be passed through the translation engine. It's not good enough to just pass them through the translation engine with an exception rule in the engine telling it to not mess around with the packets.

Brainslayer really needs to closely examine the code, here. Ideally, anything going into OpenVPN needs to be routed around the translation engine not passed through it with rules telling the translator to leave those packets alone. But, that kludge was working before so it should still be working, and since this only affects port 5060 it's probably still working. The breakage is very narrowly targeted it is just SIP going through port 5060, not SIP in general.

Port interceptions can happen anywhere in the TCPIP stack and clearly 5060 is being intercepted for ALG. Brainslayer may have excised the ALG code but the "offramp" to it was missed and needs to be demolished also.

Using port 5160 is a workaround but it's not optimal and it also is really sort of scary that something is going on under the hood in DD-WRT that isn't being brought out in a configuration directive that can be shut off.

Most likely this is ALSO going to screw with the more default case of Grandpa Kettle with his VoIP desktop telephone that's registering into some cloud PBX sip provider. Nobody has complained yet because none of those people run cutting edge DD-WRT code.

But this really does need to be looked into because it definitely happened quite recently. I can't muck about with backreving router firmware for another month since one of the routers is 80 miles away and if I remotely brick it, I'm SOL. But for sure, since this is SO narrowly targeted at port 5060, and we know it's happened sometime since February (and I'm also thinking that I did have code from June or thereabouts running on one of them) it shouldn't be THAT difficult to find and kill.

If Brain -wants- the ALG code into DD-WRT, then it needs to be deselectible since just about all ALG implementations are garbage, they are copies of custom modified ALG code for how some specific ISP did SIP. ALG code is a carryover from years ago when phones didn't have the ability to insert public IP's into outgoing SIP registrations and just dumbly used their interface private number. I will point out that one of the reasons people in the VoIP community like DD-WRT is because it's known for NOT having SIP ALG code in it so I would strongly advise NOT going down the road of trying to include it in DD-WRT as a "feature"