TCP Closed Port Woes--Linksys WRT54GS router, Westell 6100 modem, Verizon DSL

[NekoChan]

This is a maddening situation for which I welcome any suggestions to troubleshoot or resolve it.

Specs:
WinXP Pro, SP3
Windows Firewall off
No automatic security software, no third party firewalls
WinMX 3.54 beta 4 (patch included)
Linksys WRT54GS router, set up via automatic, using DHCP
Westell 6100 modem set to bridge mode (not serving routing functions)
IP Address via Command Prompt:  192.168.1.108

Situation:
When I set my router to the fixed IP address given by ipconfig via the Command Prompt (192.168.1.108), any setting for either the TCP or UDP in port forwarding yields the following response from the PortScanner (http://winmx.dnsalias.com/scan/scan.cgi)  (Using TCP = 6699 and UDP = 6257 as examples):
TCP port 6699 is closed. File operations (up/downloads and browsing) including chatroom hosting will probably fail due to this.
UDP port 6257 seems closed. Searches and Chatroom listings will probably fail due to this.

If I change the IP address to something arbitrary, like 192.168.1.111, I get the following from the PortScanner:
TCP port 6699 is closed. File operations (up/downloads and browsing) including chatroom hosting will probably fail due to this.
UDP port 6257 seems open but could be stealthed. So, searches and chatroom listings 'should' be okay.

As I stated before, any setting chosen for the TCP port, with IP = 192.168.1.111, gives a result of "closed" through the PortScanner.  I have attempted the following values for the TCP port with the same "closed" result:
16699
1720
58202

UDP does not appear affected--in other words, the PortScanner result remains "seems open"--as long as the IP address is set to anything but 192.168.1.108.  Setting the router to the latter IP address, again, results in a "seems closed" PortScanner result, no matter the port value.

WinMX Response:
If I set the Incoming TCP Connections to "Listen on Port 6699," and In/Out UDP Packets set to "Send and receive UDP datagrams on port 6257,"  I can successfully search and download from some individuals--this is a hit-or-miss process.  If I set the former to "Unable to accept incoming TCP connections," all downloads get stuck at "Waiting for network connection..."  With either of these settings, uploads time out, every one.

I have been over and over this issue for hours, but have yet to hit upon what could be blocking the TCP port regardless of the port value--and those values were chosen not to be addresses that might conflict with other functions (like WoW or the like).  Why the IP address listed by ipconfig cuts of both the TCP and UDP ports completely baffles me.  There are only two things I can think of that may be suspect:  a) the fact that my router uses DHCP may be problematic; and/or b) a line or combination of lines in my hosts file is mucking up the works--although this seems less likely.  If "a" is at the root of the problem, or contributing to it, I'm pretty much hosed because that's the method I have to use for my router using Verizon's DSL.  BTW, I don't have any of the associated software for Verizon on my computer--I did a system restore after the setup, so my DSL connection is basic and barebones.

The only troubleshooting rule-out I have not performed at this juncture is to completely uninstall WinMX and reinstall with the current v. 3.54 with patch file.

I have a lot of rare tracks I've collected over the years, and I'd really like to be able to offer them to the WinMX community when I'm online.  Any ideas or assistance anyone is able to render would be greatly appreciated.

TIA for any replies --
--
NekoChan

[NekoChan]

Addendum:

Went ahead and performed a complete uninstall of WinMX, then a clean install with the current v.3.54 with 3.0 patch file from the download site.  Reconfigured everything in the program and had exactly the same results.

So, I went ahead and tried setting both TCP and UDP options to "unable to accept" and "unable to send/receive," respectively.  Searching became quirky and slow, but that was expected due to how WinMX shunts requests with no TCP or UDP ports.  Downloads work as expected.  And, lo and behold, there's an upload actually going through.  Yeeha.
 
What continues to mess with my brain is how my router is translating settings, and have UDP stealthed but working, and TCP closed no matter what port value is used.  It just doesn't make sense!    I'm satisfied that I've got WinMX working at this point, but I'd sure like an explanation for the blockage, since with the settings on "unable," it pretty much absolves my ISP, but condemns my bloody router.

Still hoping for any input to allow me to successfully get TCP and UDP working, or at least an explanation for all TCP ports remaining closed per the PortScanner utility.

Thanks again to any brave souls that want to field this --
--
NekoChan

[Me Here]

hi Nekochan,

I can give you a full explanation here, basically what your set up involves is two NAT capable devices, and your configurations on one or the other will get blocked, by the other,  no matter what.  You can only have one handling the actual NAT traffic, so the best resolve is to set the Modem the 6100, into bridge mode or IP Pass through as its called on some, disable the NAT on it.  You'll have to consult your manual for the exact procedure.  Reboot everything and let the router (Linksys) assign an IP and do the 'routing' for you.  Once this is done its best to set up a static ip and then set up the rules in the Linksys.

The reason for your results on the portscan site is simple, UDP is nearly impossible to test accurately.  So really that test usually will tell you the UDP is stealthed when its open and working however, we cant count on this being an accurate result for you, we know full well there is no way those ports were open so its obviously false.  I'm happy to say that the TCP on that scan checker is quite accurate however and when your set back up use it to test again.

