to do a scan and it said the first 1023 ports on my router was clean and secure-the 2nd question is how would I know if that website/tool is accurate. then again, who knows if that;s so only because i turned of wan pinging? _________________ Please state what make and model router plus the build number and type of DD-WRT you are using. Screen prints and a network diagram can are also helpful. Before you create a new post, use the search function. Chances are your issue has happened to someone else.
No, a port-scan wouldn't be affected by ping-response, that is separate. Sounds like it doesn't mess up the security, then, it just seems strange from 10,000' to treat all traffic the same, regardless of origin, in order to fix a forwarding issue. I guess I just don't understand what the masquerade command is doing...
Posted: Wed Oct 17, 2012 15:22 Post subject: Re: NAT Loopback fix for 15760 and higher, (Port forward iss
phuzi0n wrote:
I spent some time thinking about the best way to fix loopback. Despite some bad documentation throwing me off before, I found that it's possible to mark traffic destined to the WAN IP and then only masquerade the marked traffic. This should allow loopback to work for all local interfaces without causing problems when ebtables is loaded.
Save the following commands to the Firewall Script on the Administration->Commands page to fix loopback.
insmod ipt_mark
insmod xt_mark
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001
iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
If you have a block of static IP's using 1:1 NAT then you also need to add another iptables rule to cover your IP block. Edit the bolded netblock to be your static IP block.
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d 1.1.1.0/24 -j MARK --set-mark 0xd001
The one known caveat is that badly written QoS scripts will prevent it from working but that's a problem with the scripts that needs to be fixed...
I did this fix on SVN 15962 on WRT300N. It works for a couple internal devices but it does not work a for 1 laptop who has a MAC address QoS rule. Is this a known issue and is there a fix for it?
Not being familiar with the DD-WRT build processes and TRAC in particular, how can one find out which build and when this would be included in a firmware build?
Posted: Thu Oct 18, 2012 1:17 Post subject: Re: NAT Loopback fix for 15760 and higher, (Port forward iss
marioja wrote:
I did this fix on SVN 15962 on WRT300N. It works for a couple internal devices but it does not work a for 1 laptop who has a MAC address QoS rule. Is this a known issue and is there a fix for it?
Yeah Markus pointed out that the marks need to be saved with conntrack so that they're not killed by conntrack restore rules that QoS (and maybe AR) use. The >20000 builds have it included but if you want to do it on older builds then you should add this to the bottom of the script:
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
From my (limited) understanding, the original behavior (before it "broke") was that the NAT rule was hard-coded in. That hard-coding was then removed because it's non-standard behavior, and people who wanted the old behavior could add the rule back in manually, so no functionality is lost (just an extra step added to the setup). Now all that this new "fix" does it revert to the old way of hard-coding this rule in, regardless of whether you want it or not. Since there is essentially no difference between adding the rule manually and having added automatically, why this reversal?
I do use (and require) the NAT loopback, so I personally don't care either way. But on principle, if the loopback is indeed nonstandard, then I think that the so-called "broken" behavior was correct.
Yeah, it worked for me. I tried only the 4lines version. Works like a charm. Netgear WNDR3700v2 v17201.
I only have a small question. What does the "Filter WAN NAT Redirection" checkbox does in the "loopback-broken" versions? It is supposed to turn on, and off NAT loopback, isn't it? Why someone "broke" all loopback in the code, instead of only change the default option to this checkbox if it wants to change the default behavior of routers?
From my (limited) understanding, the original behavior (before it "broke") was that the NAT rule was hard-coded in. That hard-coding was then removed because it's non-standard behavior, and people who wanted the old behavior could add the rule back in manually, so no functionality is lost (just an extra step added to the setup). Now all that this new "fix" does it revert to the old way of hard-coding this rule in, regardless of whether you want it or not. Since there is essentially no difference between adding the rule manually and having added automatically, why this reversal?
I do use (and require) the NAT loopback, so I personally don't care either way. But on principle, if the loopback is indeed nonstandard, then I think that the so-called "broken" behavior was correct.
Your understanding is wrong. There has always been an option to enable or disable loopback (very long ago there was even duplicate options), that option ("Filter WAN NAT Redirection" unchecked in security settings) was left in the GUI but did nothing and is now fixed to actually disable/enable loopback again. It could use a more obvious name though. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
I have tried pasting it before and after but it breaks pixelserv each time.
Are you saying that the pixelserv command works fine without the loopback rules in the OP but breaks when you have both, or are you just having trouble getting pixelserv to work on its own? The loopback rules don't touch any of the same traffic that the pixelserv rule does so there shouldn't be any problems doing both unless for some crazy reason your WAN IP happens to be 192.168.1.1. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Must have been something else causing my issue earlier. I cleared the PixelServ rules from the Firewall, pasted the loopback rules and let the disable-ads.sh rut the PixelServ rules back in and everything works.
Okay in general i have a wrt320n w/mega, wrt54gs v6 w/micro and wrt54gtm with build 15962 this i read was a stable build for WDS setup. Problem is now from the WAN i can get to the host router admin but unable to get to any other of my forwarded ports.