No connection when pinging router

[iPwn]

I've heard of "tracecert" - is that of any use? I saw it in threads that unfortunately weren't specific to my problem.

Think of tracert as a 'ping path'... it just pings each step along the way so you can see where the hops are going.

Both ping and tracert use ICMP, which there is no concept of ports in, so you can't do a tracert on a specific port.

What do you mean by power cycle?

Simply turning it off, then back on. If the changes weren't applied, the rules won't be there when you turn it back on.

Also, on the port forwarding rules, you have two rules (both UDP and TCP) setup on the router, forwarding the packets to the internal IP address of the computer/server, right?

By internal, I mean the IP address of the computer locally. If you do an "ipconfig" on the host machine, you should get something like "IPv4 Address: x.x.x.x", that being different from your external address that you get from a site like IpChicken.

 

[hmuk]

I'll do that now. Actually, the rules are set to "Any" - 4000 -> 4000. Should I set it to TCP?

 

[_michaelm]

It's also worth checking with "Shields Up" at grc.com (https://www.grc.com/shieldsup) where you can specify any port and it will independently attempt a TCP connection (as well as ICMP pings or anything else you choose). Very handy to see what your network looks like to the outside world.

As iPwn has said, the following things need to be validated and if done correctly you will be able to establish remote connections:

0) DISABLE UNIVERSAL PLUG'N'PLAY IN YOUR ROUTER!!! (this should never be used, very dangerous protocol)

1) Pick the port you wish to use (4000)

2) Determine the private IP of the machine hosting your software server (e.g. 192.168.1.100)

3) Login to your router and setup port forwarding for:
External IP = ANY, Internal IP = 192.168.1.100, External Port = 4000, Internal Port = 4000, Protocol = TCP&UDP
Note: This may require one rule for TCP and one for UDP depending on your router options. Also, you don't have to use 4000 for internal and external, but it does simplify things (in your situation, you probably do have to if your software is set to use that!)

4) Configure your software to use the desired port (4000) note that this refers to the Internal network port, the software has NO visibility or knowledge of the external port

5) Ensure any firewall is set to permit the application to access the network, and that it is associated with port 4000

6) Start your software and, using the appropriate 'netstat' command for your OS, determine that it is listening for incoming connections

7) Start a telnet session from another machine INSIDE your network and connect to that server/port. If you connect successfully the software is configured correctly (again, validate with netstat on the server to show an established connection)

8) Try a 'shields up' connection test against your external port and ensure it returns 'Open'

9) If you have access to another network (outside of your LAN) such as a corporate VPN, connect to that and then attempt to connect back into your own network. Failing this, get a friend to attempt to connect (initially using something like telnet) to your external IP/port combo (be sure to check the external IP is correct).

10) You should now have a working server - if connections from outside your network fail, try from a different location (in case your friends ISP is blocking the traffic - although this is very unlikely for port 4000) and validate your router's port forwarding policy and firewall rules are correctly setup.

Note: all the above assumes your ISP is not yet using Carrier-Grade NAT (CGNAT) which would prevent you from running a server on your local network which is internet accessible (this includes games consoles which require Point-to-point connections). This is very unlikely, but easily determinable by looking at your router's admin page and checking what the 'public/external' IP address is set to. If it is outside the RFC1918 ranges (i.e. 192.168.x.x, 172.16.x.x or 10.x.x.x) then you're NOT behind CGNAT and you should be fine.

Hope that helps.

 

[hmuk]

So, I made changed the "Any" setting to "TCP" and added another one for UDP. So, at this point, I have two port forwadings on my router - one called FOnline-TCP and one called FOnline-UDP, both set at port 4000. I also have Diablo II port forwarding, which is also port 4000.

Michael, there is no option to select external or internal IPs when port forwarding - mine is a BT Home Hub 4. The options are:

Protocol: Any/TDP/UDP
Port Range: XXX -> XXX
Translate To: XXX -> XXX
[I put 4000 in all four "XXX" fields.]

