Re: [sr-dev] [kamailio/kamailio] Error when parsing P-Asserted-Identity use $ai variable (#2837)
Can you try with master branch or the patch from the commit referenced above? If works, then I will backport to 5.5 -- 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/2837#issuecomment-944364932___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
Closed #2865. -- 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/2865#event-5470148973___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
Pushed to master branch. Closing this issue. -- 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/2865#issuecomment-944340734___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:f0e8898d: core: parser - detect pai/ppi headers spanning many lines
Module: kamailio
Branch: master
Commit: f0e8898d83c54e5e4383b70ba54ad340c5ae13b6
URL:
https://github.com/kamailio/kamailio/commit/f0e8898d83c54e5e4383b70ba54ad340c5ae13b6
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2021-10-15T16:51:19+02:00
core: parser - detect pai/ppi headers spanning many lines
- GH #2837
---
Modified: src/core/parser/parse_ppi_pai.c
---
Diff:
https://github.com/kamailio/kamailio/commit/f0e8898d83c54e5e4383b70ba54ad340c5ae13b6.diff
Patch:
https://github.com/kamailio/kamailio/commit/f0e8898d83c54e5e4383b70ba54ad340c5ae13b6.patch
---
diff --git a/src/core/parser/parse_ppi_pai.c b/src/core/parser/parse_ppi_pai.c
index 4e4ebe392b..c60e33a9fd 100644
--- a/src/core/parser/parse_ppi_pai.c
+++ b/src/core/parser/parse_ppi_pai.c
@@ -65,6 +65,26 @@ int parse_pai_ppi_body(char *buf, int len, p_id_body_t
**body)
while ((*tmp == ',') && (num_uri < NUM_PAI_BODIES))
{
tmp++;
+ while(tmp=buf+len) {
+ LM_ERR("no content after comma when parsing PAI/PPI
body %u '%.*s'\n",
+ num_uri, len, buf);
+ return -1;
+ }
+ if((tmphttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:12ea639c: snmp: Update reply stats names
Module: kamailio
Branch: master
Commit: 12ea639c45db95e31c73d632822baa31df98c6a5
URL:
https://github.com/kamailio/kamailio/commit/12ea639c45db95e31c73d632822baa31df98c6a5
Author: Stefan Mititelu
Committer: Stefan Mititelu
Date: 2021-10-15T17:18:26+03:00
snmp: Update reply stats names
Solves issue #2865.
---
Modified: src/modules/snmpstats/snmpSIPCommonObjects.c
---
Diff:
https://github.com/kamailio/kamailio/commit/12ea639c45db95e31c73d632822baa31df98c6a5.diff
Patch:
https://github.com/kamailio/kamailio/commit/12ea639c45db95e31c73d632822baa31df98c6a5.patch
---
diff --git a/src/modules/snmpstats/snmpSIPCommonObjects.c
b/src/modules/snmpstats/snmpSIPCommonObjects.c
index 3ddf6465b1..4b7b668f54 100644
--- a/src/modules/snmpstats/snmpSIPCommonObjects.c
+++ b/src/modules/snmpstats/snmpSIPCommonObjects.c
@@ -298,8 +298,8 @@ int
handle_kamailioSIPSummaryOutResponses(netsnmp_mib_handler *handler,
*/
int fwd_replies = get_statistic("fwd_replies");
- int local_replies = get_statistic("local_replies");
- int relayed_replies = get_statistic("relayed_replies");
+ int local_replies = get_statistic("rpl_generated");
+ int relayed_replies = get_statistic("rpl_sent");
int sent_replies = get_statistic("sent_replies");
int result = fwd_replies + local_replies + relayed_replies +
sent_replies;
@@ -454,4 +454,4 @@ int handleSipEntityType(modparam_t type, void *val)
}
return 0;
-}
\ No newline at end of file
+}
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
> @Maratk1n please apply and try after this commit: > [c9ab251](https://github.com/kamailio/kamailio/commit/c9ab25196ddd3a9f84897571cf23ea70df1d9b1e) > > I am unable to set a snmp setup right now. > > Thank you, Stefan It solved the problem. Thanks! -- 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/2865#issuecomment-944149275___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] Proxy protocol issue
Hi Sergey, What Frederico talks about wouldn't lead to opening a new connection towards LB/HAproxy, instead Kamailio should find a connection by alias and re-use it. Frederico, I did not test with commenting the dst ip overwriting, in my tests I was trying to find a connection by using 0 for local_ip for calls originated from behind proxy protocol, it was working, but I'm not sure this is the best option here. I am wondering if there is anyone who actually uses proxy protocol in DSR scenarios? maybe really need to change it in order to make "sending msg back" working. On Fri, Oct 15, 2021 at 4:44 PM Sergey Safarov wrote: > Hi Federico > Here is also another issue here. > I do know how to HAproxy UDP messages but let talk about TCP/TLS > connections. > Imagine you know which socket ned to use to establish a new connection. > > But you are not able to do it. Because HAproxy do not provide the ability > to establish a connection from the backend server to the client. > So real socket knowled do not help you. This do work with HAproxy servers. > > What you can, establish a direct connection from Kamailio to the client > using a different socket with a different "advertise" keyword. > > You anyway need another socket. > Any socket that you want. > > Maybe you need anycast Kamailio installation? > > Sergey > > On Fri, Oct 15, 2021 at 2:27 PM Federico Cabiddu < > federico.cabi...@gmail.com> wrote: > >> Hi Arsen, >> the issue is exactly that kamailio behind HA LB DON'T reuse the same >> connection because there is no tcp alias for CLIENT_IP/LOCAL_KAMAILIO_IP, >> because the kamailio local socket has been overwritten by the balancer IP. >> I've read the specification and nowhere is written that the load balancer >> IP must overwrite the local socket information. With the actual >> implementation it is impossible to send back a message (not a reply, a >> brand new one) to the client, because there is no matching tcp alias (I've >> done a quite deep debug). Proxy protocol was mainly taught for >> unidirectional flows (http), not for SIP. IMHO it is useless , if not >> dangerous, that the local socket is rewritten with an IP that doesn't >> belong to kamailio. Commenting the dst ip overwriting makes kamailio create >> the correct alias for the tcp connection and reuse it to send, in example, >> a BYE message from the callee to the caller. >> >> Cheers, >> >> Federico >> >> On Fri, Oct 15, 2021 at 12:40 PM Arsen Semenov >> wrote: >> >>> Hi Federico, >>> >>> I was facing the same issues when I was playing with the proxy protocol >>> some time ago. >>> As per my understanding the way how proxy protocol(PP) is implemented in >>> Kamailio is outlined in the de-facto standard doc: >>> https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt >>> >>> " >>> The PROXY protocol's goal is to fill the server's internal structures >>> with the >>> information collected by the proxy that the server would have been able >>> to get >>> by itself if the client was connecting directly to the server instead of >>> via a >>> proxy. The information carried by the protocol are the ones the server >>> would >>> get using getsockname() and getpeername() : >>> - address family (AF_INET for IPv4, AF_INET6 for IPv6, AF_UNIX) >>> - socket protocol (SOCK_STREAM for TCP, SOCK_DGRAM for UDP) >>> - layer 3 source and destination addresses >>> - layer 4 source and destination ports if any >>> " >>> >>> So that internally Kamailio will have info of Client >>> source_ip:source_port/LB_external_IP:LB_external_port >>> You can confirm that by executing core.tcp_list command. >>> >>> For a call initiated by a client behind LB with proxy protocol, >>> responses will re-use existing TCP connection and will reach the client. >>> But for example if the call will be terminated from the callee side, (i.e >>> new transaction) Kamailio will fail to find existing TCP connection since >>> it does not know nothing about it and will try to open a new one, which, in >>> turn will fail either because of LB reject - if so_useport is disabled, or >>> if so_reuseport=yes because of the fact that in the OS there is already >>> opened TCP connection with the same tuple (ie. between LB and Kamailio >>> host) >>> So the way to use proxy protocol in Kamailio is DSR (direct server >>> return) scenarios. >>> >>> here you can find related conversation: >>> https://github.com/kamailio/kamailio/issues/2103 >>> >>> >>> Regards, >>> >>> On Fri, Oct 15, 2021 at 2:43 PM Federico Cabiddu < >>> federico.cabi...@gmail.com> wrote: >>> Hi all, I've been recently testing kamailio support for proxy protocol which was introduced by https://github.com/kamailio/kamailio/issues/1757. As reported by others, even if kamailio is able to decode the proxy protocol and get the client's original IP address, it is unable to send SIP messages to the client which initiated the connection through the HA load balancer (nginx in my case). After investigation
Re: [sr-dev] Proxy protocol issue
Hi Federico Here is also another issue here. I do know how to HAproxy UDP messages but let talk about TCP/TLS connections. Imagine you know which socket ned to use to establish a new connection. But you are not able to do it. Because HAproxy do not provide the ability to establish a connection from the backend server to the client. So real socket knowled do not help you. This do work with HAproxy servers. What you can, establish a direct connection from Kamailio to the client using a different socket with a different "advertise" keyword. You anyway need another socket. Any socket that you want. Maybe you need anycast Kamailio installation? Sergey On Fri, Oct 15, 2021 at 2:27 PM Federico Cabiddu wrote: > Hi Arsen, > the issue is exactly that kamailio behind HA LB DON'T reuse the same > connection because there is no tcp alias for CLIENT_IP/LOCAL_KAMAILIO_IP, > because the kamailio local socket has been overwritten by the balancer IP. > I've read the specification and nowhere is written that the load balancer > IP must overwrite the local socket information. With the actual > implementation it is impossible to send back a message (not a reply, a > brand new one) to the client, because there is no matching tcp alias (I've > done a quite deep debug). Proxy protocol was mainly taught for > unidirectional flows (http), not for SIP. IMHO it is useless , if not > dangerous, that the local socket is rewritten with an IP that doesn't > belong to kamailio. Commenting the dst ip overwriting makes kamailio create > the correct alias for the tcp connection and reuse it to send, in example, > a BYE message from the callee to the caller. > > Cheers, > > Federico > > On Fri, Oct 15, 2021 at 12:40 PM Arsen Semenov > wrote: > >> Hi Federico, >> >> I was facing the same issues when I was playing with the proxy protocol >> some time ago. >> As per my understanding the way how proxy protocol(PP) is implemented in >> Kamailio is outlined in the de-facto standard doc: >> https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt >> >> " >> The PROXY protocol's goal is to fill the server's internal structures >> with the >> information collected by the proxy that the server would have been able >> to get >> by itself if the client was connecting directly to the server instead of >> via a >> proxy. The information carried by the protocol are the ones the server >> would >> get using getsockname() and getpeername() : >> - address family (AF_INET for IPv4, AF_INET6 for IPv6, AF_UNIX) >> - socket protocol (SOCK_STREAM for TCP, SOCK_DGRAM for UDP) >> - layer 3 source and destination addresses >> - layer 4 source and destination ports if any >> " >> >> So that internally Kamailio will have info of Client >> source_ip:source_port/LB_external_IP:LB_external_port >> You can confirm that by executing core.tcp_list command. >> >> For a call initiated by a client behind LB with proxy protocol, responses >> will re-use existing TCP connection and will reach the client. But for >> example if the call will be terminated from the callee side, (i.e new >> transaction) Kamailio will fail to find existing TCP connection since it >> does not know nothing about it and will try to open a new one, which, in >> turn will fail either because of LB reject - if so_useport is disabled, or >> if so_reuseport=yes because of the fact that in the OS there is already >> opened TCP connection with the same tuple (ie. between LB and Kamailio >> host) >> So the way to use proxy protocol in Kamailio is DSR (direct server >> return) scenarios. >> >> here you can find related conversation: >> https://github.com/kamailio/kamailio/issues/2103 >> >> >> Regards, >> >> On Fri, Oct 15, 2021 at 2:43 PM Federico Cabiddu < >> federico.cabi...@gmail.com> wrote: >> >>> Hi all, >>> I've been recently testing kamailio support for proxy protocol which was >>> introduced by https://github.com/kamailio/kamailio/issues/1757. As >>> reported by others, even if kamailio is able to decode the proxy protocol >>> and get the client's original IP address, it is unable to send SIP messages >>> to the client which initiated the connection through the HA load balancer >>> (nginx in my case). After investigation I've found that there is no alias >>> added to the tcp connection aliases list for the tuple >>> CLIENT_IP:CLIENT_PORT/LOCAL_KAMAILIO_IP:KAMAILIO_PORT. This means that when >>> trying to forward a message to the originating client kamailio won't use >>> the existing connection with the load balancer/proxy but will try to >>> establish a new connection. The fact is that the function which parses the >>> proxy header overwrites the dst ip/port of the connection with the >>> "Destination IP" and "Destination Port" fields of the proxy header ( >>> https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L989 >>> for v2, >>> https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L10
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
@Maratk1n please apply and try after this commit: c9ab25196ddd3a9f84897571cf23ea70df1d9b1e I am unable to set a snmp setup right now. --- Thank you, Stefan -- 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/2865#issuecomment-944067658___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] Proxy protocol issue
Hi Arsen, the issue is exactly that kamailio behind HA LB DON'T reuse the same connection because there is no tcp alias for CLIENT_IP/LOCAL_KAMAILIO_IP, because the kamailio local socket has been overwritten by the balancer IP. I've read the specification and nowhere is written that the load balancer IP must overwrite the local socket information. With the actual implementation it is impossible to send back a message (not a reply, a brand new one) to the client, because there is no matching tcp alias (I've done a quite deep debug). Proxy protocol was mainly taught for unidirectional flows (http), not for SIP. IMHO it is useless , if not dangerous, that the local socket is rewritten with an IP that doesn't belong to kamailio. Commenting the dst ip overwriting makes kamailio create the correct alias for the tcp connection and reuse it to send, in example, a BYE message from the callee to the caller. Cheers, Federico On Fri, Oct 15, 2021 at 12:40 PM Arsen Semenov wrote: > Hi Federico, > > I was facing the same issues when I was playing with the proxy protocol > some time ago. > As per my understanding the way how proxy protocol(PP) is implemented in > Kamailio is outlined in the de-facto standard doc: > https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt > > " > The PROXY protocol's goal is to fill the server's internal structures with > the > information collected by the proxy that the server would have been able to > get > by itself if the client was connecting directly to the server instead of > via a > proxy. The information carried by the protocol are the ones the server > would > get using getsockname() and getpeername() : > - address family (AF_INET for IPv4, AF_INET6 for IPv6, AF_UNIX) > - socket protocol (SOCK_STREAM for TCP, SOCK_DGRAM for UDP) > - layer 3 source and destination addresses > - layer 4 source and destination ports if any > " > > So that internally Kamailio will have info of Client > source_ip:source_port/LB_external_IP:LB_external_port > You can confirm that by executing core.tcp_list command. > > For a call initiated by a client behind LB with proxy protocol, responses > will re-use existing TCP connection and will reach the client. But for > example if the call will be terminated from the callee side, (i.e new > transaction) Kamailio will fail to find existing TCP connection since it > does not know nothing about it and will try to open a new one, which, in > turn will fail either because of LB reject - if so_useport is disabled, or > if so_reuseport=yes because of the fact that in the OS there is already > opened TCP connection with the same tuple (ie. between LB and Kamailio > host) > So the way to use proxy protocol in Kamailio is DSR (direct server return) > scenarios. > > here you can find related conversation: > https://github.com/kamailio/kamailio/issues/2103 > > > Regards, > > On Fri, Oct 15, 2021 at 2:43 PM Federico Cabiddu < > federico.cabi...@gmail.com> wrote: > >> Hi all, >> I've been recently testing kamailio support for proxy protocol which was >> introduced by https://github.com/kamailio/kamailio/issues/1757. As >> reported by others, even if kamailio is able to decode the proxy protocol >> and get the client's original IP address, it is unable to send SIP messages >> to the client which initiated the connection through the HA load balancer >> (nginx in my case). After investigation I've found that there is no alias >> added to the tcp connection aliases list for the tuple >> CLIENT_IP:CLIENT_PORT/LOCAL_KAMAILIO_IP:KAMAILIO_PORT. This means that when >> trying to forward a message to the originating client kamailio won't use >> the existing connection with the load balancer/proxy but will try to >> establish a new connection. The fact is that the function which parses the >> proxy header overwrites the dst ip/port of the connection with the >> "Destination IP" and "Destination Port" fields of the proxy header ( >> https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L989 >> for v2, >> https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L1071 >> for v1). This fields contain the IP/port of the Load Balancer, not the >> kamailio IP/Port, and kamailio will fail to find a tcp connection toward >> the client's src IP since the Load Balancer IP is not a kamailio's local >> socket. >> I think that the destination IP of the connection shouldn't be rewritten >> with the load balancer IP, unless I'm missing something. >> Hopefully I've been clear enough explaining the issue :) >> If you agree with the analysis I can prepare a PR for it. >> >> Have you all a great weekend, >> >> Federico Cabiddu >> >> ___ >> Kamailio (SER) - Development Mailing List >> sr-dev@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> > > > -- > Arsen Semenov > > ___
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
So the snmpstats module needs to be adapted to the new naming. -- 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/2865#issuecomment-944053341___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] snmpstats: get_statistic(): failed to retrieve statistics for local_replies (#2865)
Hi, I found this commit I did back then: 6e9f017dd3509296b83f12d3467309c583a248b1. Basically I renamed all replies related stats to start with rpl_*, for more consistency. So the re-naming changes were: - ```received_replies``` renamed to ```rpl_received``` - ```relayed_locally``` renamed to ```rpl_generated``` - ```relayed_total``` renamed to ```rpl_sent``` To get a list of all the tmx counters use: ```kamcmd cnt.list_vars tmx```. --- Hope this helps, Stefan -- 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/2865#issuecomment-944041011___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] Proxy protocol issue
Hi Federico, I was facing the same issues when I was playing with the proxy protocol some time ago. As per my understanding the way how proxy protocol(PP) is implemented in Kamailio is outlined in the de-facto standard doc: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt " The PROXY protocol's goal is to fill the server's internal structures with the information collected by the proxy that the server would have been able to get by itself if the client was connecting directly to the server instead of via a proxy. The information carried by the protocol are the ones the server would get using getsockname() and getpeername() : - address family (AF_INET for IPv4, AF_INET6 for IPv6, AF_UNIX) - socket protocol (SOCK_STREAM for TCP, SOCK_DGRAM for UDP) - layer 3 source and destination addresses - layer 4 source and destination ports if any " So that internally Kamailio will have info of Client source_ip:source_port/LB_external_IP:LB_external_port You can confirm that by executing core.tcp_list command. For a call initiated by a client behind LB with proxy protocol, responses will re-use existing TCP connection and will reach the client. But for example if the call will be terminated from the callee side, (i.e new transaction) Kamailio will fail to find existing TCP connection since it does not know nothing about it and will try to open a new one, which, in turn will fail either because of LB reject - if so_useport is disabled, or if so_reuseport=yes because of the fact that in the OS there is already opened TCP connection with the same tuple (ie. between LB and Kamailio host) So the way to use proxy protocol in Kamailio is DSR (direct server return) scenarios. here you can find related conversation: https://github.com/kamailio/kamailio/issues/2103 Regards, On Fri, Oct 15, 2021 at 2:43 PM Federico Cabiddu wrote: > Hi all, > I've been recently testing kamailio support for proxy protocol which was > introduced by https://github.com/kamailio/kamailio/issues/1757. As > reported by others, even if kamailio is able to decode the proxy protocol > and get the client's original IP address, it is unable to send SIP messages > to the client which initiated the connection through the HA load balancer > (nginx in my case). After investigation I've found that there is no alias > added to the tcp connection aliases list for the tuple > CLIENT_IP:CLIENT_PORT/LOCAL_KAMAILIO_IP:KAMAILIO_PORT. This means that when > trying to forward a message to the originating client kamailio won't use > the existing connection with the load balancer/proxy but will try to > establish a new connection. The fact is that the function which parses the > proxy header overwrites the dst ip/port of the connection with the > "Destination IP" and "Destination Port" fields of the proxy header ( > https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L989 > for v2, > https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L1071 > for v1). This fields contain the IP/port of the Load Balancer, not the > kamailio IP/Port, and kamailio will fail to find a tcp connection toward > the client's src IP since the Load Balancer IP is not a kamailio's local > socket. > I think that the destination IP of the connection shouldn't be rewritten > with the load balancer IP, unless I'm missing something. > Hopefully I've been clear enough explaining the issue :) > If you agree with the analysis I can prepare a PR for it. > > Have you all a great weekend, > > Federico Cabiddu > > ___ > Kamailio (SER) - Development Mailing List > sr-dev@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev > -- Arsen Semenov ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] Proxy protocol issue
Hi all, I've been recently testing kamailio support for proxy protocol which was introduced by https://github.com/kamailio/kamailio/issues/1757. As reported by others, even if kamailio is able to decode the proxy protocol and get the client's original IP address, it is unable to send SIP messages to the client which initiated the connection through the HA load balancer (nginx in my case). After investigation I've found that there is no alias added to the tcp connection aliases list for the tuple CLIENT_IP:CLIENT_PORT/LOCAL_KAMAILIO_IP:KAMAILIO_PORT. This means that when trying to forward a message to the originating client kamailio won't use the existing connection with the load balancer/proxy but will try to establish a new connection. The fact is that the function which parses the proxy header overwrites the dst ip/port of the connection with the "Destination IP" and "Destination Port" fields of the proxy header ( https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L989 for v2, https://github.com/kamailio/kamailio/blob/f677dea597db6ceaa66a2755dd6e9e738855dc35/src/core/tcp_main.c#L1071 for v1). This fields contain the IP/port of the Load Balancer, not the kamailio IP/Port, and kamailio will fail to find a tcp connection toward the client's src IP since the Load Balancer IP is not a kamailio's local socket. I think that the destination IP of the connection shouldn't be rewritten with the load balancer IP, unless I'm missing something. Hopefully I've been clear enough explaining the issue :) If you agree with the analysis I can prepare a PR for it. Have you all a great weekend, Federico Cabiddu ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
