[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 codyherzog at gmail.com
Fri Jan 22 02:40:05 CET 2016


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 <miconda at 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 <
> <miconda at gmail.com>miconda at 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-users at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160121/81a21bef/attachment.html>


More information about the sr-users mailing list