I upgraded asterisk 18.5.0 to 18.5.1and now 2 clients can’t connect anymore, register request are coming to the server (sngrep as well as tcpdump see them) but asterisk doesn’t, a pjsip set logger host display nothing nor core set debug do. Ips are not banned.
Asterisk is running in a VM on Debian 11, nftables is the firewall. A lot of other users are going through without any problem, VPN as well as public IP. This problem arise from time to time and restarting the server -not the virtual machine- does solve the problem.But restarting a server is not the final solution, so what could be wrong here ?
You haven’t given enough information to diagnose the problem. You need to show the configuration and a SIP trace as well as the current status (e.g. pjsip show contacts, …).
It could be that the problem has nothing to do with the small update, but that there is a problem with the 2 clients or the connection to the 2 client.
pjsip show contacts show nothing as they are not registered The problem doesn’t lie on the small update but on each time or so that asterisk is restarted.
Main question is why other clients using similar configuration doesn’t have this problem ? I agree that it is a NAT related issue within asterisk. I restarted the VM and everything is back to live. Before this I restarted asterisk (core stop now && systemctl restart asterisk) but get no changes.
Again, requests are coming to port 5060 as shown by sngrep & tcpdump but asterisk ignore them silently.
Again, you haven’t shown us anything that allows to see what is going on. The usual answer to such problems is, that something else has been overlooked. I would recommend to tackle this systematically by following the traffic in both directions.
Asterisk does not have any NAT related problems, but you might.
That said, I do not have the foggiest idea what you are trying to say. OPTION dialogs are not related to registrations and PJSIP contacts are also something different.
As said in my original post, I did: REGISTER is coming in on the VM interface as shown by sngrep and tcpdump but asterisk NEVER answer eg, no traffic coming out from asterisk. This was validated by the point that pjsip set logger host as well as core set debug 1 never show any information about the 2 IPs Hmm, only with 2 IPs and everything is working well after restart of VM ? Plenty of other customers are connected same way. For me, some related connections in asterisk are not released when asterisk is restarted. Where did I said that ?
And it happen again this night with another customer. Output of a tcpdump from source address (udp and port 5060 and src or dst 2001:db8::738) this morning
tcpdump/sngrep capture are done ON the asterisk server which is also running nftable. I see the packet coming in but no answer. No problem for others customers, IP is not in fail2ban aso. Restarting the server make things going well again without modifying any parameter.
New step: on the server who can’t connect (the one who sends above OPTIONS w/o getting answer) I ran nc -uv 2001:db8::5811 5060
and get Connection to 2001:db8::5811 5060 port [udp/sip] succeeded!
I did a core set verbose 5 and core set debug 5 and pjsip set debug host 2001:db8::738, not any trace from this IP in logs. In the mean time tcpdump show OPTIONS packet coming from this IP to port 5060. Well well well …
Can you sketch the complete network path for a phone that shows problems? There are too many unknowns in the equation to say something meaningful. It was new to me that there is IPv6 and that means that the usual (forward) NAT related problems are likely irrelevant, but that depends on your setup.
It could also be a problem with outgoing traffic, but that could be more predictable. If you pack everything into containers, there’s another network involved and that can also cause problems. We just do not have enough information.
Once you have a network plan, I’d suggest to sketch where traffic flows and where not. Ingress and outgress ports are important. If you think you a priori know what the error is, you’ll never the reason.
I opened the ticket on monday having this behavior for 2 clients in ipv4. There access is
Internet > our Physical Server > VM under KVM running Asterisk & nftables The problem was solved by restarting the VM.
Yesterday arise the problem for an ipv6 customer. His access
customer asterisk > local net > customer gateway > wiregard VPN > our Physical Server > VM under KVM running Asterisk & nftables For him, problem exist for IAX and SIP and ONLY in the way customer to us (he is NOT registering). Other way no problem. We switch him in SIP/ipv4 and it work.
Problem arised monday after having restarted Asterisk following upgrade from 18.20.0 to 18.20.1 Yesterday, for the ipv6 customer, there wasn’t any network failure -local or Internet- who can’t explain why the problem arise. Remember, plenty of other customers are connected with or without VPN (OpenVPN and Wireguard), ipv4 or ipv6, without any issue including our office.
In both cases, customers are connected as showed since years and never face this problem.
I read in the yesterday 18.20.2 version “res_pjproject: ast_sockaddr_cmp() always fails on sockaddrs created by ast_sockaddr_from_pj_sockaddr()”: could the problem come from here?
As the customer has a working setup I didn’t restart the VM so the problem still exist in ipv6 if you want me to do some checks or manipulations keeping in mind that the server is in production.
No. The problem would not be resolved from that change (the issue itself existed for years and was only exposed through using the function in a new way), and none of the changes in .1 or .2 are in any area that would cause this.
Guess what: at 6:00:02am this morning both SIP and IAX in ipv6 went back to live !!! Neather on one or other server there is a cron daemon who could explain the why it worked again
Any idea ?
The problem doesn’t lie on the small update but on each time or so that asterisk is restarted.