[SR-Users] Is "new_conn_alias_flags" supported/recommended? It seems to solve my NAT problem, but I'm worried it's not safe.

[Cody Herzog]

Hello.



In a test environment, I've been able to use the "new_conn_alias_flags"
option to solve a NAT problem, but I'm concerned that the option is not
supported/safe.



It seems the option is not documented, and cannot be used in the config
file, because 'cfg.y' doesn't support parsing it. However, it can be set at
runtime using a command such as the following:



kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1



**Question #1**



Is this option experimental and/or risky?



As background, I will now try to describe my NAT problem. Perhaps there is
an alternate way to solve my problem which doesn't require using
"new_conn_alias_flags".



My server architecture uses multiple Kamailio edge proxies, and a single
central Kamailio registrar. The edge proxies listen on multiple TLS ports.
All servers are on version 4.3.3.


My client app includes a port tester, which periodically tests whether
certain SIP proxy targets are reachable. These test connections are very
brief, and don’t persist.



The problem seems to relate to a behavior of iptables as follows:



Client A and client B are both behind the same iptables NAT.



Client A has a persistent TLS connection to one of the proxies.



Client B is doing periodic port testing, and sometimes, the itpables NAT
will assign exactly the same external IP and port for a test connection as
is already being used by client A for its persistent connection, to the
same SIP proxy IP. Only the SIP proxy target port is different.



To better explain, I will list out examples for all the relevant IPs and
ports along the paths. The IPs and ports I've selected are arbitrary.



Client A persistent TLS connection

----------------------------------

Internal IP:Port = 10.10.10.100:30000

External IP:Port = 88.88.88.88:10000

SIP proxy IP:Port = 66.66.66.66:5061



Client B port test connection

------------------------------

Internal IP:Port = 10.10.10.101:35000

External IP:Port = 88.88.88.88:10000 *** Same as above!

SIP proxy IP:Port = 66.66.66.66:443 *** SIP proxy port being different is
the only thing that makes this a distinct TCP connection from above.



When this happens, it seems that some of the TCP connection/alias hash
tables inside Kamailio are modified such that future attempts to call
client A may fail. Client B's port test connection seems to overwrite some
of the state which was important for connections into Client A. After
client B's test connection has stomped on client A's state, this is what
happens:


When an INVITE sent to client A arrives at the proxy, the proxy fails to
find the matching persistent TLS connection which already exists, so it
tries to open a new outbound TLS connection to client A, but that always
fails because client A's NAT doesn't allow it. Such calls end up failing
with a 408 timeout error.



I added some extra logging to the TCP connection/alias hash code paths, and
I can see some of the client A entries being overwritten when client B
makes its test connection.



Did I explain that well enough? I know it's a bit confusing.



Anyway, after doing some code inspection, I noticed that the
"new_conn_alias_flags" option seemed like it might improve this problem, or
at least change the behavior. It turns out that setting
"new_conn_alias_flags" equal to 1 seems to solve my problem. With that
setting, client B's test connections do not overwrite any of the TCP
connection hashes/aliases for client A's persistent TLS connection, and
calls into client A never seem to fail.



**Question #2**



Does setting "new_conn_alias_flags" to 1 seem like a good way to address my
type of problem? If not, is there an alternate way to solve my problem?
Perhaps there are some things I should be doing with the NAT helper module
that could fix the issue without relying on "new_conn_alias_flags"?



I realize that I may need to provide more information to answer these
questions fully, but I’m initially hoping to just get some high-level
impressions, without going into a ton of details.



Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160118/029896eb/attachment.html>