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

Port forwarding not working on ASUS RT-N66U

Discussion in 'Tomato Firmware' started by jan_asus_swe, Sep 9, 2012.

  1. jan_asus_swe

    jan_asus_swe Connected Client Member

  2. koitsu

    koitsu Network Guru Member

    1. Ensure your machine has the same IP address what you put in the GUI.
    2. Disable any firewall running on your machine. This is usually what the root cause is.
  3. jan_asus_swe

    jan_asus_swe Connected Client Member

    That is not the problem I have done port forwarding on many routers using stock firmware and dd-wrt but this router with tomato is not working, i have a Linux machine on port 22 on my LAN which is accessed from internet using 443 and I even tried putting that machine in DMZ accessing diectly to port 22.....but NO luck.
  4. mstombs

    mstombs Network Guru Member

    Are you testing from the internet or another machine on your lan? If from lan check the setting for local NAT loopback in router firwall - default is 'forwarded only".
  5. koitsu

    koitsu Network Guru Member

    You didn't happen to enable HTTPS / SSL support in Tomato for the GUI, and enable Remote Access, did you? If so, this would explain the conflict (connection to your router's WAN IP on TCP port 443 would be to the Tomato GUI itself, not your Linux box on TCP port 22).

    I can assure you with absolute 100% certainty that the port forwarding in Tomato and TomatoUSB works correctly. I forward similar ports (including different source and destination ports, and for SSH) on my own network to my FreeBSD machines without issue.

    Furthermore, if you can do a telnet validation test from the Tomato router (via CLI), e.g. telnet linuxmachineip 22 to verify you get back an OpenSSH or Dropbear header string, then that's good. If that works, please provide full output from the iptables --list -v command via Tomato CLI so I can see what's going on. Please be sure to enclose the output in a code block here on the forum to retain formatting.
  6. jan_asus_swe

    jan_asus_swe Connected Client Member

    No I did not enable remote GUI access i only gave fixed IP to a server PC and have some important ports forwaraded to it and some other equipment with access from the internet.
    Why did not even putting my server on DMZ enable SSH directly?
  7. jan_asus_swe

    jan_asus_swe Connected Client Member

    Now I have cycled thru Tomato - dd-wrt - Latest ASUS stock firmware and none is working with port forwarding....yes I know what I'm doing, broken hardware?
    It works fine as a wireless router....but thats it.
  8. koitsu

    koitsu Network Guru Member

    Likelihood of it being "broken hardware" = 0%. Port forwarding is done purely 100% within software (the Linux kernel + firewalling stack). Tomato, DD-WRT, and the latest Asus stock firmware all use different Linux kernels too. I can assure you all of those firmwares do port forwarding just fine.

    Can you answer mstombs' question? How exactly are you testing the port forward (from where and to where)? Are you absolutely certain your ISP is not doing filtering of their own upstream (this is fairly common on most ISPs within the US and EU; EU also has some ISPs which delegate customers NAT'd IPs, e.g. they give you a 192.168.x.x address as your Internet IP, which makes port forwarding impossible). Stuff to consider.

    I am happy to help you as much as I can, but you're not giving enough technical information to actually assist in the process. Just a lot of "when I do this it doesn't work", without any technical details. Increase verbosity please. :)
  9. koitsu

    koitsu Network Guru Member

    BTW, one other idea: given that you've changed back and forth between 3 different firmwares (stock, DD-WRT, and Tomato), have you done a thorough NVRAM erase? If so this may explain some of the oddities (leftover NVRAM variables or variables which use different syntaxes between different firmwares):

    http://www.linksysinfo.org/index.ph...orial-and-discussion.28349/page-3#post-138676

    In Tomato, doing this is simple: Administration -> Configuration -> Restore Default Configuration -> Erase all data in NVRAM memory (thorough)

    Doing a "normal" erase does not do the same thing.

    Be aware this will wipe out all configuration changes you've made to the router, so you may need to write down the changes you've made first. Do not use the Backup Configuration feature, otherwise the aforementioned leftover NVRAM variables or different-syntax variables will be restored upon configuration restoration.
  10. jan_asus_swe

    jan_asus_swe Connected Client Member

    OK I'm back on Tomato :)
    I'm currently running my N66U without any internet connection due to that I'm running to some services which can't be interupted until late midnight, testing will be done offline until then.

    My N66U is now with "clean" NVRAM.

    I did some port forwards like 443 -> 22 and was trying to display this with iptables but I really have not worked with iptables, is it really possible to see my forwards using iptables?

    And yes I have a "real" public IP address.

    I have been doing some tests using my iPhone with an SSH client, and I also have a Pingdom.com account checking that my internet connection is up using my SSH port, and I have some other more important port/services running.
    I also used directly my public IP adress not only my dyndns domain name.

    I did notice that on my local LAN the port forwarding workes.
  11. jan_asus_swe

    jan_asus_swe Connected Client Member

    I suddenly see a line in my GUI "iptables-restore: line 37 failed" this I also was seeing last try with Tomato, what is that?
  12. koitsu

    koitsu Network Guru Member

    Port forwarding doesn't apply to devices on your LAN (e.g. 192.168.1.10 trying to reach 192.168.1.58 port 443). Port forwarding only applies to WAN -> LAN (e.g. someone connecting to public IP address 1.2.3.4 port 443, which gets redirected to 192.168.1.12 port 443).

    Your statement in itself seems to indicate you don't understand port forwarding concepts or some basic networking concepts. I say this politely, not rudely.

    I've already told you how you can view the iptables list (including your port forwards). It's in an earlier post (please read it slowly and in full): http://www.linksysinfo.org/index.ph...ot-working-on-asus-rt-n66u.40601/#post-189806

    I cannot explain the error you're seeing in the Tomato log, but I would say that's a possible explanation.

    This is looking to be a PEBKAC issue; until actual technical details are provided vs. "generic statements" it's not going to be possible to solve.
  13. kthaddock

    kthaddock Addicted to LI Member

    You can se that behave when you install new program and added iptables rule and yet have booted your router.
  14. jan_asus_swe

    jan_asus_swe Connected Client Member

    I know the concept of port forwarding and have been using this with 2 different Buffalo routers running dd-wrt and now ASUS RT-N56U without ANY problems but now with the N66U no luck.
    Ok I have to ask in another forum then if you think i'm a beginner.
  15. jan_asus_swe

    jan_asus_swe Connected Client Member

    If I create some Port Forwards in the Tomato GUI how should that look like using iptables --list -v command?
    I would like to doublecheck the GUI.
  16. jan_asus_swe

    jan_asus_swe Connected Client Member

    Code:
    Tomato v1.28.0000 MIPSR2-101 K26 USB Mega-VPN-64K
    root@unknown:/tmp/home/root#
    root@unknown:/tmp/home/root# iptables --list -v
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination       
        0    0 DROP      all  --  any    any    anywhere            anywhere            state INVALID
      275 27514 ACCEPT    all  --  any    any    anywhere            anywhere            state RELATED,ESTABLISHED
        1    64 shlimit    tcp  --  any    any    anywhere            anywhere            tcp dpt:ssh state NEW
        0    0 ACCEPT    all  --  lo    any    anywhere            anywhere           
      271 18765 ACCEPT    all  --  br0    any    anywhere            anywhere           
        0    0 ACCEPT    udp  --  any    any    anywhere            anywhere            udp spt:bootps dpt:bootpc
     
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination       
        0    0            all  --  any    any    anywhere            anywhere            account: network/netmask: 192.168.0.0/255.255.255.0 name: lan
        0    0 ACCEPT    all  --  br0    br0    anywhere            anywhere           
        0    0 DROP      all  --  any    any    anywhere            anywhere            state INVALID
        0    0 TCPMSS    tcp  --  any    any    anywhere            anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
        0    0 ACCEPT    all  --  any    any    anywhere            anywhere            state RELATED,ESTABLISHED
        0    0 wanin      all  --  vlan2  any    anywhere            anywhere           
        0    0 wanout    all  --  any    vlan2  anywhere            anywhere           
        0    0 ACCEPT    all  --  br0    any    anywhere            anywhere           
     
    Chain OUTPUT (policy ACCEPT 523 packets, 117K bytes)
    pkts bytes target    prot opt in    out    source              destination       
     
    Chain shlimit (1 references)
    pkts bytes target    prot opt in    out    source              destination       
        1    64            all  --  any    any    anywhere            anywhere            recent: SET name: shlimit side: source
        0    0 DROP      all  --  any    any    anywhere            anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
     
    Chain wanin (1 references)
    pkts bytes target    prot opt in    out    source              destination       
     
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination       
    
    Below display is from Tomato GUI, but not that easy to follow.
    Code:
    Port Forwarding
    On    Proto    Src Address    Ext Ports    Int Port    Int Address    Description
    On    Both        443    22    192.168.0.5    SSH
        UDP        1000,2000        192.168.1.2    ex: 1000 and 2000
        Both        1000-2000,3000        192.168.1.2    ex: 1000 to 2000, and 3000
        Both    1.1.1.0/24    1000-2000        192.168.1.2    ex: 1000 to 2000, restricted
        TCP        1000    2000    192.168.1.2    ex: different internal port
  17. koitsu

    koitsu Network Guru Member

    1. Your iptables rules do not indicate there is any port forward in place. On TomatoUSB port forwarding rules end up in the "wanin" chain. I will show you evidence of this momentarily.

    2. The root cause, as I see it, is that you have tried to forward port 443 (which should be TCP BTW, not "Both" -- SSH is purely a TCP protocol) to address 192.168.0.5 port 22. Normally (by default) TomatoUSB assigns the router an IP address of 192.168.1.1 (specifically: part of the 192.168.1.0/24 netblock).

    Can you please shed some light on what all you have changed in your router GUI? I'm talking about *every single setting* you've changed. It looks like you've changed the IP address of the router itself. Is that the case?

    If it isn't the case, then the answer is clear: you are trying to forward packets to a LAN address which is outside of the scope of your network block.

    For example, if your network block is 192.168.1.0/24 (e.g. 192.168.1.*), there is no possible way the router will be able to forward packets to a machine on a network block outside of that range -- 192.168.0.5 is not part of 192.168.1.0/24. Understand?

    What you should be seeing with iptables is something like this (note the wanin chain rules):

    Code:
    root@gw:/tmp/home/root# iptables --list -v -n
    Chain INPUT (policy DROP 290 packets, 16507 bytes)
    pkts bytes target    prot opt in    out    source              destination
    4039  402K DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    113K  18M ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
      234 16925 ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0
    178K  14M ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0
    796K  51M ACCEPT    icmp --  *      *      0.0.0.0/0            0.0.0.0/0
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpts:33434:33534
    66398  23M ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp spt:67 dpt:68
     
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination
    2490  237K ACCEPT    all  --  br0    br0    0.0.0.0/0            0.0.0.0/0
    1328  162K DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    343K  18M TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU
      74M  47G ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
    55294 4382K wanin      all  --  vlan2  *      0.0.0.0/0            0.0.0.0/0
    535K  37M wanout    all  --  *      vlan2  0.0.0.0/0            0.0.0.0/0
    535K  37M ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0
    38532 3558K upnp      all  --  vlan2  *      0.0.0.0/0            0.0.0.0/0
     
    Chain OUTPUT (policy ACCEPT 55365 packets, 6237K bytes)
    pkts bytes target    prot opt in    out    source              destination
     
    Chain upnp (1 references)
    pkts bytes target    prot opt in    out    source              destination
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.199      udp dpt:65459
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.199      udp dpt:50990
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.199      udp dpt:50228
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.199      udp dpt:55140
        0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.199      udp dpt:63895
    2163  199K ACCEPT    udp  --  *      *      0.0.0.0/0            192.168.1.50        udp dpt:17704
      297 15888 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.1.50        tcp dpt:17704
     
    Chain wanin (1 references)
    pkts bytes target    prot opt in    out    source              destination
      48  2740 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.1.51        tcp dpt:113
        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.1.51        tcp dpt:22
    16714  822K ACCEPT    tcp  --  *      *      0.0.0.0/0            192.168.1.50        tcp dpt:3389
     
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination
    
    The above rules in the wanin chain correlate with this in the GUI:

    Code:
    Port Forwarding ->
      Basic ->
        On    TCP    <blank>    113    <blank>        192.168.1.51    icarus - identd
        On    TCP    <blank>    6502    22          192.168.1.51    icarus - sshd
        On    TCP    <blank>    3389    <blank>        192.168.1.50    koitsu - RDP
    
    I don't know how to get iptables to "properly" show forwards which change source port numbers (e.g. the rule for TCP port 6502 going to 192.168.1.51 port 22). But you can see the wanin chain rule for it ("tcp dpt:22"), and you can see that it does in fact work. Testing from an Internet host:

    Code:
    $ telnet 67.180.84.87 6502
    Trying 67.180.84.87...
    Connected to 67.180.84.87.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
    ^]
    telnet> close
    Connection closed.
    
    I recommend you restore to factory defaults (NVRAM erase; don't need to do a thorough erase) and then use the default network block (192.168.1.0/24, with the router being 192.168.1.1) and then try your port forwards to an IP on your network that's 192.168.1.x.

    Otherwise, if you HAVE renumbered the network/router, then you need to provide full technical details of what it is you're doing / your network topology (physical devices and all netblocks).
  18. USNetboy

    USNetboy Reformed Router Member

    @koitsu, The reason you do not see the complete port forwarding rules is that you look at the wrong table. The default table (and the one you look at) is the filter table. The forward chain rules you state in your post are there to allow netfilter to filter packets that are not destined to the firewall interface itself. In Tomato (while configured for NAT on the WAN interface) port-forwarding is done in the WANPREROUTING chain in the nat table. To view that table use:

    Code:
    iptables -t nat -L WANPREROUTING -vn
    koitsu likes this.
  19. jan_asus_swe

    jan_asus_swe Connected Client Member

    Yes my LAN is using 192.168.0.x addresses and my router is of course 192.168.0.1 and that is the only thing I have changed.
  20. koitsu

    koitsu Network Guru Member

    Thank you -- I had no idea about the tables part! This is just more evidence of my lack of familiarity with Linux compared to FreeBSD. :) I then became curious how you knew the table name was "nat", i.e. "how do I get a list of tables?" Simple enough: cat /proc/net/ip_tables_names
  21. koitsu

    koitsu Network Guru Member

    Can you please run iptables --table nat --list -v -n instead? (Thanks to USNetboy for pointing me to this; as my previous post said I had no idea about the different tables).

    For the record and comparison, my router (same device/forwards as shown in my above post):

    Code:
    root@gw:/tmp/home/root# iptables --table nat --list -v -n
    Chain PREROUTING (policy ACCEPT 30187 packets, 2404K bytes)
    pkts bytes target    prot opt in    out    source              destination
        0    0 DROP      all  --  vlan2  *      0.0.0.0/0            192.168.1.0/24
    938K  61M WANPREROUTING  all  --  *      *      0.0.0.0/0            67.180.84.87
    91176 7221K upnp      all  --  *      *      0.0.0.0/0            67.180.84.87
     
    Chain POSTROUTING (policy ACCEPT 6206 packets, 850K bytes)
    pkts bytes target    prot opt in    out    source              destination
    343K  24M MASQUERADE  all  --  *      vlan2  0.0.0.0/0            0.0.0.0/0
    2330  174K SNAT      all  --  *      br0    192.168.1.0/24      192.168.1.0/24      to:192.168.1.1
     
    Chain OUTPUT (policy ACCEPT 7445 packets, 958K bytes)
    pkts bytes target    prot opt in    out    source              destination
     
    Chain WANPREROUTING (1 references)
    pkts bytes target    prot opt in    out    source              destination
    827K  53M DNAT      icmp --  *      *      0.0.0.0/0            0.0.0.0/0          to:192.168.1.1
      52  2984 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:113 to:192.168.1.51
        2  120 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:6502 to:192.168.1.51:22
    20226  992K DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:3389 to:192.168.1.50
     
    Chain upnp (1 references)
    pkts bytes target    prot opt in    out    source              destination
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:65459 to:192.168.1.199:65459
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:50990 to:192.168.1.199:50990
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:50228 to:192.168.1.199:50228
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:55140 to:192.168.1.199:55140
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:63895 to:192.168.1.199:63895
    2581  241K DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:17704 to:192.168.1.50:17704
      325 17376 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:17704 to:192.168.1.50:17704
    
    There should be "matching entries" (for lack of better term) in the nat table as in the filter table. To be more specific, see WANPREROUTING in the above output, then compare that to what's shown here:

    Code:
    root@gw:/tmp/home/root# iptables --list wanin -v -n
    Chain wanin (1 references)
     pkts bytes target     prot opt in     out     source               destination
       52  2984 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.51        tcp dpt:113
        2   120 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.51        tcp dpt:22
    20317  997K ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.50        tcp dpt:3389
    
  22. jan_asus_swe

    jan_asus_swe Connected Client Member

    Code:
    root@unknown:/tmp/home/root# iptables -t nat -L WANPREROUTING -vn
    Chain WANPREROUTING (0 references)
    pkts bytes target    prot opt in    out    source              destination       
    root@unknown:/tmp/home/root# 
    Code:
    root@unknown:/tmp/home/root# iptables --table nat --list -v -n
    Chain PREROUTING (policy ACCEPT 3769 packets, 263K bytes)
    pkts bytes target    prot opt in    out    source              destination       
        0    0 DROP      all  --  vlan2  *      0.0.0.0/0            192.168.0.0/24     
     
    Chain POSTROUTING (policy ACCEPT 2 packets, 656 bytes)
    pkts bytes target    prot opt in    out    source              destination       
        0    0 MASQUERADE  all  --  *      vlan2  0.0.0.0/0            0.0.0.0/0         
        6  1772 SNAT      all  --  *      br0    192.168.0.0/24      192.168.0.0/24      to:192.168.0.1
     
    Chain OUTPUT (policy ACCEPT 8 packets, 2428 bytes)
    pkts bytes target    prot opt in    out    source              destination       
     
    Chain WANPREROUTING (0 references)
    pkts bytes target    prot opt in    out    source              destination       
    root@unknown:/tmp/home/root#
    Sorry stupid question but should Port Forwarding be enabled somewhere else?
  23. jan_asus_swe

    jan_asus_swe Connected Client Member

    Same command on my ASUS RT-N56U running latest stock firmware.....seems ok :)

    Sorry x out my WAN address.

    Code:
    # iptables --table nat --list -v -n
    Chain PREROUTING (policy ACCEPT 46M packets, 62G bytes)
    pkts bytes target    prot opt in    out    source              destination       
    25539 2470K VSERVER    all  --  *      *      0.0.0.0/0            xx.xxx.xxx.x      
     
    Chain POSTROUTING (policy ACCEPT 27856 packets, 2304K bytes)
    pkts bytes target    prot opt in    out    source              destination       
    45287 2960K MASQUERADE  all  --  *      eth3  !xx.xxx.xxx.x        0.0.0.0/0         
    1272  250K MASQUERADE  all  --  *      br0    192.168.0.0/24      192.168.0.0/24     
     
    Chain OUTPUT (policy ACCEPT 13576 packets, 1299K bytes)
    pkts bytes target    prot opt in    out    source              destination       
     
    Chain VSERVER (1 references)
    pkts bytes target    prot opt in    out    source              destination       
        0    0 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:554 to:192.168.0.136:80
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:554 to:192.168.0.136:80
      11  704 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:8000 to:192.168.0.210:80
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:8000 to:192.168.0.210:80
      20  1280 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:8001 to:192.168.0.210:8001
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:8001 to:192.168.0.210:8001
    3023  181K DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:443 to:192.168.0.5:22
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:443 to:192.168.0.5:22
    5945  462K DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:10001 to:192.168.0.5:11114
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:10001 to:192.168.0.5:11114
    4055  314K DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:10000 to:192.168.0.5:11113
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:10000 to:192.168.0.5:11113
      103  5824 DNAT      tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:80 to:192.168.0.210:80
        0    0 DNAT      udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:80 to:192.168.0.210:80
    1198  139K DNAT      udp  --  eth3  *      0.0.0.0/0            0.0.0.0/0          udp dpt:1052 to:192.168.0.70:1052
      50  2884 DNAT      tcp  --  eth3  *      0.0.0.0/0            0.0.0.0/0          tcp dpt:1052 to:192.168.0.70:1052
        0    0 DNAT      udp  --  eth3  *      0.0.0.0/0            0.0.0.0/0          udp dpt:5353 to:192.168.0.70:5353
        0    0 DNAT      udp  --  eth3  *      0.0.0.0/0            0.0.0.0/0          udp dpt:4500 to:192.168.0.70:4500
    #
    
  24. koitsu

    koitsu Network Guru Member

    This almost looks like some kind of very odd firmware bug. I've done all I can with this quite honestly; your forwarding rules, simply put, aren't being put into iptables anywhere. I cannot explain that behaviour.

    The TomatoUSB firmware I use is Toastman's -- specifically tomato-K26USB-1.28.00500.2MIPSR2Toastman-RT-N-VPN.trx -- and the router I use is an Asus RT-N16.

    I'm going to make Shibby aware of this thread + ask him politely to comment + assist from here on out. I do not have an explanation for what is going on.

    And no, in all the TomatoUSB builds I've seen, there's only one place for port forwards -- Port Forwarding -> Basic. If there is something unique in Shibby's firmware I'm not familiar with it (and that's my own lack of familiarity with his builds, not his fault. :) ).
  25. koitsu

    koitsu Network Guru Member

    Brief follow-up: I did send Shibby a PM. He's certainly busy with real life, but I'm sure he'll peek at the thread when he has time. :)
  26. shibby20

    shibby20 LI Guru Member

    did you try use different port than 443? i believe this port is reserved (used) by httpd. I also have rt-n66u weith my tomato v101 + static ip and port forwarding works correct.

    this is the problem. Show us /etc/iptables and /etc/iptables.error files.
  27. jan_asus_swe

    jan_asus_swe Connected Client Member

    Hi shibby.
    No why would port 443 be busy?
    I'm not using web GUI access via https and especially not remote.

    Code:
    root@unknown:/tmp/home/root# cat /etc/iptables
    *mangle
    :PREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    *nat
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :WANPREROUTING - [0:0]
    -A PREROUTING -i vlan2 -d 192.168.0.1/255.255.255.0 -j DROP
    -A POSTROUTING  -o vlan2 -j MASQUERADE
    -A POSTROUTING -o br0 -s 192.168.0.1/255.255.255.0 -d 192.168.0.1/255.255.255.0 -j SNAT --to-source 192.168.0.1
    COMMIT
    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -N shlimit
    -A shlimit -m recent --set --name shlimit
    -A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j DROP
    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    -A INPUT -i lo -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
    :FORWARD DROP [0:0]
    -A FORWARD -m account --aaddr 192.168.0.0/255.255.255.0 --aname lan
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i vlan2 -j wanin
    -A FORWARD -o vlan2 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    COMMIT
    root@unknown:/tmp/home/root# 
    And perhaps this.

    Code:
    root@unknown:/tmp/home/root# netstat -a -n
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address          Foreign Address        State     
    tcp        0      0 192.168.0.1:80          0.0.0.0:*              LISTEN     
    tcp        0      0 0.0.0.0:53              0.0.0.0:*              LISTEN     
    tcp        0      0 0.0.0.0:22              0.0.0.0:*              LISTEN     
    tcp        0      0 192.168.0.1:22          192.168.0.41:4287      ESTABLISHED
    tcp        0      0 :::53                  :::*                    LISTEN     
    tcp        0      0 :::22                  :::*                    LISTEN     
    tcp        0      0 :::23                  :::*                    LISTEN     
    tcp        0      0 ::ffff:192.168.0.1:23  ::ffff:192.168.0.47:59518 ESTABLISHED
    udp        0      0 0.0.0.0:53              0.0.0.0:*                         
    udp        0      0 0.0.0.0:67              0.0.0.0:*                         
    udp        0      0 :::53                  :::*                               
    raw        0      0 0.0.0.0:255            0.0.0.0:*              255       
    Active UNIX domain sockets (servers and established)
    Proto RefCnt Flags      Type      State        I-Node Path
    unix  6      [ ]        DGRAM                      5289 /dev/log
    unix  2      [ ]        DGRAM                    55481
    unix  2      [ ]        DGRAM                      5755
    unix  2      [ ]        DGRAM                      5739
    unix  2      [ ]        DGRAM                      5291
    unix  2      [ ]        DGRAM                      1315
    root@unknown:/tmp/home/root#
    
  28. Monk E. Boy

    Monk E. Boy Addicted to LI Member

    I can't speak to your setup, but in the US normal "server" ports like 25, 80, and 443 are commonly blocked by ISPs when running on consumer (home) connections.

    But since it sounds like you have two routers and one's working and the other isn't, it's a bit baffling. You could try a nonstandard high-numbered port, like 12345, and see if the problem still occurs. I would bet it will, but at least it would remove a couple possible stumbling blocks.
  29. jan_asus_swe

    jan_asus_swe Connected Client Member

    Thanks to the great support but as I said I'm not able to hassle to much with my internet connection so I'm not able to make so many test, I have to wait for the weekend to come to do that.
    In Sweden I don't know of any restrictions regarding ports to use or not to use.
    Is there another Tomato version that is known to work WELL on the N66U?

    But why don't I even see my Forwards?
  30. jan_asus_swe

    jan_asus_swe Connected Client Member

    Perhaps I should make a NVRAM cleanup and start from scratch?
    If so what to do and check and see that it works?
  31. jan_asus_swe

    jan_asus_swe Connected Client Member

  32. Monk E. Boy

    Monk E. Boy Addicted to LI Member

    The reason it doesn't work is because something somewhere has gone wrong. If you/we can figure out what it is then we can make headway.

    I've had quirky flashes sometimes where I needed to switch from a stock firmware to DD-WRT, wipe the NVRAM in DD-WRT, perform a 30-30-30 reset, then flash to Tomato, then wipe the NVRAM, then perform a 30-30-30 reset, and only then was everything perfect. However with ASUS routers the last -30 doesn't really do much besides put the router in recovery mode (when you hold down the setup button, apply power, and keep holding down the setup button ASUS routers go into recovery mode)

    Speaking of which... how did you perform the initial flash of the RT-N66? Was it from recovery mode, or through the management website?
  33. shibby20

    shibby20 LI Guru Member

    I need iptables.error
  34. jan_asus_swe

    jan_asus_swe Connected Client Member

    First time i flashed using recovery mode or basically all except last which was a different Tomato version.
  35. jan_asus_swe

    jan_asus_swe Connected Client Member

    Could not find any such file, where should it be located if exist?
  36. jan_asus_swe

    jan_asus_swe Connected Client Member

    So back on stock ASUS RT-N66U_3.0.0.4_220 firmware and now I have found a bug.
    If i add my "own" forward it is never seen in the tables using iptables --table nat --list -v -n BUT if I select one of the "famous game list" forwards like Counter Strike(TCP) and press apply it does not save that forward but it enables mine.
    So could you please explain that "workaround"?
    Is this something to report to ASUS about?
  37. jan_asus_swe

    jan_asus_swe Connected Client Member

    Did a reboot to test the workaround and the forwards where gone again, but with a Counter Strike workaround it was back :(
  38. koitsu

    koitsu Network Guru Member

    For Asus firmware issues you should always report those to Asus; their stuff is unrelated to TomatoUSB.

    I wonder if the problem is somehow browser or Javascript-related, like the form data isn't getting submit correctly or is being munged somehow. That's the only commonality I can think of that might explain an oddity like this, especially between two unrelated firmwares (TomatoUSB and the stock Asus firmware).

    Can you disclose what browser you're using and try using some alternates to see if the same problem happens? If you're using addons for the browser, please disable all of those as well to rule out compatibility issues of that sort (things like NoScript etc. mess with JS). If it still happens I'm left wondering if the issue is, somehow, some kind of bug in some code somewhere pertaining to the changing of the netblock from 192.168.1.0/24 to 192.168.0.0/24.
  39. tallanvor

    tallanvor Network Newbie Member

    Specs:
    Asus RT-N16
    Tomato 102 Mega - shibby20 MIPRS2.

    I can confirm that this issue has been observed on my router after flashing to the above firmware. I believe we can safely rule out a browser configuration issue (tested with Internet Explorer 9 and 10 on 2 different workstations using the following browsers: Firefox, Chrome beta, Maxthon etc. in Windows; normal and safe mode with networking enabled. Browsers were operating with default settings and where possible, with addons disabled.

    In relation to shibby20's request, I did not see any error message when executing the portforwarding rules from the GUI or manually, and therefore no iptables.error file was created. However, I did notice that a portforward entry exists when I inspected the NVRAM dump. Therefore, the issue appears to be that iptables/netfilter is not implementing the rules, or something has gone wrong with attempting to implement them. It is likely to be the former, seeing as iptables on the router does not have the rules listed anywhere.

    Here is the entry found in the NVRAM dump:
    portforward=1<2<<27005:27040<<192.168.1.2<d2>1<2<<28020:28045<<192.168.1.2<d2>1<2<<28120:28145<<192.168.1.2<d2>1<1<<2050<<192.168.1.2<d2>

    I believe whatever changed occurred with the flashing of the latest firmware and that these changes are persistent, despite clearing NVRAM and reverting to factory default settings.

    I have attempted to flash to a previous build and restore a backup of my configuration with the same firmware. Unfortunately, my iptables dump does not parse the portforwarding rules. Furthermore, other areas appear to be malfunctioning also. My Access Restrictions rules do not apply, and inputting it manually returns no errors. While the port forwarding rules aren't listed, manually inputting the access restrictions rules yielded only:
    -A rres00 -p tcp web --hore [missing entries here] -j REJECT --reject-with tcp-reset, with no listing of the keywords specified in the block list.

    Here are the relevant iptables entries for port forwarding rules that previously functioned correctly.
    -A WANPREROUTING -p udp --dport 27005:27040 -j DNAT --to-destination 192.168.1.2
    -A WANPREROUTING -p udp --dport 28020:28045 -j DNAT --to-destination 192.168.1.2
    -A WANPREROUTING -p udp --dport 28120:28145 -j DNAT --to-destination 192.168.1.2
    :wanin - [0:0]
    :wanout - [0:0]
    -A wanin -p udp -m udp -d 192.168.1.2 --dport 27005:27040 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.1.2 --dport 28020:28045 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.1.2 --dport 28120:28145 -j ACCEPT

    In my last attempt in searching for a remedy, I flashed a DD-WRT firmware - v24-13491 NEWD-2_K2.6_mini_RT_N16.trx. Both port forwarding and access restrictions appear to work. Flashing back to tomato, neither are implemented. Finally, I flashed tomato-K26-1.28.7500.4MIPSR2Toastman-RT-Std, but was unable to implement previously working configurations. Thus far it appears as though my ASUS RT-N16 running Tomato will not be working properly ever again. :(

    Please feel free to request configuration files/dumps, for I will be happy to supply them to anyone with a reasonably acceptable idea as to where to look to identify the issue. Any in-depth analysis is welcome, but please focus solely on tomato because nothing aside from Windows Updates has changed about the workstations I have been working on; Windows 7 x64 and Windows 7 x86.

    This issue may be an isolated case, but seeing as another person has observed similar behavior in the same tomato branch, I have reason to suspect it may have far reaching implications seeing as the defect has persisted across firmware flashes and clearing NVRAM and resetting to defaults hasn't alleviated the issue.

    One more thing, inputting the rules manually, that is, via Commands, only allows for the creation of new chains, but not port forwarding rules. Whatever has changed, it appears as though netfilter is not working as expected. I flashed via the ASUS Recovery utility, and also used the tomato Upgrade GUI. As I have already indicated, port forwarding and access restrictions were previously functional in shibby20's build 95-100s. I did not check 101, and after flashing to 102 had noticed the malfunction because an application I use requires the port forwarding rules to function correctly.
  40. tallanvor

    tallanvor Network Newbie Member

    Sorry for double-posting.

    Update:
    I recently flashed to a DD-WRT firmware released earlier this year (March) and it's working fine; both Access Restrictions and Port Forwarding appear to function normally with appropriate rules being added to iptables.

    Unfortunately, updating to the latest firmware in Tomato still has not resolved the issue. I will be testing with an earlier firmware in the Tomato branch and hopefully it will work again.

    I do have a question, though. Even though the issue appears similar, would it be appropriate to open a new thread seeing as this is for the RT-N16 rather than the RT-N66U?
  41. kronik

    kronik Network Newbie Member

    Hi guys, I believe I’m facing a similar issue with my RT-N16 running Tomato Firmware 1.28.0000 MIPSR2-101 K26 USB AIO fully bridged to a TP-Link TD-8817

    No matter what I do I cannot see port 80, 443, 25 and perhaps other common ports from outside my network, I checked with my ISP already and they assured me that there’s no blocking of ports on their end.

    I never tested the original ASUS firmware to see whether or not it was happening from the beginning however this issue has been around since day 1 of using version 80 or 82 of shibby’s firmware.
  42. Monk E. Boy

    Monk E. Boy Addicted to LI Member

    Have you tested to see whether you can see non-common ports from outside your network?
  43. Sarick

    Sarick Network Newbie Member

    You could setup a DMZ to something like a PS3/XBOX or something secure without an internal firewall and do a port scan with shields up to see if the ISP really is blocking ports and isn't aware of it. I did this and found a few KEY ports never reach me with the rest open. After reading a few post here I doubt it's the ISP's end if tables are getting reset. (I'm total noob to this don't laugh) but this might help you.
  44. shibby20

    shibby20 LI Guru Member

    Port forwarding will/may not works when:
    1) you have enabled DMZ
    2) you have enable logging inbound/outbound connections. Please check this on administration->logging page. And disable both options.

    Best Regards.
  45. Sarick

    Sarick Network Newbie Member

    Are you talking to me or the OP? My suggestion with DMZ was to test the isp for issues. If the ISP is blocking external ports they can't be seen on the lan even if they are forwarded correctly. I can see where the DMZ setting would conflict with forwarding. Mentioning that DMZ trick might have helped more then I expected if this is the problem.

    Could enabled UPnP or NAT-PnP what ever those are called also conflict the same way as DMZ?
  46. mstombs

    mstombs Network Guru Member

    If DMZ and/or logging break port forwarding then that is a new bug!

    Back to basics, the WAN IP is a real internet IP, not another local IP address, especially not in same range as LAN?
    The router is in "Gateway" (nat router) mode, not "Router" mode.
  47. pharma

    pharma Network Guru Member

    Port Forwarding on my RT-N66U is working fine without any extra settings ... use it about everyday for torrents.
    In case you have problems reading below:
    Src Address is blank, Ext Ports 27716, Int Port 27716 , and Int Address 192.198.1.102.








    Hope this helps!
  48. digiblur

    digiblur Reformed Router Member

    Hook the device straight up to the ISP with no router involved. See if you can hit those ports needed.

    Sent from a little old Note 2
  49. Rick Houghton

    Rick Houghton New Member Member

    I have a RT-N16 with the EXACT same issue. Started a new thread HERE...
  50. tallanvor

    tallanvor Network Newbie Member

    Good news, I flashed the most recent January release 105 by shibby20 and all is excellent :D
  51. paulbeard

    paulbeard New Member Member

    Is there a resolution here?
    I am running Tomato Firmware 1.28.0000 MIPSR2-110 K26 USB Mega-VPN-64K on an RT n66u and port forwarding is failing here as well. I get the same error on line 37 as posted but I didn't see anything that addresses that problem.

    37:FORWARD DROP [0:0]
    The whole file:
    Code:
        1    *mangle
        2    :PREROUTING ACCEPT [0:0]
        3    :OUTPUT ACCEPT [0:0]
        4    COMMIT
        5    *nat
        6    :PREROUTING ACCEPT [0:0]
        7    :POSTROUTING ACCEPT [0:0]
        8    :OUTPUT ACCEPT [0:0]
        9    :WANPREROUTING - [0:0]
        10    -A PREROUTING -d 50.132.9.251 -j WANPREROUTING
        11    -A PREROUTING -i vlan2 -d 192.168.0.1/255.255.255.0 -j DROP
        12    -A WANPREROUTING -p icmp -j DNAT --to-destination 192.168.0.1
        13    -A WANPREROUTING -p tcp  --dport 80 -j DNAT --to-destination 192.168.0.25:80
        14    -A WANPREROUTING -p udp  --dport 80 -j DNAT --to-destination 192.168.0.25:80
        15    -A WANPREROUTING -p tcp  --dport 143 -j DNAT --to-destination 192.168.0.25:143
        16    -A WANPREROUTING -p tcp  --dport 993 -j DNAT --to-destination 192.168.0.25:993
        17    -A WANPREROUTING -p tcp  --dport 25 -j DNAT --to-destination 192.168.0.25:25
        18    :upnp - [0:0]
        19    -A PREROUTING -d 50.132.9.251 -j upnp
        20    -A POSTROUTING -p ! 41 -o vlan2 -j MASQUERADE
        21    -A POSTROUTING -o br0 -s 192.168.0.1/255.255.255.0 -d 192.168.0.1/255.255.255.0 -j SNAT --to-source 192.168.0.1
        22    COMMIT
        23    *filter
        24    :INPUT DROP [0:0]
        25    :OUTPUT ACCEPT [0:0]
        26    -A INPUT -m state --state INVALID -j DROP
        27    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
        28    -N shlimit
        29    -A shlimit -m recent --set --name shlimit
        30    -A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j DROP
        31    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
        32    -A INPUT -i lo -j ACCEPT
        33    -A INPUT -i br0 -j ACCEPT
        34    -A INPUT -p icmp -s 216.218.226.238 -j ACCEPT
        35    -A INPUT -p 41 -j ACCEPT
        36    -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
        37    :FORWARD DROP [0:0]
        38    -A FORWARD -m account --aaddr 192.168.0.0/255.255.255.0 --aname lan
        39    -A FORWARD -i br0 -o br0 -j ACCEPT
        40    -A FORWARD -m state --state INVALID -j DROP
        41    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
        42    :wanin - [0:0]
        43    :wanout - [0:0]
        44    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
        45    -A FORWARD -i vlan2 -j wanin
        46    -A FORWARD -o vlan2 -j wanout
        47    -A FORWARD -i br0 -j ACCEPT
        48    :upnp - [0:0]
        49    -A FORWARD -i vlan2 -j upnp
        50    -A wanin  -p tcp -m tcp -d 192.168.0.25 --dport 80 -j ACCEPT
        51    -A wanin  -p udp -m udp -d 192.168.0.25 --dport 80 -j ACCEPT
        52    -A wanin  -p tcp -m tcp -d 192.168.0.25 --dport 143 -j ACCEPT
        53    -A wanin  -p tcp -m tcp -d 192.168.0.25 --dport 993 -j ACCEPT
        54    -A wanin  -p tcp -m tcp -d 192.168.0.25 --dport 25 -j ACCEPT
        55    COMMIT
    So of what use is the UI if there's no error checking?

    EDIT: it looks like I was able to fix it by deleting the rules, all of them, and then adding them back one by one, saving and looking for errors each time.
  52. tallanvor

    tallanvor Network Newbie Member

    The iptables-restore error on line 37 is most likely due to a change in the IP address, e.g. 192.168.1.1 (default) to 192.168.123.123 will return this error message. However, if you restart the router after applying the changes it'll load correctly, so no more error.
  53. mstombs

    mstombs Network Guru Member

  54. dccjr

    dccjr New Member Member

    Exact same problem here. Fixed by deleting the entry in Administration=>Scripts=>Firewall.
  55. Qabach

    Qabach New Member Member

    I am having no luck setting up port forwarding with Shibby. (I was also unable to do so on my previous router, which I replaced because it died.)

    Following is the output from 'iptables -L -v'

    Code:
    Chain INPUT (policy DROP 166 packets, 12931 bytes)
    pkts bytes target    prot opt in    out    source              destination       
      39  1699 DROP      all  --  any    any    anywhere            anywhere            state INVALID
      372 71784 ACCEPT    all  --  any    any    anywhere            anywhere            state RELATED,ESTABLISHED
        0    0 shlimit    tcp  --  any    any    anywhere            anywhere            tcp dpt:ssh state NEW
        1  250 ACCEPT    all  --  lo    any    anywhere            anywhere         
      271 25982 ACCEPT    all  --  br0    any    anywhere            anywhere         
      105 37989 ACCEPT    udp  --  any    any    anywhere            anywhere            udp spt:bootps dpt:bootpc
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination       
    9998 3553K            all  --  any    any    anywhere            anywhere            account: network/netmask: 192.168.1.0/255.255.255.0 name: lan
        0    0 ACCEPT    all  --  br0    br0    anywhere            anywhere         
        2  104 DROP      all  --  any    any    anywhere            anywhere            state INVALID
      574 29992 TCPMSS    tcp  --  any    any    anywhere            anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
    9460 3525K ACCEPT    all  --  any    any    anywhere            anywhere            state RELATED,ESTABLISHED
        3  192 wanin      all  --  vlan2  any    anywhere            anywhere         
      533 28343 wanout    all  --  any    vlan2  anywhere            anywhere         
      533 28343 ACCEPT    all  --  br0    any    anywhere            anywhere         
    Chain OUTPUT (policy ACCEPT 499 packets, 456K bytes)
    pkts bytes target    prot opt in    out    source              destination       
    Chain shlimit (1 references)
    pkts bytes target    prot opt in    out    source              destination       
        0    0            all  --  any    any    anywhere            anywhere            recent: SET name: shlimit side: source
        0    0 DROP      all  --  any    any    anywhere            anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
    Chain wanin (1 references)
    pkts bytes target    prot opt in    out    source              destination       
        3  192 ACCEPT    tcp  --  any    any    anywhere            TheNermalCurve      tcp dpt:1234
        0    0 ACCEPT    udp  --  any    any    anywhere            TheNermalCurve      udp dpt:1234
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination    
    I have done very little configuration since doing a thorough wipe of NVRAM.

    Does anything about this output suggest the cause of my problem?
    Please let me know if you need more information.
    Thank you.

    Edit: I am checking whether my port is open using http://www.whatsmyip.org/port-scanner/ and Windows firewall is turned off.
  56. Qabach

    Qabach New Member Member

    Update: I went back to the out-of-the-box firmware and I can't get a port open with that either, even with Windows Firewall off. The culprit here is probably my Windows desktop, not my router. Since I am not aware of having installed anything which would block ports, my next step is to install some form of Linux and do some testing from there.
  57. koitsu

    koitsu Network Guru Member

    Why don't you start by disabling the built-in Windows firewall?

    Also, many anti-virus softwares also include their own firewall (which is incredibly stupid, IMO -- yes let's have two firewall layers...), so you may need to tinker with that as well.
  58. Qabach

    Qabach New Member Member

    Thanks, koitsu. I did try disabling the built-in Windows firewall with no apparent change. Also, unless some antivirus stealth-installed itself, I don't believe I have any running.
  59. Gearhead

    Gearhead New Member Member

    Not sure if this is relevant, but I just brought home an ASUS router (RT-AC68U) to replace my degraded D-Link DIR-632. The port forwarding on the old D-Link worked just fine; I could view and interact with any of the web content, use FTP access, etc. With the new ASUS router, I set up the exact same forwarding parameters but had no luck accessing any server content. Then, I took a moment to read the "fine print" in the manual (on Page 72), which tells me this:

    ".... To check if Port Forwarding has been configured successfully:
    Ensure that your server or application is set up and running. \\ OK ... no brainer

    You will need a client outside your LAN but has Internet access (referred to as “Internet client”). This client should not be connected to the ASUS router.
    On the Internet client, use the router’s WAN IP to access the server. If port forwarding has been successful, you should be able to access the files or applications...."

    Now, I suppose I could use a web proxy to view my own content for testing and confirmation, but that seems like a pretty shabby workaround. I will be returning this router, which is fine in all other respects, because they have simply not provided me with direct, LAN-based access to my own in-house services. (Too bad.)
  60. Marcel Tunks

    Marcel Tunks Serious Server Member

    Port forwarding isn't needed to access your LAN devices from other devices in the same LAN. It can be done that way for testing purposes, but probably shouldn't be done that way routinely. The manual is describing remote access.

    There is something in your PC or router settings causing a problem. There are many possibilities. Most likely you are using a Windows machine that identified the new router as a new Internet connection and classified it as a Public network (ie. Internet access works, file sharing disabled). Fixing that depends on your Windows version. Second most likely is a Workgroup or other setting in either the PC or router.

    If you are unable to resolve the issue, and the store won't take the return, let me know. I'd be happy to take the AC68U off your hands at a small discount from retail price. ;-)

Share This Page