We added a listen on localhost and forced the outside application server to return 127.0.0.1 instead of the IP of Kamailio. This worked as expected, but wasn't the solution we were looking for.

It turns out that enabling sysctl net.ipv4.ip_forward=1 resolves the original issue. Is IP Forwarding a normal requirement for Kamailio in general?

For reference, running "ip route get _interface_ip_" on other Linux servers confirms that the "lo" interface is used when sending packets to an assigned Ethernet IP address.

On Thu, May 11, 2023 at 3:19 AM Henning Westerholt <hw@gilawa.com> wrote:

Hello,

 

usally there are not special requirements regarding the localhost. Is kamailio actually listening on the localhost? You could check e.g. with netstat or kamcmd/kamcli commands.

 

Cheers,

 

Henning

 

From: Calvin E. <calvine@gmail.com>
Sent: Dienstag, 9. Mai 2023 16:21
To: sr-users@lists.kamailio.org
Subject: [SR-Users] ICMP Port Unreachable using loopback interface with ethernet IP

 

The scenario is Kamailio on Debian 11 talking to an external application server that returns a 302 with a Contact that contains Kamailio's own IP and a different port. Kamailio is listening on the correct port via at the given IP address. However, when Kamailio creates the packet to talk to itself, it it send over the loopback adapter "lo" and gets an ICMP port reply:

 

listen=udp:KAMAILIO_INTERNAL_FLOATING_IP:8888

 

    10.z.a.b.5000 > 10.z.x.y.5060: SIP, length: 849
        SIP/2.0 302 Moved Temporarily
        Contact: <sip:44123456...@10.z.x.y:8888>

 

15:39:00.548722 lo    In  IP (tos 0x10, ttl 64, id 5431, offset 0, flags [none], proto UDP (17), length 949)
    10.z.x.y.5060 > 10.z.x.y.8888: SIP, length: 921
15:39:00.548732 lo    In  IP (tos 0xd0, ttl 64, id 19038, offset 0, flags [none], proto ICMP (1), length 576)
    10.z.x.y > 10.z.x.y: ICMP 10.44.7.136 udp port 8888 unreachable, length 556

 

Do I need to configure something in the OS or Kamailio to allow the ethernet IP to work via the loopback adapter? I haven't set up any special networking to cause this, it appears to be a Linux kernel behavior.