Thank you both for your replies.
Client followed some of mine guidelines and has proven that the issue is
with the Fortinet F5 firewall: he made a snapshot of the kamailio node #2
that we know is 100% working, installed the snapshot, modified the IPs, and
made tests, and the behaviour is identical to node #1. The relevant
question is why node #2, who has the same rules as node #1, is working
fine, but not nodes #1 and #3 ?! doesn't make much sense...
Meanwhile, client has been dealing with the issue with Fortinet's
engineering team. Looks like a firmware issue...
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Wed, Sep 18, 2024 at 10:35 PM Karsten Horsmann <khorsmann(a)gmail.com>
wrote:
Hi Sergio,
You answer the right questions. Works it before, yes. Changed the Kamailio
system, no. So it's an Fortinet fault.
By painful experience with Cisco and Fortinet stuff I know that you need
to tweak the Fortnite (SIP ALG, SIP POLICY and so one).
Go in that direction cause it works with Cisco before and the Fortigate
seems to break it.
Kind regards
Sergio Charrua via sr-users <sr-users(a)lists.kamailio.org> schrieb am Mi.,
18. Sept. 2024, 10:19:
Hi all!
got a client with 2 Kamailio servers using Pacemaker/Corosync with a VIP.
Kamailio is setup with dispatcher, and has been working since 2018.
This previous week, client migrated from a Cisco ASA firewall to a
Fortinet F5 firewall.
One of the Kamailio server is, apparently, working fine, receiving SIP
invites and processing them correctly.
When moving the VIP to the second Kamailio node, Kamailio is ignoring any
SIP message that is not OPTIONS, despite configuration (kamailio.cfg) being
exactly the same as in the node #1.
Also, note that using SNGrep, we can see clearly that SIP messages are
reaching the server, but Kamailio is just not processing any INVITE. In
fact, I added an output to log file right at the very beginning of the main
route and the line is added to log file ONLY if the SIP message is OPTIONS.
When the SIP message is INVITE, nothing is processed on Kamailio's side.
The listen parameter is set to 0.0.0.0 port 5060 and advertised IP set to
the Public IP.
Again, the main route is only :
route{
xlog(. ......);
}
Kamailio version is 5.1.6 (old, I know....) but it has been working since
Dec 2018!
What could be the issue?!
Why only OPTIONS are being , somehow, recognized by Kamailio and all
other SIP messages just ignored?
Also, to add some more weirdness to the mess, connecting an Asterisk
server on the same network, and sending a call to Kamailio node #2, it
works!! SIP messages of any kind are processed correctly by Kamailio on
node #2.
So, why doesn't it work with SIP messages received via Public IP address,
even though the messages reach the server correctly (confirmed using
SNGrep) ???
I spent 5h this afternoon trying to understand what is wrong, but I'm
stuck .... and no clue so far, apart from suspecting of the new Gateway,
which I have no access to configurations.... but if OPTIONS are received &
processed OK, it wouldn't make sense that received INVITES would be ignored
by Kamailio, right?
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe: