The ebuild currently determines whether CONFIG_NF_CONNTRACK_SIP is enabled and, if it is, presents the following information: "SIP (NAT) connection tracking is a module written for a single SIP client talking to a remote server. It is not able to track multiple remote SIP clients registering with a local server. Critical SIP packets may be dropped." My testing has indicated that this claim is inaccurate. The SIP service in my asterisk installation is bound to an interface where all inbound packets are dropped by default. This interface is directly Internet connected - no NAT, no RFC 1918 addresses. For a SIP connection and its associated traffic to be successfully initiated by a remote SIP client, I use the following rules (shown as iptables parameters): -A in_sip -p udp -m udp --sport 5060 --dport 5060 -m state --state NEW,ESTABLISHED -j ACCEPT -A in_sip -p udp -m udp --sport 1024:65535 --dport 5060 -m state --state NEW,ESTABLISHED -j ACCEPT -A in_sip -m state --state RELATED,ESTABLISHED -m helper --helper "sip" -j ACCEPT Naturally, traffic is directed to this table as part of the INPUT chain. I have used such a setup for quite some time and found that: * All remote SIP clients are able to function correctly and without issue (with calls being fielded correctly in both directions and no audio issues) * Upstream SIP service providers may be utilised without issue However, if I disable the NF_CONNTRACK_SIP helper module, my remote SIP clients are unable to function correctly. This is typically manifested by an inability to hear audio, irrespective of in which direction the call is initiated. Conversely, once the module is made available again, all is well. Of course, where the module is disabled, the call to iptables to add the third of the above mentioned rules fails during initialisation. Aside from this, there are no variables and this behaviour is reproducible. This seems to conclusively demonstrate that the rule which employs the assistance of the SIP helper module is integral to ensuring that RTP traffic associated with a valid SIP session is handled correctly. Moreover, in my case, it is specifically required to facilitate the correct operation of multiple remote SIP clients where the input chain otherwise has a default policy of DROP/REJECT and appears to do a perfectly good job of it.
This was added based on comments from Jaco Kroon in bug #300644, linked for your convenience. I have CC'd him on the bug and am awaiting his response.
Thanks, I'd never seen bug 300644. One thing I would say is that, while there may well be bugs in the implementation (*), it doesn't seem appropriate to suggest that it is intrinsically incapable of tracking multiple remote SIP clients. That is how I interpreted it and, after being duly alarmed and disabling the module, things didn't work so well for me ;) I'll wait for Jaco to chime in also but, assuming that his wisdom prevails, it's perhaps just a matter of wording it a little more carefully. * I would not be inclined to doubt Jaco's word, and would assume that he has subjected it to far more trying conditions
Kerframil, the exact issue I had may have been solved in the meantime. My limited testing however has shown that the tracking module drops certain packets for no apparent reason. I could literally sit with tcpdump and asterisk sip debug open on the same box, and tcpdump would see the incoming sip packets, asterisk would not. As soon as I disabled that module it worked as expected. I can probably go dig up the pcap files again, but those by themselves doesn't really prove anything. A quick perusal of the nf_conntrack_sip.c code though still show statements like: if (port < 1024 || port > 65535) return NF_DROP; This seems to drop SIP packets that wants an rtp port in the privileged range. This is a tracking module - it shouldn't be dropping any packets I reckon, merely scanning the traffic passively and adding expects for recognized rtp traffic. This code worries me the most (again, I haven't done any in-depth checking): if (ct_sip_parse_sdp_addr(ct, *dptr, mediaoff, *datalen, c_hdr, SDP_HDR_MEDIA, &matchoff, &matchlen, &maddr) > 0) { maddr_len = matchlen; memcpy(&rtp_addr, &maddr, sizeof(rtp_addr)); } else if (caddr_len) memcpy(&rtp_addr, &caddr, sizeof(rtp_addr)); else return NF_DROP; Now, what happens if ct_sip_parse_sdp_addr fails and caddr_len hasn't been initialized from just before the media types loop? In fact, it's this block that I suspect was causing my problems. It loops through all the media types etc etc ... and then proceeds to DROP certain (unparsable?) packets. My opinion (yes, it's not a fact, it's merely my opinion) is that this code should never drop packets. It's supposed to be purely a tracking module, adding expects for RTP traffic as required. A bit more is required for NAT (ie, possibly modifying port numbers in the SIP packets and setting up expects, but never, ever ever should this module DROP SIP traffic). The code is from a slightly older 2.6.33-rc5 kernel. Most SIP servers is also seem to be smart enough to deal with NAT even without this. In particular I've seen totally braindead NAT devices that does not deal with SIP and asterisk deals with it just fine (so far). However, I've seen ultra smart SIP routers that just throws away packets (one particular recent case was a D-Link router that discarded the ACK packet sent from behind the router to my server in response to my OK, resulting in a perfect call for ... ~30 seconds before the call got dropped by asterisk due to no response to our critical packet). It's these exact same kinds of problems I've seen with the linux tracking module at that time. If you do enable the module you should examine your logs (dmesg) very carefully for messages regarding the module dropping packets. The NF core moans about tracking modules that DROP packets. I would dearly like to have this module work properly, but as it stands at the moment I cannot risk using it. Improved wording in the warning may well be appropriate. The cases that I have seen it do weird things: * Dropping REGISTER packets. * Dropping a secondary INVITE (sequence was something like: INVITE, reject with auth, INVITE accepted, call closed, deregister, register, INVITE <-- dropped, this one should still be in my mail somewhere). * Dropping ACKs. I hope this helps. Also note that I do like the concept of the module, and what it's supposed to do. It's just that my experience dictates that I rather disable it. Disabling it also solved a few weird problems I've had at some of my clients, which I simply haven't bothered tracking. The time at which I had issues with this was quite a hectic stage of ULS's existence. I would like to revisit (and "fix") the code if possible. Building test cases is difficult though.
Kerin, thank you for your report. I have toned this warning down as follows: local WARNING_NF_CONNTRACK_SIP="SIP (NAT) connection tracking is enabled. Some users have reported that this module dropped critical SIP packets in their deployments. You may want to disable it if you see such problems." This is in the 1.6.2.9 ebuild.
Thanks all. Comment 3 is through-provoking; it also strikes me as odd that a connection tracking module should take matters into its own hands with respect to dropping traffic. My understanding is that the helper either matches a packet or it does not, whereupon it is up to the user to decide what the fate of the packet should be by way of additional rules or table policy. In light of all that has been said, I'll endeavour to keep a more watchful eye on the behaviour of this module henceforth.
