To all:
Without having the time at the moment to list all the details, just please consider the following:
If you're trying to poke a whole through the NAT/firewall to allow for an internal service to be accessed by the public IP address, do you really want that service working properly for the whole known world, EXCEPT for your small corner (on your local LAN, behind the router?) I can see plenty of uses for the opposite, and many uses for making something publicly accessible, but a lot of the approaches people are taking towards this just seems backwards...
The "_wan" chains are predefined to mean anything that is actually coming from the WAN interface, regardless of address. I'm guessing too many people misunderstood the BFD / "Big Fat Disclaimer" in the earlier firewall.user default files (I was one of them), and the "_wan" chains were added to try to make things easier.
Assume you have a local subnet of 192.168.0.1/24, and a WAN IP of 1.2.3.4. Using the "_wan" chains to forward incoming requests on port 80 to your local web server running on 192.168.0.2 will allow the rest of the outside world to get to your web server. But these rules won't match any requests to 1.2.3.4 coming from inside the LAN. You'd have to know to use 192.168.0.2 instead, or utilize some of the other "work arounds" such as tweaking your DNS, using a hosts file, etc.
mbm helped to clarify this in his 2006-01-11 post on this thread. Use the non-"_WAN" chains, and instead of keying to the interface, key to the destination address, e.g. "-d 1.2.3.4". This will then match any requests for the public IP, whether from the WAN or the LAN interface. The only tricky part is remembering to add the MASQUERADE rule to send the source address that will allow for responses.
Anyone, please correct me if I'm missing something obvious here. (I've been using this approach on many networks for the past year+, without any real issues.)
quietdragon:
I'm confused about which "additional entry" and which "two rules" you are referring to, especially considering the 2 previous quotes and 5 total lines to choose from.
Given the 3 total quotes, I think that the "mbm wrote" is the best approach.
With the 3rd quote from the wl500g forum, you need to make sure that "$wan_ip" is initialized somewhere. I've not jumped to Kamikaze yet, but as of the latest WR release, this was not defined by default.
Also, as I understand, by default all forwarded connections are dropped by default, unless accepted at some point with another rule. I would think that the wl500g example is only working if there is another "-j ACCEPT" on the forwarding rule at some point in one of the configuration files.
My $0.02 for the day...