Re: [SLUG] Port forwarding weirdities
There is a known bug in openwrt, at least on the 2.4 kernel. The bug is that ... After some period time, forwarding a port from X to Y will break :) (forwarding will go screwy ). (where X / Y are different port numbers) You can forward from Y to Y reliably or should at least should be able too ;) 2009/11/3 Jeremy Visser jer...@visser.name: On Wed, 2009-10-28 at 21:37 +1100, Ishwor Gurung wrote: What about just dumping NAT table i.e., without the grep magic foo? Sure. I've attached an `iptables -t nat -L` from working, and broken. (Not sure if such attachments are allowed on this list, but I have seen some pretty hideous top-posting on this list that is much worse than a couple of KB of text attachments.) What's weird is that the line that should make all the difference (the last line in both attachments) doesn't change at all. At time of writing, the brokenness is sending traffic from port 1240 to port 81 instead of 80. (Has now been ports 82 and 95 in the past.) The only differences between the two dumps are that Transmission doesn't have one of its UDP port forwards for some reason, our (dynamic) WAN IP has changed, and I pulled another port forward that I wasn't using. Given that it has been working and broken without much change, I cannot put my finger on what it is. I think it could be a bug in OpenWRT. What specific revision is it? I'm running Kamikaze 8.09.1, r16278. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
On Tue, 2009-11-03 at 22:00 +1100, db wrote: There is a known bug in openwrt, at least on the 2.4 kernel. The bug is that ... After some period time, forwarding a port from X to Y will break :) [citation needed] Do you have a link I could follow up on that with? My Google-Fu has failed me (otherwise I wouldn't be having this problem :)). signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
Hi Jeremy, 2009/11/3 Jeremy Visser jer...@visser.name: On Wed, 2009-10-28 at 21:37 +1100, Ishwor Gurung wrote: What about just dumping NAT table i.e., without the grep magic foo? Sure. I've attached an `iptables -t nat -L` from working, and broken. [...] What's weird is that the line that should make all the difference (the last line in both attachments) doesn't change at all. At time of writing, the brokenness is sending traffic from port 1240 to port 81 instead of 80. (Has now been ports 82 and 95 in the past.) This is sad. Indeed sad. The only differences between the two dumps are that Transmission doesn't have one of its UDP port forwards for some reason, our (dynamic) WAN IP has changed, and I pulled another port forward that I wasn't using. Given that it has been working and broken without much change, I cannot put my finger on what it is. Hrmm. Try patching it against r17555 and see how it goes - https://dev.openwrt.org/changeset/17555. There are a bunch of fixes in r16278 plus try disable QOS'ing packets (seems to be the common wisdom of the ticket discussion) I think it could be a bug in OpenWRT. What specific revision is it? I'm running Kamikaze 8.09.1, r16278. Isn't that the stock one? This is quiet interesting https://dev.openwrt.org/roadmap says pptp nat conntrack removed, cause of dnat off-by-one port forwarding bug (r17555). But in your case though its definitely _more_ than off-by-one port fwd in the dnat. hrmm. I feel this is a definitely a bug. File a bug report I'd say (which is rather another question. _Why_ on earth wouldn't you file a bug report?) I mentioned in my previous post that I don't have my wrt with me atm so proceed with caution. These were the summary of latest patches by agb so far- 606-netfilter_NETMAP.patch 5.6 KB 17555 8 weeks agb: merge r17552 to 8.09 [generic-2.4] remove nat pptp conntracking patch // 610-netfilter_connbytes.patch 17.0 KB 17555 8 weeks agb: merge r17552 to 8.09 [generic-2.4] remove nat pptp conntracking patch // 613-netfilter_nat_h323.patch 26.8 KB 17555 8 weeks agb: merge r17552 to 8.09 [generic-2.4] remove nat pptp conntracking patch Sorry can't be of much help. I don't have time nor energy to write a patch. -- Regards, Ishwor Gurung -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
On Tue, 2009-11-03 at 23:34 +1100, Ishwor Gurung wrote: Hrmm. Try patching it against r17555 and see how it goes - https://dev.openwrt.org/changeset/17555. There are a bunch of fixes in r16278 plus try disable QOS'ing packets (seems to be the common wisdom of the ticket discussion) Aha. Found the ticket here after looking based on those keywords: https://dev.openwrt.org/ticket/2558 Cool, looks like it is my issue after all. So it's a bug in one of their kernel patches. Hmmph -- I guess I'm glad it's found, although they certainly took their sweet time. And I can't disable QOS, otherwise VoIP is unusable here. Apparently the fix is going into Kamikaze 8.09.2, so I'm happy about that. Some people in the ticket mention that same port -- same port forwards don't stuff up, so I think I'll just do a 1240 -- 1240 forward until 8.09.2 is released. Thanks for the pointers everyone! Looks like this is 'resolved', despite not being 'fixed' yet. :) signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
On Wed, 2009-10-28 at 21:37 +1100, Ishwor Gurung wrote: What about just dumping NAT table i.e., without the grep magic foo? Sure. I've attached an `iptables -t nat -L` from working, and broken. (Not sure if such attachments are allowed on this list, but I have seen some pretty hideous top-posting on this list that is much worse than a couple of KB of text attachments.) What's weird is that the line that should make all the difference (the last line in both attachments) doesn't change at all. At time of writing, the brokenness is sending traffic from port 1240 to port 81 instead of 80. (Has now been ports 82 and 95 in the past.) The only differences between the two dumps are that Transmission doesn't have one of its UDP port forwards for some reason, our (dynamic) WAN IP has changed, and I pulled another port forward that I wasn't using. Given that it has been working and broken without much change, I cannot put my finger on what it is. I think it could be a bug in OpenWRT. What specific revision is it? I'm running Kamikaze 8.09.1, r16278. Chain PREROUTING (policy ACCEPT) target prot opt source destination zone_wan_prerouting all -- anywhere anywhere zone_lan_prerouting all -- anywhere anywhere prerouting_rule all -- anywhere anywhere Chain POSTROUTING (policy ACCEPT) target prot opt source destination postrouting_rule all -- anywhere anywhere zone_wan_nat all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain MINIUPNPD (1 references) target prot opt source destination DNAT udp -- anywhere anywhereudp dpt:21287 to:192.168.0.23:21287-0 DNAT tcp -- anywhere anywheretcp dpt:21287 to:192.168.0.23:21287-0 Chain miniupnpd_wan_rule (1 references) target prot opt source destination MINIUPNPD all -- anywhere ppp121-44-178-139.lns20.syd7.internode.on.net Chain postrouting_rule (1 references) target prot opt source destination Chain prerouting_lan (1 references) target prot opt source destination Chain prerouting_rule (1 references) target prot opt source destination miniupnpd_wan_rule all -- anywhere anywhere Chain prerouting_wan (1 references) target prot opt source destination Chain zone_lan_nat (0 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_lan_prerouting (1 references) target prot opt source destination prerouting_lan all -- anywhere anywhere DNAT tcp -- 192.168.0.1 anywheretcp dpt:5222 to:192.168.0.14 Chain zone_wan_nat (1 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_wan_prerouting (1 references) target prot opt source destination prerouting_wan all -- anywhere anywhere DNAT udp -- anywhere anywhereudp dpt:53 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:22 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:25 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:993 to:192.168.0.14 DNAT udp -- anywhere anywhereudp dpt:5060 to:192.168.0.3 DNAT udp -- anywhere anywhereudp dpt:1194 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:80 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:443 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:5269 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:5222 to:192.168.0.14 DNAT tcp -- anywhere anywheretcp dpt:5223 to:192.168.0.14 DNAT udp -- anywhere anywhereudp dpt:13000 to:192.168.0.218 DNAT udp -- anywhere anywhereudp dpt: to:192.168.0.218 DNAT udp -- anywhere anywhereudp dpt:6500 to:192.168.0.218 DNAT tcp -- anywhere anywheretcp dpts:1230:1239 to:192.168.0.23 DNAT udp -- anywhere anywhereudp dpts:1230:1239 to:192.168.0.23 DNAT tcp -- anywhere anywheretcp dpt:1240 to:192.168.0.23:80 Chain PREROUTING
Re: [SLUG] Port forwarding weirdities
On Wed, 2009-10-28 at 19:26 +1100, pe...@chubb.wattle.id.au wrote: See if there's another iptables rule redirecting output port 80 to somewhere else. I'm using white russian in almost exactly this config, and it's all working for me. I've been meaning to get back to you on this, and in fact was going to do it today, except we turned off the power (and thus power cycled the router), and when it came back on, it's all going to port 80 again properly. 'Fixed', of sorts. I've saved a dump of `iptables -t nat -L` to a config file, labelled as 'working', and when I reproduce the bug again, I'll compare them and see if there's any difference. Thanks for the pointers so far. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Port forwarding weirdities
G'day SLUG, Okay, so, I have a Linksys WRT54G running OpenWrt, serving as the Internet router for our home. You know the drill — NAT, PPPoE, whatever. Router's LAN IP address is 192.168.0.1. Several port forwards are in place (y'know — SSH, HTTP, SMTP, IMAP, and whatnot) that are already working beautifully. I'm also wanting to forward TCP port 1240 on the WAN side to port 80 on my box, 192.168.0.23, for running a test web server. (Oh, if only I could give non-technical people a link to my IPv6 address instead.) So here's the OpenWrt config I use to do this. Should look sane, even if you've not used OpenWrt before: config 'redirect' option 'src' 'wan' option 'proto' 'tcp' option 'src_dport' '1240' option 'dest_ip' '192.168.0.23' option 'dest_port' '80' And when you run `/etc/init.d/firewall restart`, it generates the following iptables rule as a result: r...@openwrt:~# iptables -t nat -L | grep 1240 DNAT tcp -- anywhere anywhere tcp dpt:1240 to:192.168.0.23:80 Which all worked fine for a week or two. But then for some mysterious reason, when I try and access port 1240 from the WAN side, it started to send traffic to port 95 on my LAN side! (Despite iptables still reporting port 80.) I rebooted the router (to no avail), reset the firewall configs, ran tcpdump, wireshark, and whatnot, and the mangling of the port is definitely something that was happening on the router. (tcpdump showed me packets exiting the LAN side bound for port 95; no pun intended.) So as a quick workaround, I made Apache on my box listen on port 95 as well as port 80, which 'fixed' it. No biggie. Except now it's trying to access port 82 on my box when I hit 1240 on the WAN site. I have not changed any configuration on the router, and if I type `uptime` I can tell it hasn't even rebooted since it was last going to port 95. This is so totally weird, and driving me absolutely insane. All other port forwards work perfectly. Oh, somebody shut down the IPv4 Internet already! Signed, Thief of the last 60 seconds of your time. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
Jeremy == Jeremy Visser jer...@visser.name writes: Jeremy Okay, so, I have a Linksys WRT54G running OpenWrt, serving as Jeremy the Internet router for our home. You know the drill — NAT, Jeremy PPPoE, whatever. Yup, same as I have Jeremy Router's LAN IP address is 192.168.0.1. Several port forwards Jeremy are in place (y'know — SSH, HTTP, SMTP, IMAP, and whatnot) Jeremy that are already working beautifully. Jeremy I'm also wanting to forward TCP port 1240 on the WAN side to Jeremy port 80 on my box, 192.168.0.23, for running a test web Jeremy server. (Oh, if only I could give non-technical people a link Jeremy to my IPv6 address instead.) Jeremy So here's the OpenWrt config I use to do this. Should look Jeremy sane, even if you've not used OpenWrt before: Jeremy config 'redirect' option 'src' 'wan' option 'proto' 'tcp' Jeremy option 'src_dport' '1240' option 'dest_ip' '192.168.0.23' Jeremy option 'dest_port' '80' This looks good. Jeremy And when you run `/etc/init.d/firewall restart`, it generates Jeremy the following iptables rule as a result: Jeremy r...@openwrt:~# iptables -t nat -L | grep 1240 DNAT tcp -- Jeremy anywhere anywhere tcp dpt:1240 to:192.168.0.23:80 Jeremy Which all worked fine for a week or two. But then for some Jeremy mysterious reason, when I try and access port 1240 from the Jeremy WAN side, it started to send traffic to port 95 on my LAN Jeremy side! (Despite iptables still reporting port 80.) See if there's another iptables rule redirecting output port 80 to somewhere else. I'm using white russian in almost exactly this config, and it's all working for me. Peter C -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
I've only ever port forwarded port 80 from external to port 80 on an internal web server. A client picks a high port and sends this request to port 80 on the web server. The web server responds out from port 80 to the high port on the client. So from a router it would port forward any external request into port 80 to an internal host listening on port 80. Otherwise you'd have to port forward every high port to your web server. I have several hosts/domains, all listening on port 80 receiving port forwards from the router which is only port forwarding port 80 to internal. This is all working fine. Unless I'm missing something in your config... Ben Jeremy Visser wrote: G'day SLUG, Okay, so, I have a Linksys WRT54G running OpenWrt, serving as the Internet router for our home. You know the drill — NAT, PPPoE, whatever. Router's LAN IP address is 192.168.0.1. Several port forwards are in place (y'know — SSH, HTTP, SMTP, IMAP, and whatnot) that are already working beautifully. I'm also wanting to forward TCP port 1240 on the WAN side to port 80 on my box, 192.168.0.23, for running a test web server. (Oh, if only I could give non-technical people a link to my IPv6 address instead.) So here's the OpenWrt config I use to do this. Should look sane, even if you've not used OpenWrt before: config 'redirect' option 'src' 'wan' option 'proto' 'tcp' option 'src_dport' '1240' option 'dest_ip' '192.168.0.23' option 'dest_port' '80' And when you run `/etc/init.d/firewall restart`, it generates the following iptables rule as a result: r...@openwrt:~# iptables -t nat -L | grep 1240 DNAT tcp -- anywhere anywhere tcp dpt:1240 to:192.168.0.23:80 Which all worked fine for a week or two. But then for some mysterious reason, when I try and access port 1240 from the WAN side, it started to send traffic to port 95 on my LAN side! (Despite iptables still reporting port 80.) I rebooted the router (to no avail), reset the firewall configs, ran tcpdump, wireshark, and whatnot, and the mangling of the port is definitely something that was happening on the router. (tcpdump showed me packets exiting the LAN side bound for port 95; no pun intended.) So as a quick workaround, I made Apache on my box listen on port 95 as well as port 80, which 'fixed' it. No biggie. Except now it's trying to access port 82 on my box when I hit 1240 on the WAN site. I have not changed any configuration on the router, and if I type `uptime` I can tell it hasn't even rebooted since it was last going to port 95. This is so totally weird, and driving me absolutely insane. All other port forwards work perfectly. Oh, somebody shut down the IPv4 Internet already! Signed, Thief of the last 60 seconds of your time. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Port forwarding weirdities
Hi, Okay, so, I have a Linksys WRT54G running OpenWrt, serving as the Internet router for our home. You know the drill — NAT, PPPoE, whatever. Router's LAN IP address is 192.168.0.1. Several port forwards are in place (y'know — SSH, HTTP, SMTP, IMAP, and whatnot) that are already working beautifully. I'm also wanting to forward TCP port 1240 on the WAN side to port 80 on my box, 192.168.0.23, for running a test web server. (Oh, if only I could give non-technical people a link to my IPv6 address instead.) Heh.. :) So here's the OpenWrt config I use to do this. Should look sane, even if you've not used OpenWrt before: config 'redirect' option 'src' 'wan' option 'proto' 'tcp' option 'src_dport' '1240' option 'dest_ip' '192.168.0.23' option 'dest_port' '80' And when you run `/etc/init.d/firewall restart`, it generates the following iptables rule as a result: r...@openwrt:~# iptables -t nat -L | grep 1240 DNAT tcp -- anywhere anywhere tcp dpt:1240 to:192.168.0.23:80 What about just dumping NAT table i.e., without the grep magic foo? NAT'ing 1240-80 is fine but then as Dr. Peter Chubb mentions, 80-(could_be_any_arbritrary_port_here) which you are obviously not listing it here. Right? Which all worked fine for a week or two. But then for some mysterious reason, when I try and access port 1240 from the WAN side, it started to send traffic to port 95 on my LAN side! (Despite iptables still reporting port 80.) I rebooted the router (to no avail), reset the firewall configs, ran tcpdump, wireshark, and whatnot, and the mangling of the port is definitely something that was happening on the router. (tcpdump showed me packets exiting the LAN side bound for port 95; no pun intended.) So as a quick workaround, I made Apache on my box listen on port 95 as well as port 80, which 'fixed' it. No biggie. Except now it's trying to access port 82 on my box when I hit 1240 on the WAN site. I have not changed any configuration on the router, and if I type `uptime` I can tell it hasn't even rebooted since it was last going to port 95. This is so totally weird, and driving me absolutely insane. All other port forwards work perfectly. Oh, somebody shut down the IPv4 Internet already! One of my mate said he had the same issue (he fixed it but I don't know how he did it, I told him to type a little bit more using his fingers and choose lesser automagic foo configs in his wrt :-) I think it could be a bug in OpenWRT. What specific revision is it? Also, there's a ticket for it if you want to read https://dev.openwrt.org/ticket/2558 and it _seems_ that its related to nat specifically. Also, try newer revision as reported by one users success if you haven't (I do not have my wrtgl with me atm) :-) [...] -- Regards, Ishwor Gurung -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
