Modify

Opened 10 years ago

Closed 4 years ago

Last modified 4 years ago

#2558 closed defect (fixed)

iptables rules doesnt work after some time

Reported by: mangel@… Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: base system Version:
Keywords: Cc:

Description

The iptables rules doesnt work after 2-3 days without reboot. I can see them with iptables -L but they are not active (all incoming ports are blocked). Restart of firewall script doesnt help, only a reboot.

Attachments (0)

Change History (66)

comment:1 follow-up: Changed 10 years ago by mangel@…

The router is an asus wl500gP

Openwrt:

Kamikaze 7.09 - Revision: 9134
Packages - Revision: 9158

comment:2 in reply to: ↑ 1 Changed 10 years ago by schwicht@…

Replying to mangel@gmx.de:

The router is an asus wl500gP

Openwrt:

Kamikaze 7.09 - Revision: 9134
Packages - Revision: 9158

On my router (asus wl500W, Kamikaze 7.09, 2.4 kernel) I loose (some) DNAT (rules) after some time as well. I seem to be able to trigger it by transferring a a lot of data (big iso files and system backup via a client based vpn connection). I was wondering if some QoS function kicks in and does the wrong thing? just speculating here ...
I have an VOIP ATA (Grandstream 386) connected via ethernet that exposes the issue to me, so this is probably not related to any WLAN device driver .... On the "other side of the router" I use a pppoe connection to a Verizon FIOS modem)

iptables - 1.3.7-1
ip6tables - 1.3.7-1 (not used)
tc - 2.6.20-070313-1
openvpn - 2.0.9-1 (not used)
ppp-mod-pppoe - 2.4.3-7
shorewall-common - 4.0.4-1 (not used)
shorewall-shell - 4.0.4-1 (not used)
....

Most notable my udp RTP forwarding rules to my ATA fail and the media stream (udp) does not arrive at the ATA anymore. (a.k.a. no audio from the person calling in) and/ or no SIP (tcp) announcing an incoming call.
booting the AP (temporarily) resolves the issue (unchanged configuration).
It would be interesting to see, if the people seeing the problem share the same setup. For example I have ip6tables and openvpn installed but not configured yet.
Do we have a setup somewhere running 7.09 on 2.4 bcrm that does *not* have the problem?

comment:3 Changed 10 years ago by azral(a)azral.se

I can confirm this issue - running Kamikaze 7.09 (brcm 2.4 kernel) with nbd's qos-script.

iptables -t nat -A prerouting_wan -p tcp --dport 4800 -j DNAT --to 192.168.1.10

iptables -A forwarding_wan -p tcp --dport 4800 -d 192.168.1.10 -j ACCEPT

Above works as far as i can tell (without regular reboots ..)

iptables -t nat -A prerouting_wan -p tcp --dport 4800 -j DNAT --to 192.168.1.10:4800

iptables -A forwarding_wan -p tcp --dport 4800 -d 192.168.1.10 -j ACCEPT

Does not.

comment:4 Changed 10 years ago by freeman

I can confirm this, but not all rules doesn't works, it's complained only for port forwarding rules like DNAT.

comment:5 Changed 10 years ago by eug

Exactly the same strange behaviour here. I am using OpenWRT WhiteRussian 0.9 with iptables 1.3.3.2 for regular filtering.

?!Sometimes?! the rules doesn't work, although I can see (iptables -L -v -n) the packets enterring the rules and incrementing the counters.

comment:6 Changed 10 years ago by anonymous

i'm having the same problem but with v1.3.7 on a kamikaze 7.09 but with MASQUERADE target, after a while, it stops masquerading, so all outgoing packets use internal ips

comment:7 Changed 10 years ago by jan

same here on an Asus WL-500GP with kamikaze v7.09 (kernel v2.4 bcm version). I can also confirm the statement of azral(a)azral.se and noticed by inspection with wireshark that the packages would be sent to port 4801 in his example - except very shortly after booting !??
I am now using a workaround: no port redirection with DNAT on openwrt combined with port redirection in the firewall on the target machine (e.g. see the FW_REDIRECT variable in opensuse). :-}

comment:8 follow-up: Changed 10 years ago by kaldek

Having activated QoS in Kamikaze 7.09, this problem has begun to affect me as well. I have a theory that it may be related to QoS misbehaving, but my installation was also missing the iptables-mod-nat package (and subsequent kmod-ipt-nat package).

Now that the NAT packages are installed I will keep an eye on it to see if perhaps it is indeed QoS causing the issue.

