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

Admin Interface Remote Access - Can't connect

Discussion in 'Tomato Firmware' started by lockheed, Feb 28, 2014.

  1. lockheed

    lockheed Reformed Router Member

    I am trying to get remote access to work so that I can access the Tomato Toastman v1.28.7635 from outside my network.

    Web Admin is enabled.
    Remote Access is on HTTP:8080

    from the same computer on LAN I can access Admin Interface with the internal LAN ip:80, but not exteranal ip:8080. Nothing loads.

    It did load until an hour ago, when I was still runing Tomato RAF firmware, but since I upgraded to Toastman's, it no longer works even thoug settings are the same.

    The only thing I can think of is if Toastman introduced iptables firewall, it blocks external connections. Could that be it?

    I found identical thread here:
    http://www.linksysinfo.org/index.ph...ce-remote-access-cannot-get-it-to-work.36380/

    But the solution there does not work. I rebooted (soft and hard reboot) and even changed the firmware to various Toastman's versions countless times - it is always the same.
     
  2. eibgrad

    eibgrad Addicted to LI Member

    Any attempt to connect to the external public IP from inside the LAN is called NAT loopback. Not all routers support it, esp. w/ stock firmware. But most third party firmware does. I don't use Toastman, but I do use Shibby and dd-wrt, and it's usually configurable via the firewall UI. It may be disabled by default.

    P.S. Opening the WAN side of your router's GUI is not a good idea. You should use SSH (or VPN), preferrably w/ public/private keypairs.
     
  3. lockheed

    lockheed Reformed Router Member

    I've been using regular Tomato and Tomato RAF for years and it has never been a problem, or an option I needed to set up.

    Is that different in Toastman's?
     
  4. koitsu

    koitsu Network Guru Member

    How are you verifying Remote Access isn't working? Describe the exact test (and where you're doing it from).
     
  5. lockheed

    lockheed Reformed Router Member

    From my laptop connected to LAN of the router (NAT loopback).
    1. I go to the router's WAN IP:8080
    2. The browser says Connecting... Connecting... Connecting...
    3. After a minute it's still blank, Connecting...
    4. Page not found.
     
  6. koitsu

    koitsu Network Guru Member

    This is not a valid test; the packets are not coming across the WAN interface. You need someone else to test for you, or use one of the many port checkers available on the Internet (there are tons of sites that can do this for you).

    As implied by earlier posts, hitting your WAN IP from within the LAN makes use of NAT loopback, which you should try to avoid using under all circumstances (I have talked about this at length in older posts of mine, there are massive perform hits doing it; if you want me to look them up I can do so).

    TL;DR -- When on the LAN, connect to the router's LAN IP. When on the Internet, connect to the router's WAN IP. Always.
     
  7. lockheed

    lockheed Reformed Router Member

    I checked it with a web service http://www.yougetsignal.com/tools/open-ports/ and it says the port is closed.

    I run
    iptables -I INPUT -p tcp --dport 8080 -j ACCEPT
    inside tomato, but it is still closed.


    Sure, that would be an interesting read.

    Yes, but I am inside this LAN only once every year, and so before I leave, I need to make sure I can access the admin interface from the outside.
     
    Last edited: Mar 2, 2014
  8. koitsu

    koitsu Network Guru Member

    If the port is closed per online port checking tools, then you get to figure out why. :) Blindly adding INPUT chain firewall rules isn't the way to go about this, as the methodology for inbound connections to the router itself is different than what you'd think.

    It would help to see your existing firewall rules (output from iptables -L -n -v --line numbers and iptables -t nat -L -n -v --line-numbers and please do not change/modify any of the output), as well as output from netstat -anl.

    References for performance problems when using WAN IP within the LAN -- the key one is the first:

    http://www.linksysinfo.org/index.php?threads/file-transfers-slow-using-wan-ip.59161/
    http://www.linksysinfo.org/index.php?threads/port-forwarding-oddity-bug.68460/#post-226359
    http://www.linksysinfo.org/index.ph...th-tomato-shibby-1-28-v115.69316/#post-237683

    As I say in all my posts: just stop doing this. If you use a FQDN/hostname on your LAN when trying to access the WAN (e.g. from the LAN you access http://whatever.myisp.com/ where whatever.myisp.com resolves to your WAN IP), then there are workarounds for this where you can configure dnsmasq to return the LAN IP when whatever.myisp.com is resolved on your LAN (i.e. this ensures any DNS lookups done on your LAN for your WAN hostname get turned into a LAN IP). I discuss it in some of those threads.
     
    Last edited: Mar 2, 2014
  9. lockheed

    lockheed Reformed Router Member

    edited
     
    Last edited: Mar 2, 2014
  10. koitsu

    koitsu Network Guru Member

    99.99.999.999 isn't a valid IP address. Did you miss the part where I said "please do not change/modify any of the output"? I cannot trust this output when it's modified, I'm sorry to say.

    Also, since the forum messes up whitespace formatting (not your fault; it's been like this for ages), it would help if you could put this stuff up on a pastebin somewhere.
     
  11. lockheed

    lockheed Reformed Router Member

  12. lockheed

    lockheed Reformed Router Member

    By the way - I tried connecting from the outside of the LAN, and it still doesn't work.
     
  13. koitsu

    koitsu Network Guru Member

    The port check tools mentioned are sufficient test methodologies, no need to go to great extremes, they'll do the work for you.

    Give me time to check some settings and try to reproduce it, but I can see you do have some firewall rules in place that differ from my own (I use tomato-K26USB-1.28.0503.7MIPSR2Toastman-RT-N-Ext.trx). I'll poke about and see what the deal is.

    You don't have Enable DMZ enabled under Port Forwarding / DMZ, do you? If so undo that and try again.
     
  14. lockheed

    lockheed Reformed Router Member

    Why, yes I do. I always had and it always worked before switching from Tomato and Tomato RAF to Toastman's.
    I disabled it, but it's still the same.

    The website now reports the port 8080 as open, but I don't think it's related to DMZ because I reenabled it and it still says it's open.
     
  15. koitsu

    koitsu Network Guru Member

    Okay, took a look at this. All I changed in my settings was Administration / Admin Access / Remote Access HTTP (was previously Disabled), and compared the firewall rules before and after (for both filter and nat tables), ditto with netstat.

    The only relevant difference is in the INPUT chain (part of filter table). There were no changes to the nat table.

    Before (remote disabled):

    Code:
    Chain INPUT (policy DROP 2568 packets, 175K bytes)
    num  pkts bytes target  prot opt in  out  source  destination
    1  215 17361 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state INVALID
    2  3658  522K ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
    3  22  2230 ACCEPT  all  --  lo  *  0.0.0.0/0  0.0.0.0/0
    4  11355 1505K ACCEPT  all  --  br0  *  0.0.0.0/0  0.0.0.0/0
    5  61305 3906K ACCEPT  icmp --  *  *  0.0.0.0/0  0.0.0.0/0
    6  13  884 ACCEPT  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp dpts:33434:33534
    7  9143 3136K ACCEPT  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp spt:67 dpt:68
    8  5  300 ACCEPT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:113 flags:0x17/0x02
    
    After (remote enabled):

    Code:
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    num  pkts bytes target  prot opt in  out  source  destination
    1  0  0 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state INVALID
    2  99  6026 ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
    3  0  0 ACCEPT  all  --  lo  *  0.0.0.0/0  0.0.0.0/0
    4  4  252 ACCEPT  all  --  br0  *  0.0.0.0/0  0.0.0.0/0
    5  20  1280 ACCEPT  icmp --  *  *  0.0.0.0/0  0.0.0.0/0
    6  0  0 ACCEPT  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp dpts:33434:33534
    7  1  381 ACCEPT  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp spt:67 dpt:68
    8  0  0 ACCEPT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080
    9  0  0 ACCEPT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:113 flags:0x17/0x02
    
    Note the addition of what's at rule number 8. That line equates to this (and is visible in /etc/iptables too):

    iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

    And I can indeed verify it works just fine. Testing from my FreeBSD VPS on the Internet:

    Code:
    $ telnet koitsu.strangled.net 8080
    Trying 76.102.14.35...
    Connected to koitsu.strangled.net.
    Escape character is '^]'.
    ^]
    telnet> close
    Connection closed.
    
    Then checked packet counters:

    Code:
    Chain INPUT (policy DROP 1 packets, 40 bytes)
    num  pkts bytes target  prot opt in  out  source  destination
    ...
    8  1  60 ACCEPT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080
    ...
    
    So the issue may be related to any kind of customised rules or firmware features you're using, or your ISP may be filtering traffic before it even reaches you.

    Your router is too small / doesn't have Entware to be able to fit something like tcpdump on there (well, if I could find a static binary of it, you could drop it into /tmp and run it from there -- the normal place I used to get such binaries was shut down) to see if your ISP is filtering traffic or not.
     
  16. koitsu

    koitsu Network Guru Member

    Changing the DMZ setting would cause some firewall rules to get entirely reloaded from scratch, so anything you had in there beforehand would be lost, i.e. something that was previously causing a problem is now gone. My guess is that that's probably the case.

    Rule ordering vs. when DMZ is enabled may have been a problem in the past, I don't know if it was fixed or what. Here's a thread circa 2012 talking about it w/ shibby firmware:

    http://www.linksysinfo.org/index.php?threads/remote-access-on-shibby.50001/

    I would suggest fully rebooting your router with the settings now in place and see if the problem happens again. If so, then there may be a rule ordering problem that gets fixed after toggling DMZ but is done wrong on reboot. If it doesn't recur, then there was something wonky in your rulesets directing traffic to an IP on your LAN or somewhere else (hence packets to 8080 were going to that machine and not your router).

    If it's reproducible and you want to track this down, you'll need to spend the time looking, i.e. adjusting settings, saving output from iptables -L -n -v and iptables -t nat -L -n -v into a file on the router (somewhere in /tmp would be good), adjusting settings, saving output, rinse lather repeat until you can find what rules are getting messed with and in what order. There's no way in hell I'm going to enable DMZ to test this (security implications are too high), so it'll be up to you if you wanna pursue it.
     
  17. lockheed

    lockheed Reformed Router Member

    You mean something like that? :)
    http://multics.minidns.net/tomato/PRECOMPILED-static/


    Anyway, I figured it was easier to wipe the router clean and reconfigure it manually. So I did, and now remote access admin works fine.

    But I have another problem, which may or may not be related, but seems similar to me.
    I am trying to run a small SOCKS proxy on that server (for external use for friends from China, so they can acces Facebook, youtube and so on).
    So I do it like so in the Tools/Run window:
    Code:
    wget -O /tmp/srelay http://multics.minidns.net/tomato/PRECOMPILED-static/srelay
    chown root:root /tmp/srelay
    chmod 755 /tmp/srelay
    /tmp/srelay -i :21 -a n -t -J vlan1
    iptables -I INPUT -i vlan1 -p tcp --dport 21 -j ACCEPT
    However, after setting that external IP: port as proxy in a browser in one of the computer inside the LAN, it does not load any pages. You certainly know your way around network issues, so I though I'd ask if you can spot the cause of the problem.
     
  18. koitsu

    koitsu Network Guru Member

    Yes, that's the site, but all I could find were links going to the old site name.

    I'd need a man page for that srelay binary, as I need to know what all the flags are and how they function, and I'd need to figure out if srelay was truly listening in INADDR_ANY or not.

    I also assume vlan1 is your WAN interface?
     
  19. lockheed

    lockheed Reformed Router Member

    Glad to be of help.

    I doubt a manpage exists, but here's the next best thing:
    Code:
    /tmp/srelay -help
    srelay 0.4.8b4 2010/11/05 (Tomo.M)
    usage: srelay [options]
    options:
    -c file config file
    -i i/f listen interface IP[:pORT]
    -J i/f outbound interface name
    -m num max child/thread
    -o min idle timeout minutes
    -p file pid file
    -a np auth methods n: no, p:pass
    -u file srelay password file
    -f run into foreground
    -r resolve client name in log
    -s force logging to syslog
    -t disable threading
    -b avoid BIND port restriction
    -g use the same interface for outbound as inbound
    -v show version and exit
    -h show this help and exit
    
    Yes, vlan1 is WAN interface. And here's the netstat -anl:

    http://pastebin.com/HteFEtgN
     
  20. koitsu

    koitsu Network Guru Member

    My guess is that from the LAN you're able to contact TCP port 21 (since the daemon binds to INADDR_ANY), but that the -J flag causes the response packets to go out vlan1, which is your WAN interface. There's a lot of things wrong with what this could cause/induce, but the one that worries me the most is this:

    The destination IP in the response packet, going out the WAN interface, may be for a reserved IANA address (ex. 192.168.1.0/24) because the source IP of what was talking to it was within that range. Some ISPs implement BCP 38 (a very very good/wise thing to do), which would ideally block this packet before it made it out onto the Internet, but some may not. Furthermore, some ISPs may actually shut off your account if they see your router/devices trying to send packets out with destination addresses in reserved ranges (or also source IPs in that range for that matter).

    You're probably going to have to do packet captures on two interfaces at the same time -- both vlan1 and br0 -- to see what comes across the LAN (from the client) and what may be going out the WAN (from srelay). I'm sorry but I'm not going to give a tcpdump tutorial here -- doing this properly and understanding the actual packets and correlation of things would take me hours to explain.

    But in general this is just another example of where you can't test this kind of thing from your LAN because the nature of the multi-interface aspect home routers. This is one reason why I tend to recommend people not try to turn their routers into "Linux servers" and instead just get a low-cost VPS (like $20/month from Linode, but some others go as low as $5/month) and do whatever they want from there. There's too many "gotchas" about the nature of what consumer routers do, the NAT layer, and how the switches work (br0 vs. ethX vs. vlanX). Multi-interface environments always make stuff like this complex.

    You might try replacing -J vlan1 with just -g, but it all depends on what the actual srelay code does. Meaning I can't guarantee that will work/do the right thing (in fact I'd bet it won't, come to think of it).

    Also just a comment in passing: such a relay service may be in violation of your ISP's ToS, in addition to the fact that you'll be held responsible for whatever your friends in China are actually doing via said SOCKS proxy (your network = your responsibility = you may be held responsible legally). This sort of thing already came to light with Tor, where in Germany someone intentionally running a Tor exit node claimed innocence to whatever going over their network and the court ruled that argument was utter nonsense (same would be the case in the US, we just haven't had the court case for it yet). If this is really something you want to allow, lock it down with firewall rules only allowing certain source IPs to connect to TCP port 21 on your WAN interface. (You should also be using the --syn flag on your iptables rule for that, BTW)
     
  21. lockheed

    lockheed Reformed Router Member

    You were right, it does work when connected from the outside. Excellent. Thanks a lot!
     
  22. jbarbieri

    jbarbieri Network Newbie Member

    The iptables scripts are incorrect. Need to add another line per rule if DMZ / remote access is turned on.

    in firewall.c in the source code:

    where
    Code:
    ipt_write("-A INPUT -p tcp %s --dport %s -j %s\n", s, nvram_safe_get("http_wanport"), chain_in_accept);
    is, need to add
    Code:
    ipt_write("-A %s -p tcp --dport %s -j ACCEPT\n", chain_wan_prerouting, nvram_safe_get("http_wanport"));


    where
    Code:
    ipt_write("-A INPUT -p tcp %s --dport %s -j %s\n", s, nvram_safe_get("sshd_rport"), chain_in_accept);
    is, need to add
    Code:
    ipt_write("-A %s -p tcp --dport %s -j ACCEPT\n", chain_wan_prerouting, nvram_safe_get("sshd_rport"));

    Once that is done, then remote access will work with DMZ on.



    Easiest way now is to go under admin>scripts>firewall and add:

    iptables -I WANPREROUTING -t nat -p tcp --dport (whatever you set the outside webport to be) -j ACCEPT
    iptables -I WANPREROUTING -t nat -p tcp --dport (whatever you set the outside sshport to be) -j ACCEPT
     

Share This Page