nf_conntrack and the conntrack program

September 14, 2008

Today I had a problem with my VoIP connection to my provider. The hardware SIP client did not connect for some hours. I had a look at the packets which went over my router into the internet. At the first glance it looked as everything worked right on my side, but the other side did not answer.


15:04:46.131077 IP xxx.xxx.xxx.xxx.5061 > yyy.yyy.yyy.yyy.5060: SIP, length: 532
15:04:47.147701 IP xxx.xxx.xxx.xxx.5061 > yyy.yyy.yyy.yyy.5060: SIP, length: 335
15:04:50.130068 IP xxx.xxx.xxx.xxx.5061 > yyy.yyy.yyy.yyy.5060: SIP, length: 532
15:04:51.147168 IP xxx.xxx.xxx.xxx.5061 > yyy.yyy.yyy.yyy.5060: SIP, length: 335

But at a closer look i realized that the xxx.xxx.xxx.xxx IP address was not my current IP address, given by the DSL provider, but one from an older ppp session with my provider. It was at once clear that there must be a problem with the connection tracking of IPtables, as the SIP client used an internal IP address and gets masqueraded by the router. If you want to know more about IPtables and connection tracking take a look at this.

Anyway I did at a fast cat /proc/net/nf_conntrack | grep 5060 to get all connection tracking entries for SIP. And I found more than one, here is on example.


ipv4 2 udp 17 172 src=10.xxx.xxx.xxx dst=yyy.yyy.yyy.yyy sport=5061 dport=5060 packets=1535636 bytes=802474523 src=yyy.yyy.yyy.yyy dst=xxx.xxx.xxx.xxx sport=5060 dport=5061 packets=284 bytes=114454 [ASSURED] mark=0 secmark=0 use=1

The timeout for this entry is 180 sec and 172 seconds to go, and the SIP client was all the time sending new probes and therefore the connection was never dropped. What can you do in this instance? You can install conntrack. It is a userspace command line program targeted at system administrators. It enables you to view and manage the in-kernel connection tracking state table. If you want to take a look at the manual without installing it (apt-get install conntrack) you can take a look at this webpage which contains the man page. With this program I did delete the entries with the wrong IP address and everything worked again.

I think this program and the knowledge of the connection tracking is important for many of my readers, so I’ve written this post. The current cause to talk about this topic is only one of many, so take a look at it.

2 Comments »

RSS feed for comments on this post. TrackBack URI

  1. I think I have hit the same problem.

    tcpdump -i $uplink_if shows that packets are being sent with source IP address from out private network(!).

    The wrong ip_conntrack entry is

    udp 17 29 src=10.7.5.1 dst=195.197.95.4 sport=5060 dport=5060 packets=18609 bytes=11966056 [UNREPLIED] src=195.197.95.4 dst=10.7.5.1 sport=5060 dport=5060 packets=0 bytes=0 mark=0 secmark=0 use=1

    while the correct one is

    udp 17 178 src=10.7.5.1 dst=195.197.95.4 sport=5060 dport=5060 packets=80 bytes=43264 src=195.197.95.4 dst=193.166.XXX.XXX sport=5060 dport=5060 packets=80 bytes=36517 [ASSURED] mark=0 secmark=0 use=1

    I can recover by stopping asterisk for a while so that the entry expires. I am however unable to remove it with conntrack. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496769 for more info on that.

    If you want to reply to this message, please mail [email protected]

    Comment by Timo Juhani Lindfors — August 13, 2009 #

  2. I did take a look at your bug report. It was long ago when I with the program. But did you try to flush the whole conntrack?

    conntrack -F

    does that work? and take a look at

    http://muchtall.com/2008/11/12/5/

    Comment by robert — August 26, 2009 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 37 queries. 0.077 seconds.