Some notes specific to my circumstance are of course important

  • FTP wasn't blocked, but then the kmod-ipt-nathelper includes an FTP NAT module
    • Also my FTP wasn't using port redirection (since this isn't supported anyway)
  • IPTables didn't complain about my DNAT rules even though the IPTables NAT modules were not installed
    • I'm pretty sure these are needed for destination port redirection!
  • Previously I was running PacketProtector 2.5 (Kamikaze 7.09 derivative)
    • All NAT redirects worked during a 2+ month uptime
    • I cannot say if the iptables-mod-nat package was installed in PacketProtector (I assume so)
    • The migration away from PacketProtector was due to QoS not working in PP 2.5.

comment:9 in reply to: ↑ 8 Changed 10 years ago by Kaldek

Replying to kaldek:

Having activated QoS in Kamikaze 7.09, this problem has begun to affect me as well. I have a theory that it may be related to QoS misbehaving

Installing the iptables-mod-nat package did not affect the behaviour; the assumption here is that this module was already compiled into the kernel in Kamikaze 7.09 (happy to be corrected). Connections still failed after a few hours when a number of large downloads were performed. These downloads used NNTP, so the ports were in the QoS "Bulk" classification.

QoS has now been disabled and I will perform some large downloads, and leave the router for a few days to see if the problem occurs again. If it does not occur, I will re-enable QoS and then wait for the problem to occur before removing the IPTables mangle rules and then the queues, one at a time. I expect at this time I will identify which rule/queuing discipline is to blame, if indeed QoS is the root cause.

comment:10 follow-up: Changed 10 years ago by kaldek

The problem does not appear to occur with QoS disabled. I am now going to enable QoS and wait for the problem to occur again. I will then update with findings within a few days.

Another item worth noting is that this refers to kernel 2.4.

comment:11 Changed 10 years ago by anonymous

Openwrt is unreliable garbage.

comment:12 in reply to: ↑ 10 Changed 10 years ago by anonymous

Replying to kaldek:

The problem does not appear to occur with QoS disabled. I am now going to enable QoS and wait for the problem to occur again. I will then update with findings within a few days.

Another item worth noting is that this refers to kernel 2.4.

Right I've had QoS enabled for over a week now and the problem has not occurred. However I also enabled physical swap space on a USB stick at that time. Others have said their router took 2 months for the problem to occur, which points back to a resource exhaustion problem.

At this point I can only keep running and perform detailed analysis when the problem occurs again.

comment:13 Changed 10 years ago by kthaa@…

I've noticed that destination port numbers are altered somewhere between prerouting_wan and forwarding_wan when using DNAT.
In my case, I had a rule mapping external port 80 to local 80 (tcp dpt:80 to:192.168.7.10:80). The DPT was correct during prerouting_wan (80) and got translated to 85 (!!!) when forwarding_wan rules were interpreted.
Funny thing, adding the rule: tcp dpt:80 to:192.168.7.10:75 got my www mapping working again (sure, my local www was still running on 80).

comment:14 Changed 9 years ago by mtutak@…

My firewall stops working after starting mldonkey client (heavy traffic). Traffic breaks port forwarding, so connections from outside doesn't reach right machine inside the lan. Interesting: before malfunction X.X.X.X:80 forwards to Y.Y.Y.Y:80, after malfunction X.X.X.X:80 forwards to Y.Y.Y.Y:79! Temporary solution is to forward all ports X.X.X.X:* to Y.Y.Y.Y:*. My Hardware - Asus WL-500GP

comment:15 Changed 9 years ago by acrist

I have wl500w and 7.09 downloaded from x-wrt site, installed using instruction from openwrt documentation. Probem with isuse DNAT, it's work around 4 hours and gone.
Right now try to use qos enable, about result post late.

comment:16 Changed 9 years ago by speedster@…

This still occurs with the 20080922 snapshot, have any devs had a look into why this is still a problem?

comment:17 Changed 9 years ago by anonymous

Still an issue as of 20081019.

Seems like someone's asleep at the wheel.

comment:18 follow-up: Changed 9 years ago by info@…

Hi folks,
anybody active in this thread? I'm having the same problem with this shifting DNAT(and also REDIRECT) target ports. Doing a 1-to-1 mapping as suggested is not practicable.
OK, so long: Hereby i offer a prize of 100 Euros (payable with Paypal) for a well done working patch.
Thomas Lehner

comment:19 follow-up: Changed 9 years ago by cs@…

Hi any news on this issue ? Problem is stil alive.

