Thank you. Turns out that template was just the answer I was looking
for. I don't know where Kamailio's been all my life...
5060 is only open to the private PBX. And I'm just using one PBX to
register the mobile clients to (from there I just do wizardry to get to
all the others).
I rolled back the hack job I did on the template and just tried your
suggestion. Seems to put it in a loop which craps out after too many hops.
On 7/11/2025 10:43 PM, Fred Posner wrote:
>> On Jul 11, 2025, at 10:23 PM, Jeremy Weibert via sr-users <sr-users@lists.kamailio.org> wrote:
>>
>> I'm new to Kamailio, and looking for some guidance.
>>
>> I have a very large global PBX network (NEC). I have mobile users, that for many years we have had connecting through VPN. This has worked fine for us until recently, various circumstances have made this unreliable. In searching for a better way to handle this, I came across Kamailio. I want the mobile users using TLS/SRTP, the NEC has various limitations on that, but more importantly, I'm not putting my PBXes on the internet. I've been at this for a few days now, learning and trying to see how I can do this with Kamailio, when I eventually came across this: https://www.fredposner.com/2309/kamailio-simple-tls-gateway/#:~:text=One%20feature%20that%20truly%20shines,aka%20to%20the%20PBX.
>>
>> Seems this is exactly what I need. The only difference really is that I have an additional firewall between the internet and the Kamailio server, with the external IP being NATed.
>>
>> In the famous last words of all users "it didn't work". Specifically, registrations seem to work just fine (the NEC acts as the registrar). However, when making a call:
>>
>> - The original INVITE from the mobile user (port 5061, TLS) reaches Kamailio and is then proxied via UDP to the PBX.
>> - The PBX behaves appears to behave as a B2BUA, creating a completely new INVITE with a different Call-ID and sending it back to Kamailio.
>> - Kamailio, seeing this as a completely new INVITE coming in on UDP (not TLS), rejects it (403 Accepting TLS Only).
>> - Likewise, if a call originates from the PBX side, same thing.
>>
>> I figure, if the INVITE is coming from the PBX, I can just skip the TLS check, as it's coming from a trusted IP. However, the INVITE looks like:
>> INFO: {1 udp 1 INVITE 7776d675@PBXIP} <script>: {R-MAIN] Incoming request from PRIVATEIP using udp
>>
>> In other words, the INVITE is showing as coming from Kamailio.
>>
>> I can't use the alias tag that Kamailio sets initially as the PBX strips it with the new INVITE. I figure to just explicitly send it to registered client over TLS by just rewriting the destination URI, and then it goes into an infinite loop.
>>
>> I got a bit lost at this point and if someone could help point me in the right direction, I would be eternally grateful.
>>
>
> That was a fun template… put up at the height of covid lock downs…
>
> It assumes, in that config, that 5060 is ONLY open to your private PBX (hence in not having an advertised address)… It also assume just one PBX.
>
> There’s a check in there about matching the PBX IP to the known IP, in which case it forwards on…
>
> You could easily change:
>
> if ($si=="PBXIP") {
>
> To
>
> If ($Rp==5060) {
>
> And have it be the same thing… assuming of course that UDP 5060 is only internal.
>
>
>
>
> Regards,
>
> Fred Posner
>
>