I just checked on my wrt320n running k2.6 big 15778 and port forwarding worked fine.
Are you guys accidentally filling in the source net? It's a new option that restricts what remote sources can access the port forward so you should leave it empty if you want it to allow every source.
If you encounter the problem could you please post the usual info plus the output of these two commands.
The iptables output looks alright for both of you.
@mastacontrola - Your TCP port 993 rules got matched a few times which suggests that maybe nothing is listening or it's blocked after the router. Also you ought to consider changing your forwards to only use whichever TCP/UDP/both setting you need instead of leaving them on both all the time.
@Enik - Your TCP and UDP port 32459 rules got matched a lot. This strongly suggests that it's functional and you have something very actively using it. _________________ 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)
Joined: 23 Nov 2010 Posts: 28 Location: Crown Point, NY
Posted: Wed Nov 24, 2010 6:01 Post subject:
Okay, too easy to fix the TCP/UDP/Both area. All done. I don't know why 993 was matched a whole bunch, but in 15704 the forwards work perfect, in 15778 (both look the same to me from the output's I put on) the 15778 didn't work with port forwarding. I don't know why this has happened, but it seems like a bug in the build (especially since there is more than just I having this issue.
phuzi0n wrote:
The iptables output looks alright for both of you.
@mastacontrola - Your TCP port 993 rules got matched a few times which suggests that maybe nothing is listening or it's blocked after the router. Also you ought to consider changing your forwards to only use whichever TCP/UDP/both setting you need instead of leaving them on both all the time.
@Enik - Your TCP and UDP port 32459 rules got matched a lot. This strongly suggests that it's functional and you have something very actively using it.
The iptables output looks alright for both of you.
@Enik - Your TCP and UDP port 32459 rules got matched a lot. This strongly suggests that it's functional and you have something very actively using it.
You're right. Port 32459 is the port I use for uTorrent. If I check the port on grc.com or portforward.com without uTorrent running it will show the port as closed (as well as the other ports). What's weird is if I start uTorrent and check the port again the sites will show the port as open and uTorrent has no problem communicating... For port 27015 the port stays closed even when I run the application using the port so the app is unable to communicate. The ports should stay open (and forward data) regardless of whether the application using it is running or not. I also tried enabling the uPnP service but that didn't help either - which is just as well as I'd rather leave it off.
One thing about port forwarding I can confirm, is that it's weird: on the latest EKO build, the router would hang itself up if I used it. Only when doing all port forwarding through uPnP would it work properly. _________________ If you use DD-WRT, you HAVE to make a donation! See this topic too: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=228
Posted: Wed Nov 24, 2010 17:43 Post subject: Port forwarding issues
port forwarding was not working properly on my Netgear 3500L (set with the gui) after loading st/nas/usb. A reset to factory defaults and rentering it is back to normal. The forwardng was for RDP/PCAnywhere/webserver/lotus application/ and ftp with passive ports
I don't know why this has happened, but it seems like a bug in the build (especially since there is more than just I having this issue.
To me it seems more like the placebo effect. Your minds believe it's broken, therefore it is. Port forwarding is a difficult topic that many people get confused by. About as many people have confirmed it working as those who believe it's broken.
Enik wrote:
You're right. Port 32459 is the port I use for uTorrent. If I check the port on grc.com or portforward.com without uTorrent running it will show the port as closed (as well as the other ports). What's weird is if I start uTorrent and check the port again the sites will show the port as open and uTorrent has no problem communicating... For port 27015 the port stays closed even when I run the application using the port so the app is unable to communicate. The ports should stay open (and forward data) regardless of whether the application using it is running or not. I also tried enabling the uPnP service but that didn't help either - which is just as well as I'd rather leave it off.
I appreciate you taking the time to help out.
This is normal behavior. You must have something listening on the port to accept connection otherwise it will appear closed/stealthed. The port forward is still active on the router but your PC ignores the incoming packets because no program is listening on the port.
For all of you that believe port forwarding is broken please see this page I recently created to help people troubleshoot port forwarding problems. Especially make sure that you are not using any old configuration data since the format of the port forward variable changed recently due to the new source net option.
http://www.dd-wrt.com/wiki/index.php/Port_Forwarding_Troubleshooting _________________ 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)
Joined: 23 Nov 2010 Posts: 28 Location: Crown Point, NY
Posted: Thu Nov 25, 2010 2:37 Post subject:
phuzi0n, I can assure you it isn't the placebo effect, at least not on my end. From what Enik says, it looks like the only time it operates is when someone is actively using that port. I host web services and email services. The ports on the server are listening and operate perfectly as I can access the server using the direct IP's. However, once I add in the variables for the port forwarding to allow for the DNS to route the data properly, they seem to quit working.
With that said, when I try to access the website after 30/30/30 and upgrade, and 30/30/30 again, it will not work after manually putting in the information.
I have backed up my configuration and it updates perfectly as the previous build 15747 was what I was running, but I cannot use it anymore.
Once again, when I put build 15778 on, it will not operate at all. Source net is available in 15704, 15747, and 15778. I do not know why it isn't working, but there is a problem, whether or not everyone is experiencing it not the issue.
To put the point in further, when using 15778, I can't even access the ports as required from the server using the hostname settings. IP direct is the only way I can at all and that is using the non-public IP's. Trying to access using the public IP to port will not allow connection.
phuzi0n wrote:
mastacontrola wrote:
I don't know why this has happened, but it seems like a bug in the build (especially since there is more than just I having this issue.
To me it seems more like the placebo effect. Your minds believe it's broken, therefore it is. Port forwarding is a difficult topic that many people get confused by. About as many people have confirmed it working as those who believe it's broken.
Enik wrote:
You're right. Port 32459 is the port I use for uTorrent. If I check the port on grc.com or portforward.com without uTorrent running it will show the port as closed (as well as the other ports). What's weird is if I start uTorrent and check the port again the sites will show the port as open and uTorrent has no problem communicating... For port 27015 the port stays closed even when I run the application using the port so the app is unable to communicate. The ports should stay open (and forward data) regardless of whether the application using it is running or not. I also tried enabling the uPnP service but that didn't help either - which is just as well as I'd rather leave it off.
I appreciate you taking the time to help out.
This is normal behavior. You must have something listening on the port to accept connection otherwise it will appear closed/stealthed. The port forward is still active on the router but your PC ignores the incoming packets because no program is listening on the port.
For all of you that believe port forwarding is broken please see this page I recently created to help people troubleshoot port forwarding problems. Especially make sure that you are not using any old configuration data since the format of the port forward variable changed recently due to the new source net option.
You're right. Port 32459 is the port I use for uTorrent. If I check the port on grc.com or portforward.com without uTorrent running it will show the port as closed (as well as the other ports). What's weird is if I start uTorrent and check the port again the sites will show the port as open and uTorrent has no problem communicating... For port 27015 the port stays closed even when I run the application using the port so the app is unable to communicate. The ports should stay open (and forward data) regardless of whether the application using it is running or not. I also tried enabling the uPnP service but that didn't help either - which is just as well as I'd rather leave it off.
I appreciate you taking the time to help out.
This is normal behavior. You must have something listening on the port to accept connection otherwise it will appear closed/stealthed. The port forward is still active on the router but your PC ignores the incoming packets because no program is listening on the port.
Well, it's definitely odd. As I mentioned, port 27015 will not forward even when I have the application running and listening on the port. I think I'll try flashing back to 15704 and report my results.
phuzi0n wrote:
Especially make sure that you are not using any old configuration data since the format of the port forward variable changed recently due to the new source net option.
I always enter all settings manually after upgrading - no saved configurations or using scripts.