comment:20 in reply to: ↑ 19 Changed 9 years ago by anonymous

Replying to cs@sigma-com.net:

Hi any news on this issue ? Problem is stil alive.

No,
i have circumnavigated the problem by setting up multiple IPs on the box and doing 1:1 port redirections, which works without the described error.

comment:21 Changed 9 years ago by Keith

'PLEASE FIX THIS BUG!!!!

comment:22 in reply to: ↑ 18 ; follow-up: Changed 9 years ago by frank@…

Replying to info@hotspotsolutions.de:

Hi folks,
anybody active in this thread? I'm having the same problem with this shifting DNAT(and also REDIRECT) target ports. Doing a 1-to-1 mapping as suggested is not practicable.
OK, so long: Hereby i offer a prize of 100 Euros (payable with Paypal) for a well done working patch.
Thomas Lehner

I have it but you'll need to show some more money

comment:23 in reply to: ↑ 22 Changed 9 years ago by anonymous

Replying to frank@dontspam.me:

I have it but you'll need to show some more money

Hi frank@,
thanks for your response. As mentioned earlier we have already curcumnavigated the problem some weeks ago. Also, the awarded price was intendend as a tribute to the efforts and not as a real wage or offer/bid. But if you're still interested in publishing your patch to the community we're still standig to our offer.

comment:24 Changed 9 years ago by bcl

Working around the problem is NOT a solution!

