Hi,

I have a few port forwards set up on my router (currently on BB r41835), and it seems that after a reboot I need to manually restart the firewall to get fully operational again.

As an example, I have one rule that forwards UDP port 10013 to a machine in my lan. The external device that uses this port sends UDP packets with 10 seconds intervals.

This is how the redirect looks:

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'udp'
        option dest_ip '192.168.12.126'
        option name 'Test1'
        option src_dport '10013'
        option dest_port '10013'

After a reboot, this redirect does not work until I manually restart the firewall:

/etc/init.d/firewall restart

Reloading does not work, it needs to be restarted. The packets still arrive at the wan interface (obviously), it's just that they are not forwarded anywhere.

I'm not sure how to diagnose this, because the config is obviously working after a firewall restart, and during a reboot the firewall is also by definition restarted.

Does it also start working if you issue the following command without restarting the firewall?

echo f > /proc/net/nf_conntrack

I just tested that, and I can confirm that this command also causes it to start working again.
Is this a bug somewhere?

Anyone knows if this behaviour could be a bug? Could it be related to the fact that packets are coming in while the router is still booting (before firewall is operational), creating entries in the connection tracking table that confuses the firewall?

Yes, thats exactly the case. For a while we used to clear the conntrack table on each ifup but the downside of this approach is that it interrupts established connections on unrelated ifaces (think of e.g. a vpn reconnect terminating all wan connections that do not run over the vpn).

I'm still thinking about a proper solution for that.

Apparently it would require conntrack-tools:

"conntrack -D --src-nat --reply-dst <old-wan-ip>"

see:

http://serverfault.com/questions/367626 … ck-entries
http://www.muchtall.com/2008/11/12/5/

But I'm not sure if the old conntrack-tools 1.0.0 (Feb-2011) package supports this syntax ...

PS: pfSense has also had the very same issue (states not clearing upon if up/down) for years. It usually becomes an issue for UDP states, such as "stuck" SIP logins by the IP-PBX.

(Last edited by kpv on 28 Jul 2014, 17:02)

jow, are there any plans to deal with this issue before the final release of OpenWRT 14.07 ?

Yes, there are but I am low on time so it might take a while.

Thanks for the feedback, have you decided about the technical approach you'll use?

E.g. before your yes answer, I was considering about doing it the following way:
1) Try to compile latest (2012) conntrack-tools 1.4.0 http://conntrack-tools.netfilter.org/
2) create a package including only conntrack binary (not conntrackd)
3) invoke conntrack via hotplug (assuming I can feed it the "old" WAN IP) to clear "stale" states

(Last edited by kpv on 30 Jul 2014, 16:14)

I'll extend our "echo f > /proc/net/nf_conntrack" hack to take a source ip. I'd like to not rely on conntrack-tools due to the associated bloat.

Since this is imho one of the most serious limitations / bugs of OpenWRT BB, affecting all services using UDP flows from VoIP to VPNs, I just checked and the (old) conntrack-tools v1.0.0 included in BB 14.07 does seem to support the

conntrack -D --src-nat --reply-dst old.wan.ip.addr

syntax to clear states:

...
conntrack v1.0.0 (conntrack-tools): 13 flow entries have been deleted.

(Last edited by kpv on 6 Aug 2014, 00:03)

jow added the fw3 part of his solution for flushing old states upon WAN ip change and asks for testing:

This forum thread is just one of several about "stuck UDP connections" (typically noticed for VoIP and VPNs) which are probably due to the same underlying issue.

Hmm. In my case I have a static WAN IP (I am actually using DHCP on WAN, but my ISP has a static lease of this IP), so I guess the solution as proposed will not work if it is triggered by a WAN IP change?

In my case, the problem appears because UDP-packets hits the router before the FW has been initialized (after a reboot), and the way I read this, it would not fix this problem. Or will it?

The initial case is covered as well by the latest changes. Upon first firewall start the entire ct table is flushed.

It seems to segfault on my test (x86) VM:

Mon Aug 11 16:37:02 2014 user.notice firewall: Reloading firewall due to ifup of wan (eth1)
Mon Aug 11 16:37:02 2014 kern.info kernel: [   16.643080] fw3[3518]: segfault at 0 ip 08051ea7 sp bf8468b0 error 4 in fw3[8048000+23000]
Mon Aug 11 16:37:03 2014 user.notice firewall: Reloading firewall due to ifup of vpn1 (tun1)
Mon Aug 11 16:37:04 2014 kern.info kernel: [   17.929763] fw3[3799]: segfault at 0 ip 08051ea7 sp bfd3ace0 error 4 in fw3[8048000+23000]

PS: core files e-mailed to jow

Testing a x86 VM with jow's latest fix (r42138) I've noticed no segfaults and the firewall seems to flush all (interface-specific) states upon wanup.

Hopefully more people, particularly those running constant  UDP streams (e.g. SIP or VPN behind an OpenWrt router) will give the new feature a thorough test.

(Last edited by kpv on 11 Aug 2014, 22:41)