1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tomato 1.28-port forwarding-RDC

Discussion in 'Tomato Firmware' started by Kigor, Jun 24, 2012.

  1. Kigor

    Kigor Networkin' Nut Member

    Hi,
    I have on Linksys model WRT54GL Tomato 1.28 firmware.
    I look to made external Remote desktop connection.

    Looking instruction I go to Port forwarding, in Proto put TCP, on ext Ports put 3389 and on Int Address, i put addres of local PC with static address. And save it.

    Then out of my LAN I go to RDC and write external static IP address (received from Status-Overview-WAN-IP address) and add in the end ":3389".

    But I can't made Remote desktop connection. What I do wrong
     
  2. koitsu

    koitsu Network Guru Member

    1. I can assure you that port forwarding works, specifically for RD/Terminal Services (TCP port 3389). I've used it for 6+ years on Tomato/TomatoUSB without issues.

    2. If the external port number is the same as the internal port number, you do not need to specify the internal port number. This is described on the web page; I'm not sure why people don't read this stuff. It doesn't hurt if you enter it anyway, but there's no point in doing so.

    I've included a screenshot (see attachment below) to verify both of the above points and show you exactly what the forwarding should look like. And here's further validation that the forward works fine -- done from a UNIX machine out on the Internet:

    Code:
    $ telnet koitsu.dyndns.org 3389
    Trying 67.180.84.87...
    Connected to koitsu.dyndns.org.
    Escape character is '^]'.
    ^]
    telnet> close
    Connection closed.
    So you're left wondering: "what's the problem then?" The problem is almost certainly that the Windows machine you're sending RD/TS traffic to (e.g. the machine on your LAN) has the Windows Firewall enabled, and thus you need to permit the port there as well. And that is not a TomatoUSB problem.
     

    Attached Files:

  3. Kigor

    Kigor Networkin' Nut Member

    Hi,
    thanks for your replay. It's seems I made all correct but still something stop it.
    I have on this tested PC disabled windows firewall and I also disabled comple Eset smart security. Not have any other firewall.
    But also I check open port with Open port check tool and give that 3389 is closed.
    Btw I made test this on few pc-a. Ever of course change int. address on Tomato but ever result is identic.
    Something still blocked this port
     
  4. koitsu

    koitsu Network Guru Member

    So there seems to be a degree of negligence (not understanding networking) going on here. It's understandable; people rely on "port scanners" to determine something when they don't know how to interpret those results nor what "open port" vs. "stealthed port" vs. "closed port" means. I hate those terms anyway; they're misleading.

    The only way you're going to be able to determine if packets destined to port 3389 on your router are actually being received at all is to run tcpdump on it. That will confirm if packets from the Internet are successfully arriving at the router. If they aren't, then your ISP is doing the filtering.

    You can download a tcpdump binary from here using "wget" on your router. Put the file in /tmp, and after downloading chmod 755 the binary: http://multics.minidns.net/tomato/PRECOMPILED-static/tcpdump

    The command + pcap filter string you want to use is:

    Code:
    tcpdump -i `nvram get wan_iface` -p -l -n -s 0 "tcp and port 3389"
    Once its running, have someone do what I showed you -- telnet to your WAN IP (from the Internet) to port 3389, or (possibly) run that port scanner you used. Again: these need to be run from an Internet host, not tools from your LAN/etc. Packet routing and loopback/forwarding works differently for packets coming from your LAN directed to your WAN IP (it's hard to explain, I'd rather not get into it).

    You can use ^C (Ctrl-C) to quit tcpdump.

    Below is an example of what you should see in the case that your ISP/etc. is not filtering the packets:

    Code:
    root@gw:/tmp# tcpdump -i `nvram get wan_iface` -l -n -s 0 "tcp and port 3389"
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes
    16:43:33.624011 IP 72.20.98.121.27024 > 67.180.84.87.3389: Flags [S], seq 4247184507, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 1001889627 ecr 0], length 0
    16:43:33.624495 IP 67.180.84.87.3389 > 72.20.98.121.27024: Flags [S.], seq 3210148393, ack 4247184508, win 65535, options [mss 1460,nop,wscale 3,nop,nop,sackOK], length 0
    16:43:33.642111 IP 72.20.98.121.27024 > 67.180.84.87.3389: Flags [.], ack 1, win 8212, length 0
    
    Explaining what's shown here:

    Line 1: 72.20.98.121 (my UNIX box on the Internet) initiated a TCP connection to 67.180.84.87 (my TomatoUSB router, which has TCP port 3389 forwarded like in the screenshot I showed you) on port 3389. "Flags S" means TCP SYN (initiate new connection).

    Between lines 1 and 2, given the port forward I have in place, the router itself is actually doing NAT and sending this packet (though re-written) to the machine on my LAN (192.168.1.50). The LAN machine (Windows XP) responds, which brings me to:

    Line 2: 67.180.84.87 responds to 72.20.98.121 with "Flags S." (note the dot) which means SYN+ACK (acknowledge SYN request). This response has the router's IP address in it, but since NAT is involved, the SYN+ACK is actually coming from the Windows XP machine. Starting to understand why "port scanners" are often misleading?

    Line 3: 72.20.98.121 responds to the SYN+ACK from 67.180.84.87 with "Flags ." which means TCP ACK.

    From that point on packets flow normally, RD works, blah blah. What you see in those 3 lines above is a standard 3-way TCP handshake for a new connection. And that is what you're looking for.

    If all you end up seeing is the equivalent of Line 1, but not Line 2 or 3, then what this means is that either the port forward in TomatoUSB isn't working (extremely unlikely), or your Windows machine has a firewall or some kind of filtering on it. Or possibly you have the LAN IP in the port forwarding field wrong. Take your pick.
     
  5. shadowken

    shadowken Networkin' Nut Member

    @ Kigor
    Have you enabled RDP service on your desktop ?
     
  6. Kigor

    Kigor Networkin' Nut Member

    Sorry slow replay. In thr end problem was on server and service. Now all work opn port for web applicatin and for remote desktop. Big thans to you all.
    One more question.
    It is possibe to made disk mapping.
    I know is possible open port for FTP, but to map disk?
     

Share This Page