Thanks for the ongoing support. I tried 'tcp.new_conn_alias_flags = 1' in the global config section, but that causes a config file parse error on startup.
I have also tried the following: 'tcp_new_conn_alias_flags = 1' <== parse error 'tcp_options.new_conn_alias_flags=1' <== NO parse error, but doesn't seem to change the option. The only way I've found to change the option is at runtime as follows: sudo kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1 Thanks. On Tue, Jan 19, 2016 at 2:48 PM, Daniel-Constantin Mierla <mico...@gmail.com > wrote: > Hello, > > I am not the developer that added the new_conn_alias_flags and had not > time to dig much in the code to given an precise answer. But if it make the > case you detailed to work, then set it. In its definition in the code i saw > it can be 0, 1 or 2. > > Try to see if it works to set it in kamailio.cfg with: > > tcp.new_conn_alias_flags = 1 > > Use it in the part with global parameters. > > Cheers, > Daniel > > > On 19/01/16 19:16, Cody Herzog wrote: > > Hello. > > Thanks for the quick reply. > > The internal ports were different in the testing I was doing. Client A was > using 5061 as the local TCP port for the persistent TLS connection for SIP > signalling. Client B was using ephemeral high TCP ports for the brief test > connections. > > The best way to reproduce the problem is to configure iptables for SNAT > with a very small port range. Here are the iptables commands I used for my > test. Notice I use a range of only 100 ports. 192.168.128.151 is the IP > address of the NAT box, which is running Ubuntu server 14.04. > > sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT > sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate > RELATED,ESTABLISHED -j ACCEPT > sudo iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to > 192.168.128.151:6000-6099 > sudo iptables -t nat -A POSTROUTING -p udp -o eth0 -j SNAT --to > 192.168.128.151:6000-6099 > sudo iptables -t nat -A POSTROUTING -p icmp -o eth0 -j SNAT --to > 192.168.128.151 > > I believe that iptables doesn't mind reusing the same external IP:port, so > long as the external destination server IP or port is different. It must > maintain enough state to route the responses back to the correct internal > target by examining the external server IP and port. > > Do you agree that setting 'new_conn_alias_flags = 1' seems like a > reasonable way to address this issue? > > If so, then we will likely make a local modification to 'cfg.y' so that we > can set that option in the config file. Currently, it seems that it can > only be set at runtime. > > Is it planned to make ''new_conn_alias_flags' available in the config file? > > Thanks. > > On Mon, Jan 18, 2016 at 11:24 PM, Daniel-Constantin Mierla < > <mico...@gmail.com>mico...@gmail.com> wrote: > >> 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 >> >> 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. >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - >> http://www.linkedin.com/in/miconda >> Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu >> >> > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > Book: SIP Routing With Kamailio - http://www.asipto.comhttp://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
