[kamailio/kamailio] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103) - sr-dev

List overview All Threads
Download

newer

[kamailio/kamailio] [Feature Request]: Add connection IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)

older

git:master:757bf4fa: dialog: docs...

Re: [sr-dev] [SR-Users] Routing...

Joel Serrano

17 Oct 2019 17 Oct '19

8:27 p.m.

### Description

When using Kamailio with `tcp_accept_haproxy=yes`, the `$si` and `$sp` variables have the real IP & Port information from the original connection to the LB leaving no way to access the connection IP & Port from where the packet is received from Kamailio perspective.

### Possible Solutions

Create two new pseudovariables that contain the connection IP & Port where the packet was received for use cases where `tcp_accept_haproxy=yes`.

Suggested names (but could be any): $CI and $CP meaning -> Connection IP and Connection Port.

### Example

With `tcp_accept_haproxy=yes`:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB **with** Proxy Protocol (3.3.3.3:57482) -> (4.4.4.4:5060) Kamailio.

``` $si = 1.1.1.1 $sp = 45621 $CI = 3.3.3.3 $CP = 57482 ```

With `tcp_accept_haproxy=no`:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB **without** Proxy Protocol (3.3.3.3:57482) -> (4.4.4.4:5060) Kamailio.

``` $si = 3.3.3.3 $sp = 57482 $CI = 3.3.3.3 $CP = 57482 ```

I don't think there is any way to get the `3.3.3.3:57482` IP and Port from the example above when using `tcp_accept_haproxy=yes` but I could be wrong.

Thanks! Joel.

-- 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/2103

Attachments:

attachment.html (text/html — 2.8 KB)

Show replies by date

Henning Westerholt

18 Oct 18 Oct

5:12 a.m.

Well, one could argue that is according to the design of the HA Proxy feature. ;-) Why do you need this information, just for logging etc..?

About the name suggestion, we should go for $Ci and $Cp - a capitalized second character is usually used in combined PVs (e.g. $ru, $rU, $rD etc..). We also already have $Ri and $Rp for received IP and port.

-- 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/2103#issuecomment-543620282

Joel Serrano

10:08 a.m.

Hi @henningw,

AFAIK: As we are talking about TCP + Proxy Protocol here, this means that most likely the LB between Kam and the UAC only understands connections (pure TCP proxy). Although I have access to the UAC's IP:Port (which is the goal of tcp_accept_haproxy=yes, and this shouldn't change), if I have to send a msg to the UAC and I don't want to go directly (Kam->UAC) but I want to go via the LB where the request came from (KAM->LB->UAC) I need to send the msg to the IP:Port KAM received, and the LB will send that to the IP:Port it received.

For certain scenarios just using `force_rport()` works, but not for all.

Following previous example of:

UAC (1.1.1.1:45621) -> (2.2.2.2:5060) LB with Proxy Protocol (3.3.3.3:57482) -> (4.4.4.4:5060) Kamailio.

``` UAC: REGISTER -> KAM: <- 200OK ```

Now I want to send an INVITE from Kam to UAC, for correct flow I would need to send it from Kam to LB:

`4.4.4.4:5060 -> 3.3.3.3:57482`

And LB would make the translation and send it to UAC:

`2.2.2.2:5060 -> 1.1.1.1:45621`

To be able to do this, I need a way to know that the connection came from `3.3.3.3:57482`. Does this make sense so far or am I fundamentally wrong?

RE: var naming --> I agree that $Ci and $Cp are more appropriate, I would also go with those. Thanks for suggestion!

RE: $Ri and $Rp --> I didn't _try_ these because according to docs they provide received _interface_ IP/Port, not received _source_ IP/Port.

Let me know what you think about this.

Thanks again! Joel.

-- 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/2103#issuecomment-543764153

Henning Westerholt

10:44 a.m.

Thanks for the explanation, I just wanted to understand the scenario. :-) So bascically you want to do it to keep the load balancer "in the path". Yes, the $Ri and $Rp should be (according your example) 4.4.4.4 and 5060.

About the feature request, I just had a quick look to the code. Probably it is necessary to extend the internal "sip_msg" structure for it, to add another receive_info struct and fill it in the core TCP path. Then the evaluation code could be added to the pv module.

Lets wait if other developers want to comment as well, as this would be a change with some more impact (sip_msg is used basically everywhere).

-- 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/2103#issuecomment-543779527

Joel Serrano

12:46 p.m.

Correct! The idea is to have a way to keep the LB "in the path", you got it!

Thanks @henningw, let me know if you need any other info, clarification, tests, or whatever :)

-- 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/2103#issuecomment-543830889

Emmanuel Schmidbauer

3:09 p.m.

