[kamailio/kamailio] [Feature Request]: Add **connection** IP and Port vars (specifically for tcp_accept_haproxy=yes) (#2103)
18 Oct
2019
18 Oct
'19
3:27 a.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
18 Oct
18 Oct
12:12 p.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
5:08 p.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
5:44 p.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
7: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
10: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
11: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_linu….
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
28 Oct
28 Oct
3:03 p.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
3:03 p.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
3:13 p.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
30 Oct
30 Oct
12:19 a.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
31 Oct
31 Oct
1:01 a.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
11: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
10: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
1852
days inactive
1865
days old
13 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Emmanuel Schmidbauer
-
Henning Westerholt
-
Joel Serrano