[sr-dev] [kamailio/kamailio] Issues with single Kamailio process in two networks/vlans (#1703)

Thomas Lobker notifications at github.com
Thu Nov 1 19:31:20 CET 2018


To start off. Please forgive me, I'm not completely sure if this is an issue in Kamailio, or an issue in Linux that I'm overseeing. But I could really use a helping hand.

### Description

I have a setup with a Kamailio load-balancer and a secondary proxy that is handling all the complex work, let's call them balancer and core proxy. The core proxy is only listening on a private network, that's a separate VLAN with an rfc1918 IP address. The balancer is listening on that network too, but it has also a listening socket on a different VLAN with a public internet IP address.

```
Balancer:
 - Public IP  : 150.0.0.51 (interface ens9, vlan 150)    ----
 - Private IP : 10.0.0.51 (interface ens3, vlan 10)         |
                                                            |
Core:                                                       |
 - Private IP : 10.0.0.52 (interface ens3, vlan 10)   <------
````

When I'm sending an INVITE I see the balancer receiving the UDP packet on `150.0.0.51` and relaying it from the same address to `10.0.0.52`. On the core proxy (different server) I can see the packet coming in with tcpdump or ngrep. Kamailio seems to completely ignore this packet. Bumping up the debug level to the maximum still results in no logging at all when I send the SIP packet.

Now I can work around this issue by forcing the send socket to use the private IP on the balancer. But this introduces new problems in my environment, because I have actually many balancers and core proxies in a high availability setup and the return path to the user should always remain the same.

We can also work around this issue by exposing a public IP to the core proxy (and other internal proxies). But I really would like to keep only the load-balancer exposed to the internet. I have this working with Kamailio `5.1.1` in an existing environment, but now we are moving from Ubuntu `16.04` to Ubuntu `18.04` and updating Kamailio to `5.1.6` and it's not working anymore.

### Additional Information

  * **Kamailio Version**:
```
Tested with 5.1.6 and 5.1.2
```

  * **Operating System**:

```
Ubuntu 18.04.1 LTS
4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
```

### Logging

I can see a `REGISTER` packet like this coming in on the core proxy (with many retransmissions), here is the `ngrep` output captured on the core proxy on interface `ens3`:

Not working:

```
#
U 2018/11/01 18:57:55.548408 150.0.0.51:5060 -> 10.0.0.52:5060
REGISTER sip:my.domain SIP/2.0.
Via: SIP/2.0/UDP 150.0.0.51;branch=xxx.
Via: SIP/2.0/UDP 10.x.x.x:34904;received=x.x.x.x;branch=xxx;rport=34904.
From: "200" <sip:200 at my.domain>;tag=xxx.
To: "200" <sip:200 at my.domain>.
Call-ID: xxx.
CSeq: 565 REGISTER.
Max-Forwards: 69.
User-Agent: snomD345/8.9.3.33.
[...]
```

But when I force the source socket to be the private address:

Working:

```
#
U 2018/11/01 19:03:42.914001 10.0.0.51:5060 -> 10.0.0.52:5060
REGISTER sip:my.domain SIP/2.0.
Via: SIP/2.0/UDP 150.0.0.51;branch=xxx.
Via: SIP/2.0/UDP 10.x.x.x:34904;received=x.x.x.x;branch=xxx;rport=34904.
From: "200" <sip:200 at my.domain>;tag=xxx.
To: "200" <sip:200 at my.domain>.
Call-ID: xxx.
CSeq: 587 REGISTER.
Max-Forwards: 69.
User-Agent: snomD345/8.9.3.33.
[...]
```

Now Kamailio is processing the request normally for some reason.

Any help or suggestions will be appreciated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20181101/3b21cb69/attachment-0001.html>


More information about the sr-dev mailing list