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

access forwarded ports from inside LAN??

Discussion in 'Tomato Firmware' started by tkittich, Jan 16, 2013.

  1. tkittich

    tkittich Serious Server Member

    Hi,

    I have multiple DVR's that should be available both from LAN and WAN via http://dyndns.org:8000, http://dyndns.org:8001, http://dyndns.org:8002, etc. But it seems tomato only forwards ports for incoming connections from the WAN side. How do I access the forwarded ports from inside LAN as well?

    The following command seems to work:
    Code:
    /usr/sbin/iptables -t nat -I PREROUTING 1 -j WANPREROUTING
    But I am not sure if it's the correct way to do it or not.
     
  2. koitsu

    koitsu Network Guru Member

    Do not do that. The way to access the forwarded ports from within the LAN is to access the LAN IPs on the ports you've configured. For example, if TCP port 8000 is forwarded to 192.168.1.40 TCP port 12345, then from the LAN connect to 192.168.1.40 port 12345.

    Please do not try to connect to the WAN IP from within the LAN. Yes it will work due to loopback masquerading, but it's a very bad habit to get into and has major performance implications (I've been trying to dig up the post showing this fact -- a user reports the router's CPU shoots up to something like 70% -- but I can't find it in the search results. Making me quite irritated).

    If you need a way to test, on the WAN side, that forwarded connections are working, use available Internet resources:

    http://www.t1shopper.com/tools/port-scan/
    http://www.yougetsignal.com/tools/open-ports/
    http://www.canyouseeme.org/
     
  3. tkittich

    tkittich Serious Server Member

    Thanks a lot for your insight. Having to use different IP's and ports from WAN and LAN can be very confusing for users. And my little Asus RT-N12 C1 router seems to handle the load ok with no problems. If there's no better way to use the same hostname : port from WAN and LAN, I think I'll have to use the above code.
     
  4. sarelc

    sarelc Addicted to LI Member

    A more user-friendly solution might be to just create two different bookmarks - DVR (@home) and DVR (away).
     
  5. tkittich

    tkittich Serious Server Member

    Sadly, the above code doesn't work with QOS enabled. Would it be possible to setup some kind of redirect inside LAN so that the same hostname : port would also work from LAN and WAN??
     
  6. koitsu

    koitsu Network Guru Member

    You should be aware what your iptables rule is actually doing and the risks associated with it. Specifically, packets received across the WAN interface with a spoofed source address of your LAN IP range (i.e. 192.168.1.0/24) can/will make it to machines on your LAN. Naturally response packets won't make it back to the attacker, but they'd be able to bypass the necessary security rule. Example:

    Code:
    root@gw:/tmp/home/root# iptables -t nat -L PREROUTING -n -v --line-numbers
    Chain PREROUTING (policy ACCEPT 2890 packets, 207K bytes)
    num  pkts bytes target    prot opt in    out    source              destination
    1        0    0 DROP      all  --  vlan2  *      0.0.0.0/0            192.168.1.0/24
    2    8915  577K WANPREROUTING  all  --  *      *      0.0.0.0/0            67.180.84.87
    3      649 51978 upnp      all  --  *      *      0.0.0.0/0            67.180.84.87
    
    Thus consider using 2 for your insert line number, not 1. But I still think that rule you've inserted is very dangerous given the lack of source or destination address provided.

    What is the value Advanced -> Firewall -> NAT -> Nat Loopback ? If set to All and NAT Target is set to MASQUERADE then you shouldn't need the rule at all. Proof using my own network, where I have TCP port 6502 forwarded on the WAN to a local LAN machine:

    Code:
    $ telnet koitsu.strangled.net 6502
    Trying 67.180.84.87...
    Connected to koitsu.strangled.net.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
    ^]
    telnet> close
    Connection closed.
     
    $ ping 192.168.1.1
    PING 192.168.1.1 (192.168.1.1): 56 data bytes
    64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.416 ms
    64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.314 ms
    ^C
    --- 192.168.1.1 ping statistics ---
    2 packets transmitted, 2 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.314/0.365/0.416/0.051 ms
    
    Overall I must insist that you do as I recommended though -- I really couldn't care less if "it's a problem for users" to delineate between a WAN and LAN segment. Part of being a network administrator is teaching/educating users of your network to do what's proper. Teaching someone "for machines on the LAN you need to use an address of 192.168.1.something, but if you're trying to connect to our stuff across the Internet, you need to use the WAN IP" is not that hard.

    P.S. -- I found the post mentioning high CPU load when using loopback masquerading; just because you have some other router model doesn't mean squat: http://www.linksysinfo.org/index.php?threads/file-transfers-slow-using-wan-ip.59161/
     
  7. tkittich

    tkittich Serious Server Member

    Currently I have Nat loopback: All and NAT target: SNAT. Somehow, the DROP on this router is on line #2.
    Code:
    root@qos:/tmp/home/root# iptables -nvL -t nat --line-numbers
    Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    num  pkts bytes target    prot opt in    out    source              destination
    1        0    0 WANPREROUTING  all  --  *      *      0.0.0.0/0            192.168.111.101
    2        0    0 DROP      all  --  vlan1  *      0.0.0.0/0            10.10.10.0/24
     
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    num  pkts bytes target    prot opt in    out    source              destination
    1        0    0 SNAT      all  --  *      vlan1  0.0.0.0/0            0.0.0.0/0          to:192.168.111.101
    2        0    0 SNAT      all  --  *      br0    10.10.10.0/24        10.10.10.0/24      to:10.10.10.1
    
    Also, I have tried changing NAT target: SNAT to MASQUERADE. That didn't allow forwarded ports to be accessed from LAN.
     
  8. koitsu

    koitsu Network Guru Member

    Thanks for following up -- looks like I'm wrong. I guess -I chain 1 actually behaves more like "insert after line 1" not "insert at line 1 + shift other rules down". And -A (which I assume would be like "insert after line X") doesn't have support for line numbers, so yeah.

    Your iptables stuff contains significantly different topologies and configurations than mine (for example use of two private networks, 192.168.111.0/24 (presumably) and 10.10.10.0/24); I use stock defaults with no other adjustments to the network topology or details (e.g. no VPN, no vlans aside from the stock vlan2, a single network, etc.). So I imagine there is some complexity in your network topology going on which is causing some of this. I can assure you that the NAT loopback and NAT target stuff does work (proof is above, obviously). If you figure it out, let us know!
     
  9. Bird333

    Bird333 Network Guru Member

    Line numbers should put rules at that spot.
    If you have rules listed after that one it could be placed ahead of that one.
     
  10. PBandJ

    PBandJ Networkin' Nut Member

    Not sure if this can work, I'm far from being comfortable with iptables, so proceed with caution:

    Let's, for the sake of argument, say you had just one single DVR. You could use dnsmasq's --address to solve this, right? By resolving to the local address of that single DVR.
    So what about the general case with multiple DVRs? Use the same trick to resolve to the internal IP address of the router, than use DNAT rules to redirect to the DVRs:
    Code:
    iptables -t nat -A PREROUTING -i br0 -d <router-internal-ip> --dport 8000 -j DNAT --to-destination <ip-of-DVR1>:<port>
    iptables -t nat -A PREROUTING -i br0 -d <router-internal-ip> --dport 8001 -j DNAT --to-destination <ip-of-DVR2>:<port>
     
  11. Bird333

    Bird333 Network Guru Member

    That rule makes logical sense, but I can't remember if packets in the same subnet actual pass through the prerouting rules. Wouldn't hurt to try.
     

Share This Page