I too seem to be having similar problems, although for me the symptom is that it stops forwarding UDP packets (or they go someplace else, I haven't sniffed it) after some period of time (days or weeks).

It looks to me like this is a serious bug in openwrt and it makes it useless for any real world use.

Given the lack of response to this and similar bugs I am going to have to consider one of the other WRT54GL operating systems like DDWRT or Tomato.

comment:25 Changed 9 years ago by jow

Imho one of these netfilter patches could be the problem:
603-netfilter_nat_pptp.patch
608-netfilter_ipset.patch
622-netfilter_ipset_porthash.patch

Haven't had time yet to create a build without this patches to test on my router.

Another solution is to switch to the kernel 2.6 variant which does not have this issue.

comment:26 Changed 9 years ago by zardam@…

I also have this problem with 8.09_RC1, on a WRT54GL. Switching to kernel 2.6 is not a solution, because wireless is not reliable with the b43 driver.

comment:27 follow-up: Changed 9 years ago by zardam@…

Seems fixed in [13840]

comment:28 Changed 9 years ago by anonymous

TO be honest, I do not understand why such a serious bug could be kept intact for such a long time.

Practically this bug renders openwrt almost unusable. As 2.6 kernel's
wireless is buggy, this means there is no single version of openwrt
is functioning normally!!

comment:29 follow-up: Changed 9 years ago by anonymous

to be honest, you can buy some non-broadcom hardware from the other 20+ supported platforms..

comment:30 Changed 9 years ago by zardam@…

Of course, I would like to buy better hardware, but linksys ones are cheap, robust, and easily available. If anyone has another competitive solution, I'm very interrsted.

comment:31 in reply to: ↑ 29 Changed 9 years ago by anonymous

Replying to anonymous:

to be honest, you can buy some non-broadcom hardware from the other 20+ supported platforms..

Then it is funny to call this piece openwrt, as it does not run properly on WRT54G.

comment:32 in reply to: ↑ 27 ; follow-up: Changed 9 years ago by darkroom.dave@…

Replying to zardam@free.fr:

Seems fixed in [13840]

Is it still fixed for you? I was thinking about trying the snapshots/brcm-2.4/ on my 54gs

comment:33 in reply to: ↑ 32 ; follow-up: Changed 9 years ago by zardam@…

Replying to darkroom.dave@gmail.com:

Replying to zardam@free.fr:

Seems fixed in [13840]

Is it still fixed for you? I was thinking about trying the snapshots/brcm-2.4/ on my 54gs

Still fixed after one week uptime.

comment:34 follow-up: Changed 9 years ago by wielkiebe

Still same problem on snapshots/brcm-2.4/ image. On my 54gl with qos-scripts enabled port forwarding worked about 4h and now it's broken again.

comment:35 in reply to: ↑ 34 Changed 9 years ago by darkroom.dave@…

Replying to wielkiebe:

Still same problem on snapshots/brcm-2.4/ image. On my 54gl with qos-scripts enabled port forwarding worked about 4h and now it's broken again.

Yes my problem has returned after a few days. So still on 2.4 it breaks after a unspecified time frame.

comment:36 Changed 9 years ago by anonymous

I can't believe this, this information should be all over the OpenWRT homepage / wiki pages etc.

The router is completely unusuable in this state.

comment:37 Changed 9 years ago by anonymous

I've just freshly installed Kamikaze 8.09 RC2, problem still exists. Argh.

comment:38 Changed 9 years ago by anonymous

Can confirm 8.09 RC2 doesn't work either on my WRT54GS V1.0. Is anybody working on this issue?

comment:39 Changed 9 years ago by MasterPLaster

same problem here. funny thing cause if i just set qos to diable and click save changes but without apply changes in xwrt port forwarding works agine. then i just click clearchanges and its ok for next period of time

comment:40 Changed 9 years ago by anonymous

using shorewall fixed my problem, I have pppoe and I blamed the isp for this...

comment:41 in reply to: ↑ 33 Changed 9 years ago by pepper

Replying to zardam@free.fr:

Replying to darkroom.dave@gmail.com:

Replying to zardam@free.fr:

Seems fixed in [13840]

Is it still fixed for you? I was thinking about trying the snapshots/brcm-2.4/ on my 54gs

Still fixed after one week uptime.

Hi there.
I have a question - how to apply changes from:

Replying to zardam@free.fr:

Seems fixed in [13840]

Thank in advance

comment:42 Changed 9 years ago by jakabin@…

13840 did not fix. Still the same ugly bug.
7.09 - 8.09 - Latest trunk = All bugged

comment:43 Changed 9 years ago by existentialhero

This bug persists in all builds that I've tried recently and continues to create serious problems. On my system, external port 2201 is DNATed to port 22 on an internal machine, but after a period of time (possibly related to packet volume) it starts to DNAT to port 23 instead.
What do we need to do to get the attention of the people who know the inner workings of the DNAT stack on this? This is a serious bug, significantly reducing OpenWRT's functionality on this platform. Since the 2.6-series Broadcom drivers still aren't stable, this is very, very bad.

comment:44 Changed 9 years ago by jdobry@…

Problem can by fixed by this way:
forum.openwrt.org/viewtopic.php?id=13533

But price is many openwrt kernel patches removing.

comment:45 follow-up: Changed 9 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

proper fix added in r16141
also backported to 8.09

comment:46 in reply to: ↑ 45 Changed 9 years ago by Yazoo

Replying to nbd:

proper fix added in r16141
also backported to 8.09

nbd, thanks a metric ton! This bug had dissuaded me from even trying OpenWrt on my wl500gP. If the fix really works as advertised, then I think I'll give it a shot now with the 2.4 build... New penguin joy! ;)

comment:47 Changed 9 years ago by wberrier@…

Anyone else still seeing this bug on 8.09.1?

comment:48 Changed 8 years ago by jeronimo <jm+openwrtdev@…>

yep still there (/kamikaze/8.09.1/brcm-2.4/openwrt-wrt54gs-squashfs.bin)

comment:49 Changed 8 years ago by tore@…

This bug is still present in my 8.09.1 (r16278). I've forwarded port 22 on the WAN interface to an internal box on port 22 (TCP), and with tcpdump I see the packets coming in from the internet with dpt:22, but a TCP RST is being generated from rules in the chain zone_wan_REJECT. Inserting a LOG rule into that chain prior to the REJECT rules demonstrates that that the DNAT rule in zone_wan_prerouting for some reason has changed the destination port to 23 even though it very clearly is set up correctly:

Chain zone_wan_prerouting (1 references)
target prot opt source destination
prerouting_wan all -- anywhere anywhere
DNAT tcp -- anywhere anywhere tcp dpt:22 to:192.168.1.2:22

So this bug is not fixed...

Tore

comment:50 Changed 8 years ago by wberrier@…

I don't think this was fixed in the 8.09 branch until r17555 (from trunk r17552).

I've been running for a few weeks now without any issues.

comment:51 Changed 8 years ago by jeromepoulin@…

I can confirm the same problem with QoS enabled, compiled from source Kamikaze 8.09.1 on WRT54GL.

comment:52 Changed 8 years ago by djbruno@…

I'm also having the same problem with the latest stable binary. (8.09.1, r16278)

I'm gonna try flashing 8.09.2 RC2 which is r17574, and I'll report if the problem persists.

BTW, mine is a WL500gP also.

comment:53 Changed 8 years ago by anonymous

I am also seeing this same problem with 8.09.1. nbd, can you please clarify in which released version the problem was fixed?

comment:54 Changed 8 years ago by thomas@…

I see the same problem DAILY with 8.09.2, I have an asterisk server running behind my WL500gP. The problem started with 8.09, it continued with 8.09.1 (even though it was claimed that the bug was fixed), and it is still present with 8.09.2. My home phone breaks every single day because the router stops forwarding UDP packets. The only "solution" is to reboot the router.

Please re-open this ticket as this is definitely a very annoying bug.

comment:55 follow-up: Changed 8 years ago by djbruno@…

As I said in my last comment, I upgraded 2 months ago to 8.09.2 RC2. Since then, I had no more problem with this bug.

Thomas, are you sure the packets are being forwarded to your internal LAN on a wrong port ? Or are they just being dropped ?

comment:56 in reply to: ↑ 55 Changed 8 years ago by thomas@…

djbruno, 8.09.2 (final) is r18961, so if it was fixed in RC2 then it must have been re-introduced. I don't know for sure if it just drops the packets or if they get forwarded to a wrong port. But it seems like it works reliably when I forward port by port (rather than a port range).

comment:57 Changed 8 years ago by thomas@…

Oh, mapping port by port doesn't work any better, either. I thought it was but this morning I had the same problem again.

comment:58 Changed 8 years ago by thomas@…

This bug finally appears to be fixed by r19761 (which intended to fix the multi-port match bug, issue #5141). Wow, after more than two years NAT finally works again!

comment:59 follow-up: Changed 8 years ago by teufel@…

I'm still using kamikaze 7.09 and can confirm, that this bug existed there and is/was probably associated to resource problems. Because I added some swap space of 1 GiB (on a swap partition on a memory stick), it occures very seldom (after a few month). I didn't even recognized this as a bug until I read this today. ;-)

comment:60 in reply to: ↑ 59 Changed 8 years ago by thomas@…

Replying to teufel@…:

I'm still using kamikaze 7.09 and can confirm, that this bug existed there and is/was probably associated to resource problems. Because I added some swap space of 1 GiB (on a swap partition on a memory stick), it occures very seldom (after a few month). I didn't even recognized this as a bug until I read this today. ;-)