Using WinMX as you have it now will work ok, for about 80% of your transfers, because WinMX only requires one of you have open ports to make the transfer in, so most users will have open ports.  For those set up with "Unable" on both TCP and UDP the transfers will fail for you both up or down.

Hope this helped explain it to you and great job giving plenty of detail when posting too.. post back if you still need any help.

[NekoChan]

You can only have one handling the actual NAT traffic, so the best resolve is to set the Modem the 6100, into bridge mode or IP Pass through as its called on some, disable the NAT on it.

You must have missed the info in my specs:  Westell 6100 modem set to bridge mode (not serving routing functions).  I had to do this in order to have the Linksys router function with the modem at all, so that rules out the two NAT devices fighting each other theory.

Once this is done its best to set up a static ip and then set up the rules in the Linksys.

I have already attempted this and described it in my initial post.  To wit:  using the IP address yielded by the ipconfig command at the Command Prompt gives me a "closed" status for both the TCP and UDP through the PortScanner utility.  This is when it is used to within the router settings for port forwarding.  In all honesty, actually setting a static IP for the LAN connection makes no difference as to how the router behaves verses the router automatically assigning an IP.  The only difference seen is when the IP address in port forwarding is set for something other than that given by the ipconfig command--for example, using 192.168.1.135 instead of 192.168.1.108--and that difference is the UDP then reads as "stealthed but appears open" instead of "appears closed" through the PortScanner utility.

The reason for your results on the portscan site is simple, UDP is nearly impossible to test accurately.  So really that test usually will tell you the UDP is stealthed when its open and working however, we cant count on this being an accurate result for you, we know full well there is no way those ports were open so its obviously false.

Really?  Then why could I search and download (albeit not from everyone) when I had WinMX to listen in on the assigned ports for both UDP and TCP?  The only constant here was people couldn't upload from me.  I think you're missing something here.  UDP had to be functional for me to get the response from WinMX with these settings. If not, I would have expected no functionality at all regarding searching, which worked flawlessly.

I'm happy to say that the TCP on that scan checker is quite accurate however and when your set back up use it to test again.

I'm dubious as to this, because an optional checking utility, ShieldsUP! at www.grc.com, reported any tested TCP port as stealthed, not blocked, when using a different IP address than that supplied by ipconfig in the router port forwarding setup.  ShieldsUP! would report the TCP port as blocked only when I used the IP address supplied by ipconfig.  See why I'm mumbling to myself about this?  My router's behavior is completely illogical.  And I still believe that something is being missed, here, by both of us.

Using WinMX as you have it now will work ok, for about 80% of your transfers, because WinMX only requires one of you have open ports to make the transfer in, so most users will have open ports.  For those set up with "Unable" on both TCP and UDP the transfers will fail for you both up or down.

All the more incentive for me to get my bloody router to operate correctly.    Given that the battling NAT devices theory has been disproven, do you have any other ideas?  I've reviewed the manual for my modem's setup and verified that I did indeed put it into plain vanilla bridge mode, so it definitely is not fighting the router (as I stated before, I had to do this to get my Linksys router to work with the Westell 6100 modem in the first place).  It's completely unwarranted for my router not to "just work" with port forwarding properly set up.  It shouldn't be behaving in this fashion.  That's why I mentioned the DHCP protocol it has to run on as a possible problem source, since most people are running their routers via PPPoE.  This is a Verizon thing, and may be part of the problem--I just can't figure out how.

As always, any other ideas would be appreciated.  This is not your stock WinMX port forwarding problem, as you can now see.

Purrs --

[NekoChan]

Okay, I have no clue whether this is due to it being my birthday, or the fact that I pounded away (figuratively speaking--when I get to the point I physically break something, it's a lost cause) at my router for another few hours with a very determined look on my face, but...I finally got my port forwarding to work.
 

What I did:
-- Turned off the DHCP server function in my router's setup (separate from the actual protocol and not really necessary when it comes down to it)
-- Tried again at setting up a static IP.  This time, it worked (first time killed all Internet access).  This time, I also had valid DNS servers from lookup (big help)
-- Set the TCP and UDP port forwarding settings for "Both," instead of separately assigning "TCP" and "UDP" for each in the drop-down boxes
-- Re-ran the WinMX setup wizard with the default TCP and UDP port settings

And it all came together to "just work."    Must be because it's my birthday, because yesterday I just kept going round and round with this.

So, a successful resolution to a frustrating port forwarding situation.  Good router! <pats router>  I knew you were trying hard to make this happen. <snerk>

Oh, lookee at all the people downloading old school 80's grooves!  Bwahahaha!  Now I must begin my campaign of .ogg evangelism over .mp3. 

Thanks for your feedback, Me Here.  Maybe you worked some magic in this situation as well.  Whatever did the trick, I'm just happy I can toddle off to bed for a few hours.

Big Rumbling Purr --

[Me Here]

LOL good lord,

Your right NekoChan I did infact miss that in your original post, and in my defense it was rather late here when i found you needing help.. sorry.. in any case Im very happy you have it working and are getting some needed rest.

And Happy Belated by the time you read this reply Birthday from us all @WinMxWorld