Asterisk 13 is past end of life. chan_sip is deprecated, and will be removed in just over a year. So the first suggestion is to re-implement with chan_pjsip.
The sip.conf shows many common bad practices.
I don’t recognize the GUI, but in any case support from the GUI needs to come from its suppliers.
insecure=invite makes no sense without a secret, but if you did have a secret, with it, Asterisk wouldn’t generate a 401, if the INVITE matched the configuration. I therefore assume it doesn’t match.
For a match, either the source address has to match the host address, or the section name (VITALPBX??) has to match the From user. I don’t see anything that I can reasonably guess would set the from user. It looks like address isn’t matching because you are getting the FW address, rather than the VitalPBX one. That suggests you have an application level gateway enabled, assuming FW refers to a firewall in a router. Application level gateways are usually a bad thing.
I assume that the 401 is probably there to confuse an attacker, as the result of “always auth reject”, or VITALPBX?? is matching a device that does have a secret.
?? means two blurred splodges.
If you are not trying to match the From user agaisnt VITALPBX??, you shouldn’t be using type=friend. Especially given there is no password, it could be a security hazard (I can’t see how you use contexts).
401 is not an error. It is a request to provide a password, although, as I’ve speculated above, the reason you are being asked for a password, is that the call is coming from an unknown address, not anything listed in sip.conf.
Please post configurations as text, not images. I presume, as there is no template, that the section you posted earlier has context public. I hope that context can’t make chargeable calls, as your type=friend make that relatively easy to abuse.
No. That says that UDP datagrams (which are connectionless) can be accepted on all the machines interfaces, on the the chosen port.
The packets are being accepted but they are then failing to match any sip.conf entry, because they come from FW IP, rather than VitalPBX IP. You really need to correct where they come from to create a secure solution.
If the bind was wrong, there would be no 401s, because the INVITEs would never have reached Asterisk.
Call Log in VitalPBX from call Asterisk (13.27) to VitalPBX
Call Log in VitalPBX from call Asterisk (13.27) to VitalPBX
Call flow for 23aef3325e9b6e8041459fbb4cbb9ddd@ Asterisk (13.27)IP:5060 (Color by Request/Response)
xINVITE sip:75003@vitalpbx01 SIP/2.0 Asterisk (13.27)IP:5060 vitalpbx_IP:5060xVia: SIP/2.0/UDP Asterisk (13.27)IP:5060;branch=z9hG4bK06ec6ceb
qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqqxMax-Forwards: 70
x INV (Asterisk (13.27)IP) x xFrom: “João Pedrosa” <sip:69197@Asterisk (13.27)IP>;tag=as554c39fe
x audio 17902 (g711u) x xTo: sip:75003@vitalpbx01
17:08:53.361377 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x xContact: sip:69197@Asterisk_13_27_IP:5060
+0.000921 x 100 Trying x xCall-ID: 23aef3325e9b6e8041459fbb4cbb9ddd@Asterisk_13_27_IP:5060
17:08:53.362298 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x xCSeq: 102 INVITE
+0.086238 x 180 Ringing x xUser-Agent: Asterisk PBX 13.27.0
17:08:53.448536 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x xDate: Fri, 20 May 2022 16:08:53 GMT
+0.054411 x 180 Ringing x xAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
17:08:53.502947 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x xSupported: replaces, timer
x 200 (vitalpbx_IP) x xRemote-Party-ID: “João Pedrosa” sip:69197@Asterisk_13_27_IP;party=calling;privacy=off;screen=no
+2.884246 x audio 17368 (g711u) x xContent-Type: application/sdp
17:08:56.387193 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x xContent-Length: 285
+0.001729 x ACK x x
17:08:56.388922 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x xv=0
x x xo=root 17635627 17635627 IN IP4 Asterisk_13_27_IP
x x xs=Asterisk PBX 13.27.0
x x xc=IN IP4 Asterisk_13_27_IP
x x xt=0 0
x x xm=audio 17902 RTP/AVP 0 8 3 101
x x xa=rtpmap:0 PCMU/8000
x x xa=rtpmap:8 PCMA/8000
x x xa=rtpmap:3 GSM/8000
x x xa=rtpmap:101 telephone-event/8000
x x xa=fmtp:101 0-16
x x xa=maxptime:150
x x xa=sendrecv
x x x
x x x
x x x
When I receive the call from Asterisk in VitalPBX, i see the IP from Firewall and the call work without problems
I think that the problem could be the authentication in side of my asterisk, like you said “401 is not an error. It is a request to provide a password,”
I give up. I’ve told you what is wrong. Turn off the SIP ALG (or configure the system on the basis that the calls are coming from FW IP and not from VitalPBX, although I think this is a good solution).