I did ShieldsUP!, and it gives the following result for port 4000.

Port: 4000
Status: Stealth (which is highlighted green)
terabase, Terabase (I think this is related to its common usage)

This is what I got when I ran netstat:

Active Connections

Proto Local Address Foreign Address State
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51975 TIME_WAIT
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51976 TIME_WAIT
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51977 TIME_WAIT
TCP 192.168.1.64:49157 212.118.234.65:12975 ESTABLISHED
TCP 192.168.1.64:49576 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49577 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49578 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49588 wg-in-f95:http ESTABLISHED
TCP 192.168.1.64:49589 wg-in-f95:http ESTABLISHED
TCP 192.168.1.64:49590 lhr08s01-in-f26:http ESTABLISHED
TCP 192.168.1.64:49594 lhr08s01-in-f14:https ESTABLISHED
TCP 192.168.1.64:49601 213.120.177.176:http ESTABLISHED
TCP 192.168.1.64:49616 lhr08s01-in-f31:https ESTABLISHED
TCP 192.168.1.64:49622 lhr08s01-in-f15:https CLOSE_WAIT
TCP 192.168.1.64:49627 lhr08s01-in-f1:https ESTABLISHED
TCP 192.168.1.64:49628 ham02s11-in-f15:https ESTABLISHED
TCP 192.168.1.64:49629 text-lb:http CLOSE_WAIT
TCP 192.168.1.64:49630 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49631 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49632 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49633 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49634 text-lb:http CLOSE_WAIT

I hope that makes sense - could you explain what you mean by a telnet session?

 

[iPwn]

I think what you're missing is the 'forward to device' part.

So I looked at the BT Home Hub 4 config page, and there's a part on the bottom where you have to associate each port forward rule with a device on your network. Are those setup?

Use the Device box to choose a computer to forward ports to. This box contains a list of computer names that are visible on your network.

Select the application you created using the Game or Application drop down box. Then click Add to enable it.

 

[hmuk]

Oh, no, I did that too. The options I mentioned when port forwarding come first, when configuring a set-up, then you select which computer to forward ports to, and I selected my own.

 

[_michaelm]

So, I made changed the "Any" setting to "TCP" and added another one for UDP. So, at this point, I have two port forwadings on my router - one called FOnline-TCP and one called FOnline-UDP, both set at port 4000. I also have Diablo II port forwarding, which is also port 4000.

Why are you trying to run two applications both on port 4000 (Diablo and FOnline)? Not sure I understand what Diablo has to do with this, or have I missed something?

Michael, there is no option to select external or internal IPs when port forwarding - mine is a BT Home Hub 4. The options are:

Protocol: Any/TDP/UDP
Port Range: XXX -> XXX
Translate To: XXX -> XXX
[I put 4000 in all four "XXX" fields.]

