The random port number forwarding bug is still alive and well in r16473 of the openwrt-wrt54gs-squashfs.bin for 2.4 kernel from x-wrt.org.
Topic: Port forwarding stops working after a while
The content of this topic has been archived between 4 Mar 2018 and 18 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.
I'm having this problem with the most recent release. I'm not using QoS or PPTP so I'm not sure why I'd have this problem.
It suffices if the PPTP support is in there, you do not have to use it AFAIK.
Building an own image from a more recent version from SVN should solve the problem.
Is there a chance that an official release might be made? I don't believe it's very easy for me to build a WRT54G bin for SVN that works with LuCI...
Any updates on this? I am seeing this issue on several boxes here at work. We are running WRT54GL V1.1 hardware with OpenWRT version 8.09.1 firmware (r16278 I think).
Rebooting seems to be the only way to fix this and I would prefer not to have to reboot more than the current midnight reboot.
Thanks
Aaron Z
Have you tried 8.09.2? The release notes mention this bug has been fixed. I have not had this problem in quite a long time at this point.
Have you tried 8.09.2? The release notes mention this bug has been fixed. I have not had this problem in quite a long time at this point.
Not yet, the location that was having this issue stopped having it, so it has gone down in the list of important things to get done.
Aaron Z
8.09.2 does *not* fix the bug, even though the release notes claim to do so. However, it has recently been fixed with r19761. Merging that revision to the 8.09.2 branch fixes NAT definitely, I've been running this for weeks now and the NAT bugs are definitely fixed. More details at https://dev.openwrt.org/ticket/2558
This is becoming a common frustration. How do we get the r19761 on an existing system, or have a new bin file including it?
I'm using WRT54GLv1.1 with the latest stable 8.09.2 and I could redirect 8080 to 8080 on an internal server, however redirecting any other port seems to fail for some reason like i see the iptables rules but they're not functional :\
I tried to redirect Asterisk, SSH, Web and DB traffic but nothing is working except that 8080 port for some reason.
8.09.2 does *not* fix the bug, even though the release notes claim to do so. However, it has recently been fixed with r19761. Merging that revision to the 8.09.2 branch fixes NAT definitely, I've been running this for weeks now and the NAT bugs are definitely fixed. More details at https://dev.openwrt.org/ticket/2558
That's weird. I haven't had a problem on 8.09.2 and definitely had the annoying bug for a couple of years prior to upgrading to that. If it wasn't fixed it was certainly improved for me, unless you are referring to a problem other than the specified forwarded port mysteriously changing to a different port.
That's weird. I haven't had a problem on 8.09.2 and definitely had the annoying bug for a couple of years prior to upgrading to that. If it wasn't fixed it was certainly improved for me, unless you are referring to a problem other than the specified forwarded port mysteriously changing to a different port.
I had it on 7.x (I think), and all 8.09.x releases. I have an asterisk voip server running behind my openwrt router, so I have to map a range of ports to that server. Before this one revision, my asterisk voip server would randomly lose it's registration to one of my sip providers (but not all were affected), usually after several hours or almost a day. This happened on a daily basis. I assume that the packets were forwarded to the wrong port, like all other people suggested. It didn't matter whether I mapped the whole range of ports in one rule, or set up a rule for each port individually. Anyway, after applying that one patch to 8.09.2 this bug definitely is fixed. My asterisk has been working great for weeks with no interruption whatsoever. I wasn't able to use openwrt until this fix, so I've been trying all releases for the past year or two, none of which worked properly.
(Last edited by thomasw on 10 Apr 2010, 05:27)
How do we get the r19761 on an existing system, or have a new bin file including it?
Make sure subversion (svn) is installed on your machine. Then checkout the 8.09.2 tag and apply r19761. Then compile according to the build instructions.
svn co svn://svn.openwrt.org/openwrt/tags/8.09.2 kamikaze_8.09.2
svn merge -c 19761 svn://svn.openwrt.org/openwrt/trunk/ kamikaze_8.09.2/
Outgoing traffic is always fine, but every so often, traffic to port forwarded servers ceases. It often goes weeks at a time with no issues, not sure what triggers the problem. A reboot always cures it.
I'm going to try r19761 and see if it cures it.
Thomas, thanks for posting!
Outgoing traffic is always fine, but every so often, traffic to port forwarded servers ceases. It often goes weeks at a time with no issues, not sure what triggers the problem. A reboot always cures it.
This is exactly what I experienced. I haven't seen this issue in more than a month with this one revision applied. Let me know if this fixed it for you, too. Good luck!
https://dev.openwrt.org/ticket/2558
I think this bug has reappeared (or is still here) in 10.03.1, while I never experienced with 10.03...
I think I will revert back to 10.03 :-(
Or does anyone have any news?
Paolo
I see my port redirects stop working after usually a couple hours on my Vera 3 router, which is running OpenWrt 10.03.1. In the OpenWrt web ui, I can restart iptables and the port redirects start working again. Would love to see this fixed as it's a real pain.
Hi All,
I'm posting only for the records.
I had this issue with 8.09.1 on a WRT54GL. I updated the WRT54GL to 8.09.2, and the problem went away. The uptime of the device is 60 days now, runs like a charm (regarding this issue and issues in general :-), runs extremely stable ).
Keep up the good work :!:
603-netfilter_nat_pptp.patch.fix.patch
The 603-netfilter_nat_pptp.patch.fix.patch is not downloadable,
could you send it to me ?
why 603-netfilter_nat_pptp.patch caused the bug?
Thanks.
The discussion might have continued from here.