OpenWrt Forum Archive

Topic: Firewall rules break after a while - only reboot fixes this

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,
I am running kamikaze 7.09 on a Linksys wrt54.
I have setup a lot of port forwarding rules to make some servers available to the outer world.
Everything works fine for quite some uptime (usually hours - sometimes days).

After a while (quite likely under heavy traffic load), the internal port forwarding rules get messed up:
* the router starts to redirect packets to different destinations (the destination IP or the destination port changes)
* the firewall rules (as displayed by "iptables -L -vn" and "iptables -t nat -L -vn") still seem to be correct

The problem has the following symptoms:
1) packets do not get forwarded -> the service is unreachable
2) "DROP" messages of the specific packets start to appear in "dmesg"

Restarting the firewall scripts does not help.
Reloading of ipt-modules does not help.
Reboot helps -> afterwards the router works as expected again.

I tried exactly the same setup with two different Linksys WRT54. Both show the same behaviour.

Somehow I have the feeling, that the internal representation of the iptables rules gets messed up under certain conditions.
I don't see any error logs in dmesg (except for the DROP packets).

My current (ugly) "workaround" for this problem is a cron job, that runs every minute and reboots the machine, if it greps the specific DROP packets in "dmesg". That results in quite a lot of downtime (while rebooting) - but at least there are no hours of downtime (this happened without reboot).

The same devices worked flawlessly with white russian before - with a similar setup.

Do you have any ideas, how I can debug this issue?

Should I attach some information (ouptut of "iptables -L -vn" or dmesg)? It only works inline in this forum - right?

Any helping advice would be great!
thanks for your time,
Lars

Hi yapoo,

yapoo wrote:

Which kernel version do you use, 2.4 or 2.6?
We have a similar issue when wifidog gateway is running.
zukky

sorry - I forgot about this important piece of information:

 # uname -a
 Linux OpenWrt 2.4.34 #3 Sun Sep 30 20:33:21 CEST 2007 mips unknown

Your issues sounds really similar to mine - but I am not using wifidog here sad
The wireless interface (wpa2) is used only by two or three people. And none of them were around, during many occasions of that problem.

So it seems to be something different - but thanks a lot for your reply - at least I had some hope for a second smile


To make the problem a little bit more clear, I added two of my port forwarding rules below and the resulting dmesg output for the DROPed packets, which (from my point of view) may never exist:

 # iptables -t nat -L -vn
 [...]
 Chain prerouting_wan (8 references)
  pkts bytes target     prot opt in     out     source               destination         
 [...]
  387 23220 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 2200 to:192.168.1.25:22 
  5966  287K DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 25 to:192.168.1.31:25 
 [...]

 # dmesg
 [...]
 IN=ppp0 OUT=br-lan SRC=80.86.xxx.xxx DST=192.168.1.25 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=19242 DF PROTO=TCP SPT=33490 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0

The dmesg output states that there were incoming packets redirected to DST=192.168.1.25 at port 25. But there are no iptables rules for this combination (port 25 should be redirected to another host; IP 192.168.1.25 is used for other ports).

I could add the complete output of "ipkg list_installed", ps, iptables and dmesg, if that is necessary. For clarity, I tried to keep the amount of information small, but useful - tell me, if I failed smile

Any other thoughts would be great!

I keep seeing this problem being reported.  The problem follows with multiport nat on the 2.4 kernel.  I use only single port DNATs and have never experienced the problem. 

I've suggested in the past this problem be brought to the the netfilter mailing list and bug tracker.  I do not regularly follow that list, so I can't say if it has been pursued by anyone.

lschweiss wrote:

The problem follows with multiport nat on the 2.4 kernel.

thanks - that was the point I was looking for!
After switching to the 2.6 kernel everyhting is fine (besides the missing wireless support).

at least it works now reliably. Thanks for your time!

PS: according to a test made by "jhalfmoon" (http://forum.openwrt.org/viewtopic.php?pid=59584 - look out for postings of that user), "multiport" does not seem to be the real source of the problem. (Disclaimer: I did not test this here.)

The discussion might have continued from here.