That's fine, most routers don't offer external/internal differentiation as the external is assumed (there isn't any other reason to port forward in a normal home network environment).

I did ShieldsUP!, and it gives the following result for port 4000.

Port: 4000
Status: Stealth (which is highlighted green)
terabase, Terabase (I think this is related to its common usage)

That definitely suggests something isn't correct on your router's port forwarding. I just opened port 1234 and associated it with my machine's IP and Shields Up went from green (stealth) beforehand to red (closed) afterwards. Note that you don't have to even be running a server on port 1234 (or 4000 in your case) for testing Shields Up, you will reply to a TCP connection and/or ICMP ping regardless, it just won't get sent 'up the stack' to the application layer where your server would operate.

This is what I got when I ran netstat:

Active Connections

Proto Local Address Foreign Address State
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51975 TIME_WAIT
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51976 TIME_WAIT
TCP 192.168.1.64:139 Unknown-f8:1e:df:e5:bf:2a:51977 TIME_WAIT
TCP 192.168.1.64:49157 212.118.234.65:12975 ESTABLISHED
TCP 192.168.1.64:49576 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49577 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49578 lhr08s01-in-f4:http ESTABLISHED
TCP 192.168.1.64:49588 wg-in-f95:http ESTABLISHED
TCP 192.168.1.64:49589 wg-in-f95:http ESTABLISHED
TCP 192.168.1.64:49590 lhr08s01-in-f26:http ESTABLISHED
TCP 192.168.1.64:49594 lhr08s01-in-f14:https ESTABLISHED
TCP 192.168.1.64:49601 213.120.177.176:http ESTABLISHED
TCP 192.168.1.64:49616 lhr08s01-in-f31:https ESTABLISHED
TCP 192.168.1.64:49622 lhr08s01-in-f15:https CLOSE_WAIT
TCP 192.168.1.64:49627 lhr08s01-in-f1:https ESTABLISHED
TCP 192.168.1.64:49628 ham02s11-in-f15:https ESTABLISHED
TCP 192.168.1.64:49629 text-lb:http CLOSE_WAIT
TCP 192.168.1.64:49630 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49631 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49632 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49633 bits-lb:http CLOSE_WAIT
TCP 192.168.1.64:49634 text-lb:http CLOSE_WAIT

All the http and https connections (ports 49xxx) are fine, that's just your web traffic and expired sessions. The connection to 212.118.234.65 on port 12975 is a LogMeIn connection (which on a completely unrelated note is now no longer free, so you'll have to find an alternative solution for report access assuming you aren't a pro version subscriber - I'm embarking on that same quest as of tomorrow).

The connections on port 139 relate to NETBIOS, a notoriously insecure Microsoft protocol, but given those connections are to MAC addresses not IP addresses, then it is safe to assume that is confined to within your local network (and hence less of an issue).

I hope that makes sense - could you explain what you mean by a telnet session?

A telnet session is simply a very dumb connection in a command terminal used for testing and remote administration. Essentially it allows you to remove your application/server (e.g. FOnline) from being a potential problem. You won't be able to actually do anything having made a telnet connection, but it's purpose is simply to verify that there is a route from outside your network to inside your network on your chosen port (4000).

In your situation you want to run the following command on the remote server:
Open a command prompt window and type the following (press return after each line)

C:\>telnet 
Microsoft Telnet>open [I]external_ip[/I] 4000

You can test this from another device inside you LAN if you wish, simply start your FOnline application on your server and then replace external_ip with 192.168.1.64 from another host.

You should receive some sort of header message (called a Banner) which confirms the connection was successful. At this point 'quit' a few times should get you disconnected. Feel free to check netstat on your server whilst you're connected and see what it shows you.

Good luck, I've not configured a HomeHub 4 personally, but from what iPwn said you should be almost there. Make sure your settings are applied before you perform your tests (and don't restart your router or they may be lost again).

 

[hmuk]

So, first, I tried "open 192.168.1.64 4000" from my laptop. It begins with:
Connecting To 192.168.1.64...
Then, after several seconds, it immediately shifts to:
Press any key to continue...
That is to say, the entire Command Prompt feed is gone, it's just that message, and when I press a key Command Prompt ends. However, when I try it a second time, it goes back to the telnet interface, and I see this:

Connecting To 192.168.1.64...

Connection to host lost.

Furthermore, I get this message on the feed from FOnlineServer.exe, which was running at the time, obviously.

[Logic][08:40:804] FOServer:rocess - Connection timeout, client kicked, maybe bot. Ip<192.168.1.81>.

Then, I tried "open 109.152.194.209 [my current external IP] 4000", and I received:
Connecting To 109.152.194.209...Could not open connection to the host, on port 4000
000: Connect failed

After this, I try netstat.

Active Connections

