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

Port Forwarding question : Asus RT-N16 Shibby Tomato

Discussion in 'Tomato Firmware' started by duprade, Feb 4, 2013.

  1. duprade

    duprade Serious Server Member

    Hello All!
    I'm new to custom firmware, and today I jumped in and installed the following firmware on my RT-N16
tomato-K26USB-1.28.RT-MIPSR2-105.1-AIO

    I have a domain .. under which I've created subdomains … pointing to my RT-N16 via no-ip.org… all the subdomains are pointing correctly to the router.

    Is there anyway to Forward subdomains to specific devices within my network with a specific port?
    For example:

    This is along the lines of what I'd like to accomplish…

    ftp.mydomain.com - to forward to my network storage drive 192.168.1.100 using port 21. (192.168.1.100.21)
    storage.mydomain.com - to access to the network storage driver's web interface using port 80 (192.168.1.100:80)

    router.mydomain.com - to access the tomatos web interface via port 8080

    print.mydomain.com - to forward to my network printer on port 9100 (192.168.1.50:9100)
    and so on …

    When I've attempted to configure these items on the port forwarding page … it seems I have to use the port in order to reach those devices in the address… as I'm not sure if I'm able to configure the router to actually route those connections to the correct devices.

    Using the SRC Address didn't help … but if I left SRC address blank, I was able to connect to the FTP on my NAS for example … This is where my confusion lies. Any ideas? I feel I'm quite capable when it comes to this type of stuff, but I seem lost.
     
  2. koitsu

    koitsu Network Guru Member

    Let's step through each part:

    You've updated DNS records to reflect the following things (either via A record updates or CNAMEs (shame on you if you use CNAMEs -- there are many caveats which I'm not going to get into here)):

    ftp.mydomain.com IN A public.internet.ip.
    storage.mydomain.com IN A public.internet.ip.
    router.mydomain.com IN A public.internet.ip.
    print.mydomain.com IN A public.internet.ip.

    Right? So all these "subdomains" point to the same IP address.

    Any time a packet is sent to {anyoftheabove}.mydomain.com it's going to have a destination address of public.internet.ip. This is at the IP level (layer 3).

    Each service (FTP vs. your NAS web interface vs. router web interface vs. printer interface) can run on its own port number, i.e. public.internet.ip:{portnumber}. This is at the TCP level (layer 4).

    See the disconnect? You either have to segregate these types of services at layer 3 (IP) or layer 4 (TCP). It's your call.

    I would say for the 2nd and 3rd, you can do this because they're HTTP. You can run what's called a "reverse proxy server" (reverse proxy web server) on your router, which would transparently "translate" I/O for things with an HTTP Host: header to some custom IP or port of your choosing. For example:

    public.internet.ip TCP port 80 with HTTP Host header storage.mydomain.com <--> 192.168.1.100 TCP port 80
    public.internet.ip TCP port 80 with HTTP Host router.mydomain.com <--> 192.168.1.1 TCP port 8080

    Meaning, http://storage.mydomain.com/ (i.e. TCP port 80) would go to 192.168.1.100 TCP port 80 (transparently) and http://router.mydomain.com/ (i.e. TCP port 80) would go to 192.168.1.1 TCP port 8080 (transparently), even though storage.mydomain.com and router.mydomain.com both resolve to the same IP address.

    I strongly doubt your printer (what listens on TCP port 9100) is HTTP, and even if so, there's zero guarantee printer drivers include Host: headers in their requests.

    If these protocols are not HTTP (for example, your printer probably isn't), then you must specify the port number yourself, and that port number must be unique (i.e. print.mydomain.com TCP port 12345 would go to 192.168.1.50 TCP port 9100, etc.). You could not have print.mydomain.com on TCP port 80 in the case no Host: header is sent by the client, because the reverse proxy wouldn't know where to send the request. HTTP just happens to provide an extra way to provide "multiple domains on a single IP" -- non-HTTP protocols don't.

    In this situation, the only other alternative is for you to have multiple/separate public Internet IP addresses and then NAT packets to certain IPs, redirecting the I/O to some IPs on your LAN on a different port number. Linux can do this, sure, but most ISPs won't give you more than one IP address (especially if via DHCP).

    Finally, for FTP, there is no solution to this. You need a fully dedicated IP address for FTP to work. I have explained in detail on this forum in the past how the FTP protocol works -- specifically how passive and active modes work and what they require from a firewall. For FTP to work, you really need a dedicated IP address. Most people think "it's just ports 20 and 21" (and often think the port 20 stuff is for incoming traffic as well) -- they are wrong on multiple levels. Most people who run FTP servers, I've found, do not understand how the FTP protocol (passive and active modes) actually works.
     
  3. duprade

    duprade Serious Server Member

    Thank you for your explanation Koitsu.
    I've actually found a workaround using Web redirects through the DNS for most of what I was trying to do. I'm still experimenting with a couple of other things, but your explanation was extremely helpful. I apologize for not replying sooner, as I had my family in law in town and didn't have time to play around. I'm still rather new at this so I'm learning by trial and error.:)
     

Share This Page