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@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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