It happened to me more than once daily, at least on 8.09.x. I bet that if you apply r19761 on 7.09 that it would fix that bug.

comment:61 Changed 8 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

Looks like this problem may have re-appeared in 10.03.

using standard inbound NAT ("port forwarding") works for about 5 days... then some translations randomly stop working, and "ls /proc/sys/net/netfilter/*" hangs in the D state. System load skyrockets, reboot fails, had to freakin' re-flash.

Is this just a tunable issue; e.g., do I need to bump up an allocation somewhere? I'm really not that heavy a user - not even 10 redirections, and the conntrack table (when I can read it) is seldom more than half a page.

What a bummer - out on a trip very far away and got totally locked out of my own network. Guess I'm stuck with the censored Internet access until I get all the way home. :(

comment:62 Changed 8 years ago by thomas@…

I haven't tried 10.03 yet, but it definitely works on 7.09 with r19761, it's been running for 100 days without a reboot and I haven't had any issues at all.

comment:63 Changed 8 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

This ticket was reopened due to #7410.

However, #7410 refers to ar71xx while this issue is related to iptables on brcm-2.4, multiport and pptp conntrack in particular. Closing this as invalid because it is not related.

comment:64 Changed 6 years ago by maximalmin@…

  • Resolution invalid deleted
  • Status changed from closed to reopened

I have iptables set up to forward ESP from the WAN side into a static-IP host on the LAN side for an IPSec based tunnel. After reboot, the router is able to forward, but after about a day, the tunnel fails, even tho iptables -L -n -v shows the rules in both the nat and filter tables. However, tcpdump shows that the packet is no longer being forwarded from the WAN side (it sees the packet using tcpdump -i x -n esp command), but not on the br-lan side. Certain other forward are still working, but the iptables -L -n -v shows that packet/byte count for the esp rule remains at 0. So in order to get my router working again, I have to ssh-in (luckily the ssh forward rule still works) to a box and then internally ssh into router to reboot it. This is on a Asus WL500gP running 10.03.1 I switched to this router because of similar issues I encountered in a WR850G (Motorola) running Kamikaze (not sure of the version at the moment) which had no issue of forwarding ESP over time, but ssh forwarding eventually fails. So I think this bug has been around for a while...

comment:65 Changed 4 years ago by tripolar

  • Resolution set to fixed
  • Status changed from reopened to closed

please update to latest version. problem should be fixed.

comment:66 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.