Proto Local Address Foreign Address State
TCP 25.157.156.248:5357 x-PC:52132 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52135 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52137 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52142 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52147 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52149 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52157 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52158 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52164 TIME_WAIT
TCP 25.157.156.248:5357 x-PC:52166 TIME_WAIT
TCP 25.157.156.248:59564 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59565 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59566 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59567 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59580 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59581 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59582 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59584 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59585 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59586 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59587 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59588 x-PC:wsd TIME_WAIT
TCP 25.157.156.248:59589 x-PC:wsd TIME_WAIT
TCP 192.168.1.64:4000 My_Laptop:activesync TIME_WAIT
TCP 192.168.1.64:49157 212.118.234.69:12975 ESTABLISHED
TCP 192.168.1.64:50082 ivfn:http ESTABLISHED
TCP 192.168.1.64:50091 ivfn:http ESTABLISHED
TCP 192.168.1.64:58596 213.123.84.73:http ESTABLISHED
TCP 192.168.1.64:59124 lhr08s01-in-f0:https ESTABLISHED
TCP 192.168.1.64:59405 gamer:http TIME_WAIT
TCP 192.168.1.64:59419 channelproxy-shv-07-ash2:https ESTABLISHED
TCP 192.168.1.64:59421 178.236.6.19:https TIME_WAIT
TCP 192.168.1.64:59422 178.236.6.19:https TIME_WAIT
TCP 192.168.1.64:59423 178.236.6.19:https TIME_WAIT
TCP 192.168.1.64:59471 lhr08s01-in-f14:http ESTABLISHED
TCP 192.168.1.64:59486 213.120.177.138:http TIME_WAIT
TCP 192.168.1.64:59487 213.120.177.138:http TIME_WAIT
TCP 192.168.1.64:59488 213.120.177.138:http TIME_WAIT
TCP 192.168.1.64:59491 213.120.177.138:http TIME_WAIT
TCP 192.168.1.64:59568 lhr08s01-in-f23:https ESTABLISHED
TCP 192.168.1.64:59583 edge-star-shv-05-lhr2:https ESTABLISHED

x-PC is my friend's PC, I believe, as I recognise the PC name on the Hamachi network. Harmless enough, I think, as I had Hamachi running at the time.
My_Laptop is my laptop's name, I just changed both these names for privacy's sake.

After all of this, I check my router settings, and FOnline-TCP and FOnline-UDP are both there.

 

[_michaelm]

So, first, I tried "open 192.168.1.64 4000" from my laptop. It begins with:
Connecting To 192.168.1.64...
Then, after several seconds, it immediately shifts to:
Press any key to continue...

Good, that's what should happen - the connection was successful, but since there isn't any command line interface to that application it just terminates after the first 'command' is entered

That is to say, the entire Command Prompt feed is gone, it's just that message, and when I press a key Command Prompt ends. However, when I try it a second time, it goes back to the telnet interface, and I see this:

Connecting To 192.168.1.64...

Connection to host lost.

Not a problem either, the telnet session appears over the top of your command prompt session, so when that disappears all you're left with is the output that actually went to the command window (Connecting to... and Connection to host lost). The 'press any key..' message is within the telnet session so that would disappear.

Furthermore, I get this message on the feed from FOnlineServer.exe, which was running at the time, obviously.

[Logic][08:40:804] FOServer:rocess - Connection timeout, client kicked, maybe bot. Ip<192.168.1.81>.

That sounds like a reasonable defense mechanism against a telnet connection, the important thing is if you were connecting from 192.168.1.81 then you got through to your server without issue.

Then, I tried "open 109.152.194.209 [my current external IP] 4000", and I received:
Connecting To 109.152.194.209...Could not open connection to the host, on port 4000
000: Connect failed

This still definitely sounds like problems with the port forwarding.. without actually having one to try with myself I'm not sure I can help much more with that, what you've described should be sufficient to connect. Check the firewall rules on the router (assuming it has some) and temporarily disable those to confirm it isn't blocking part of your connection.

The rest of your netstat looks fine, as you'd expect there are no connection records there but since your remote attempt didn't succeed then that's not surprising.

 

[hmuk]

I tried to get my friend to connect to the server with my router firewall disabled... to no avail. Is there a better test to see if it's the router's firewall that's responsible?

Also, my friend suggested that I used a port that is guaranteed to be open, rather than 4000? Is this a good idea, and if so, do you have any suggestions?