connection tracking fails to update udp timer

connection tracking fails to update udp timer

[Eray Bilgin]

i noticed this when my voip phone mysteriously stopped ringing. i use
a tp-link router as a gateway which i'm certain is running
linux/netfilters, though i don't know what version. i've observed the
same problem on my raspberry pi running iptables v1.8.2.

usually the first thing a sip client does is register with the provider's
server. this has the effect of punching a hole through any firewalls in
its path. after that initial registration, my provider keeps the
connection alive by sending messages every 60 seconds.

when netfilters sees traffic moving back and forth, the connection should
transition to the assured state and set the expiration timer to
nf_conntrack_udp_timeout_stream, which by default is 120 seconds. but in
this case the timer is reset to nf_conntrack_udp_timeout, which is 30
seconds. the connection does not appear as "assured".

pi@zawardo:~ $ sudo conntrack -L | grep 5060
conntrack v1.4.5 (conntrack-tools): 26 flow entries have been shown.
udp      17 3 src=x.x.53.184.sip dst=x.x.126.73 sport=5060 dport=5060
src=x.x.126.73 dst=x.x.53.184 sport=5060 dport=5060 mark=0 use=1

this means that the connection is already expired before the first
keep-alive arrives. if the router is using nat or filtering new connections
then the messages bounce back until the client opens a new connection
from inside.

pi@zawardo:~ $ sudo tcpdump -i ppp0 udp port 5060 or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:28:46.010042 IP x.x.53.184.sip > sip.example.com.sip: SIP: REGISTER sip:sip.example.com:5060 SIP/2.0
16:28:46.018303 IP sip.example.com.sip > x.x.53.184.sip: SIP: SIP/2.0 401 Unauthorized
16:28:46.021205 IP x.x.53.184.sip > sip.example.com.sip: SIP: REGISTER sip:sip.example.com:5060 SIP/2.0
16:28:46.030034 IP sip.example.com.sip > x.x.53.184.sip: SIP: SIP/2.0 200 OK
16:28:46.031020 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0
16:28:46.031326 IP sip.example.com.sip > x.x.53.184.sip: SIP: NOTIFY sip:zawardo@x.x.53.184:5060 SIP/2.0
16:28:46.034408 IP x.x.53.184.sip > sip.example.com.sip: SIP: PUBLISH sip:zawardo@sip.example.com:5060 SIP/2.0
16:29:46.030460 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0
16:29:46.030587 IP x.x.53.184 > sip.example.com: ICMP x.x.53.184 udp port sip unreachable, length 492
16:29:46.530506 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0
16:29:46.530619 IP x.x.53.184 > sip.example.com: ICMP x.x.53.184 udp port sip unreachable, length 492

i've tested this with a few different sip servers and it doesn't matter
whether the pi is forwarding the connection or initiating the connection
itself.

before you ask me to update netfilters, just know i'm more 
interested in learning why this occurs since it seems to be 
contrary to what i know about how connection tracking
should work. if it is a known bug affecting older versions of
netfilters then i would appreciate any documentation that might
persuade tp-link to update their firmware.

yours,

eray

Re: connection tracking fails to update udp timer

[Florian Westphal]

Eray Bilgin <bilgin@eray.ca> wrote:
> i noticed this when my voip phone mysteriously stopped ringing. i use
> a tp-link router as a gateway which i'm certain is running
> linux/netfilters, though i don't know what version. i've observed the
> same problem on my raspberry pi running iptables v1.8.2.
> 
> usually the first thing a sip client does is register with the provider's
> server. this has the effect of punching a hole through any firewalls in
> its path. after that initial registration, my provider keeps the
> connection alive by sending messages every 60 seconds.
> 
> when netfilters sees traffic moving back and forth, the connection should
> transition to the assured state and set the expiration timer to
> nf_conntrack_udp_timeout_stream, which by default is 120 seconds. but in
> this case the timer is reset to nf_conntrack_udp_timeout, which is 30
> seconds. the connection does not appear as "assured".

Replies during first 2 seconds are ignored in order to prevent
DNS requests from triggering assured state + 2m timeout.

Re: connection tracking fails to update udp timer

[Eray Bilgin]

---- On Tue, 11 Mar 2025 10:48:12 -0400 Florian Westphal <fw@strlen.de> wrote ---

    >Replies during first 2 seconds are ignored in order to prevent
    >DNS requests from triggering assured state + 2m timeout.

i see.. is there a run-time option that overrides this behavior, at least
for select ports? my other router which runs dd-wrt doesn't have this
problem

eray