i've noticed the proxy-proto feature breaks kamailio as a registrar. when `tcp_accept_haproxy=yes` and a REGISTER is received from the loadbalancer, IP and Port variables are changed to the UAC's IP and Port. the location data that is saved is then inaccurate. when user location lookup is called, it returns the IP:port of the UAC. this will not work since the phone expects the INVITE to come from the load-balancer's IP:Port (not kamailio's). the saved location data for the user should still be the load-balancer IP:port. I think the appropriate approach for proxy-proto is to *not* modify any existing IP and Port variables, but add new ones like @joelsdc suggested ($Ci, $Cp) id be willing to write a patch for this but want to make sure others agree.

-- 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/2103#issuecomment-543892746

Henning Westerholt

4:11 p.m.

@eschmidbauer IMHO the underlying issue is that there exists several ways how this proxy feature could be used. I will borrow some terms from IP LVS here to make it clear [link](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...).

The way I see it implemented in tcp_accept_haproxy is the "direct routing" type. This load balancer does not stay in the path, they hand-down the session to the real server(s). This usally works (at least in IPS) that the real server has a (non-arp) virtual IP address that it shares with the balancer. Therefore it can send the packet with the correct IP and port back directly to the user. The real server needs to get transparently get all the incoming IP and port information, and this is what the proxy protocol implementation in Kamailio is providing.

What Joel and also you are suggesting is another one, the "NAT Routing" type. Here the load balancer stays in the path and the real server uses a different IP address as the balancer. The real server is will be always behind the balancer.

I would suggest to keep the discussion in this feature request to the two additional PVs. If you want to discuss the "NAT routing" balancing type, please open a new issue or write an e-mail to sr-dev.

-- 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/2103#issuecomment-543919438

Daniel-Constantin Mierla

28 Oct 28 Oct

8:03 a.m.

Implemented in tcpops module -- see the commit referenced above.

If there is anything else to be discussed further, sr-users should be more appropriate as haproxy support is in stable branch and can get feedback from larger community.

-- 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/2103#issuecomment-546915807

Daniel-Constantin Mierla

8:03 a.m.

Closed #2103.

-- 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/2103#event-2748242278

Henning Westerholt

8:13 a.m.

Thanks Daniel - tcpops is a much better idea!

-- 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/2103#issuecomment-546919156

Joel Serrano

29 Oct 29 Oct

5:19 p.m.

Hi @miconda,

I believe something might not be working as expected...

I have added the following:

``` ... loadmodule "tcpops.so" ... tcp_accept_haproxy=yes ... xlog("L_NOTICE", "New request - M=$rm UAC-IP=$si:$sp LB-IP=$tcp(c_si):$tcp(c_sp) UA='$ua' ID=$ci\n"); ... ```

And this is what I see: ``` message":" NOTICE: {1 21 INVITE zgtu-ae~qO} <script>: New request - M=INVITE UAC-IP=104.175.176.242:37298 LB-IP=:0 UA='LinphoneIPhone/00346 (belle-sip/1.6.3)' ID=zgtu-ae~qO"} ``` Note the `LB-IP=:0`

Not related but probably caused by this ticket, I believe the documentation wasn't generated correctly:

https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables check right after `$msrp(srcsock)`

I cannot reopen the ticket myself, please let me know if you want me to create a new issue.

Thanks, Joel.

-- 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/2103#issuecomment-547634020

Joel Serrano

30 Oct 30 Oct

6:01 p.m.

Hi @miconda / @henningw , not sure if you get notifications when tickets are in closed state, please confirm, if not I'll open a new issue to check this.

The `$tcp(c_si)` and `$tcp(c_sp)` are not working as expected, see my previous comment for details.

-- 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/2103#issuecomment-548131406

Daniel-Constantin Mierla

31 Oct 31 Oct

4:13 a.m.

@joelsdc - try again with latest master, I just pushed a commit trying to fix it.

Notifications come also to sr-dev mailing list, even when issue is closed -- it is the place I usually check.

-- 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/2103#issuecomment-548258972

Joel Serrano

3:22 p.m.

Hi @miconda thanks for clarifying, now I know for next time :)

I just tested and now it works as expected:

``` "message":" NOTICE: {1 20 INVITE lR5kTpx06q} <script>: New request - M=INVITE UAC-IP=104.175.176.242:45334 LB-IP=35.191.9.16:62793 ```

Note the ---> `LB-IP=35.191.9.16:62793` <--- is the data we were missing!

Thanks again for implementing this :)

-- 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/2103#issuecomment-548530544

1959

Age (days ago)

1972

Last active (days ago)

sr-dev@lists.kamailio.org

13 comments

4 participants

tags (0)

participants (4)

Daniel-Constantin Mierla
Emmanuel Schmidbauer
Henning Westerholt
Joel Serrano