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

[Daniel-Constantin Mierla]

Hello,

interesting to see a case when the same ip:port is given by the firewall
for the source of a connection.

I haven't gone to the code to track the new_conn_alias_flags, but if
tests don't reveal any issue, then all should be good.

Are the internal ports for the A and B different, or both use the same
(5060/5061)?

Cheers,
Daniel

On 18/01/16 19:55, Cody Herzog wrote:
>
> 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 <http://10.10.10.100:30000>
>
> External IP:Port = 88.88.88.88:10000 <http://88.88.88.88:10000>
>
> SIP proxy IP:Port = 66.66.66.66:5061 <http://66.66.66.66:5061>
>
>  
>
> Client B port test connection
>
> ------------------------------
>
> Internal IP:Port = 10.10.10.101:35000 <http://10.10.10.101:35000>
>
> External IP:Port = 88.88.88.88:10000 <http://88.88.88.88:10000> ***
> Same as above!
>
> SIP proxy IP:Port = 66.66.66.66:443 <http://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.
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160119/23528ecb/attachment.html>