Domain name recognition question

Talk about Documentation
1

Hi how's it going, sorry if this is another one of those super simple questions but I'm still new to networking with the OpenWRT system and was overwhelmed by the amount of features and documentation. Anyways ill try to make this question is intuitive as possible.

Ok, so I have a domain name I purchased called my coolnet.com and have configured with a static ip pointing to my router at home. The domain name allows me to enter any sub name i want at it will still always goto the router. So like stuff.coolnet.com or i can enter anything.coolnet.com etc.... Regardless if i only enter coolnet.com or files.coolnet.com it goes to my router. Anyways how do I configure OpenDWR so it will rout the different sub domain names to different ip's and ports on the router? Or is this even possible? Anyways thanks

files.coolnet.com goto 192.168.4:2000
stuff.coolnet.com goto 192.168.10:485
nas.coolnet.com goto 192.168.52:80
etc...

I know how to configure the port forwarding but want to make it so the different names are recognized and then can forward them from there?

2

Please post output of

ubus call system board

from your OpenWRT device.

3

Domain names are resolved to IP addresses, there is no way to use port numbers here. And (on a public DNS) they can only resolve to a public IP address.

So, all those names must point to the public IP address of your router (if you were planning to use this only internally, you didn't need a fixed IP address or a real domain name).

Now, you can use a reverse HTTP(S) proxy on your router (for example NGINX) to forward the requests to different internal machines (with different port numbers), depending on the name used by the client. But this will work only for HTTP(S).

4

So your saying that no matter what there's only one IP those names goto. I understand that but there's no way for the router to know which one was being requested and then re rout them kind of like how DNS does? So what do i need to do to get that to work?

5

depends on the protocol, it can be done it's it's HTTP, where you create a rule on a web server, to forward based on the FQDN you're requesting.

another option is to map those *.coolnet.com FQDNs to BS IPs in the DNS, then use firewall rules to forward the traffic to the IP:port they're really supposed to go to.

unless the client knows 192.168.4 is supposed to use port 2000, and you don't have to write it out, then you're only mapping a FQDN to an IP.

1 Like
6

Since you have port 80 shown, is it safe to assume that the client will be HTTP-based, ie. a browser or similar?

In that case use a HTTP reverse proxy to fan-out the HTTP requests.

The simplest one I can think of is Varnish. An example config file /etc/varnish/default.vcl (pulled from the internet and adjusted a bit):

vcl 4.1;

backend files {
    .host = "files.OpenWrt.lan";
    .port = "2000";
}

backend stuff {
    .host = "stuff.OpenWrt.lan";
    .port = "485";
}

backend nas {
    .host = "nas.OpenWrt.lan";
    .port = "80";
}

sub vcl_recv {
    if (req.host ~ "^stuff\.coolnet\.com\.?$") {
        set req.backend_hint = stuff;
    }
    elseif (req.host ~ "^nas\.coolnet\.com\.?$") {
        set req.backend_hint = nas;
    }
    else {
        set req.backend_hint = files;
    }

    if (req.method == "GET" || req.method == "HEAD") {
        return (pass);
    }
}

You can see the backend TCP port in the configuration above.
The backend IP will be in your DNS configuration in LUCI. For example, add
/nas.OpenWrt.lan/192.168.0.52/ to dnsmasq config.

Not sure if that particular reverse proxy is available as a package in OpenWRT, if not then look for stuff like nginx, squid, apache. Somewhat bigger software but does the same job.

1 Like
7

Addendum:

If you want to secure your password to the NAS from being viewed by your ISP, you may want HTTPS too?

The "s" in HTTPS means it runs over SSL/TLS, so one needs some software to fan-out based on the TLS SNI header instead of the HTTP host header. Same concept, the headers simply contain whatever hostname that the client used to do a DNS lookup before it contacted your IP.

In that case you need something called a TLS/SSL reverse proxy. There's a couple different ones too, I can think of pound, ssltunnel and haproxy. If built with SSL support, probably nginx can too.

SSL reverse proxies can accept HTTPS and fan-out to HTTPS servers, but usually one would have the SSL keys lying around on the reverse proxy anyway, so in most cases it's easier to also use the SSL reverse proxy to terminate SSL entirely and then fan-out plain HTTP to the servers.

Here's a configuration example /etc/haproxy/haproxy.cfg:

frontend tls_terminate
   bind *:443 ssl strict-sni crt /etc/nas.coolnet.com.pem /etc/stuff.coolnet.com.pem /etc/files.coolnet.com.pem

   use_backend nas if { ssl_fc_sni -i nas.coolnet.com }
   use_backend stuff if { ssl_fc_sni -i stuff.coolnet.com }
   default_backend files

backend nas
   server s1 192.168.0.52:80

backend stuff
   server s2 192.168.0.10:485

backend files
   server s3 192.168.0.4:2000

To use SSL, one also needs SSL certificates and keys.

Either create your own and install the certificates on all your client devices, or use some piece of software to pull down officially recognized SSL certificates that will work anywhere. I think the default many people use is called certbot.

You can tunnel anything, so this works for stuff other than HTTPS too. If you come across a protocol that ends with an "s", odds are that it is SSL-tunneled.

Technical detail: The "strict-"sni" option above means that the client has to present a SNI servername header, or it will be shown the door. But essentially all modern software that supports SSL does this.

EDIT: I can think of one exception, a piece of software called postfix. For some reason, that project refused to add SNI header support when all the other modern email transport software and all major email providers did. For this particular edge case, or if you come across other archaic software that doesn't support modern TLS, it's possible to omit "strict-sni" and instead configure a so-called "default certificate".

1 Like
8

don't need any certs for SNI though ?
I use that to reroute traffic via my US based sniproxy to bypass geo blocking.

sslh should be able to do it in openwrt.

9

Okay, yes, technically true!

Clever :slight_smile:
(you should share the config!)

Aah, excellent. If that's an available package, maybe I should have whipped up a configuration for sslh instead of haproxy and varnish, hmm.

Also makes sense on smaller routers to do SSL termination somewhere further back I guess.

10

Sure, but I'm not using sslh, but sniproxy, it's a diff piece of sw.
Not sure it's developed any more, also unavailable in Openwrt.

Could try to recreate the same functionality using sslh, shouldn't be too hard.

11

Cool, I did some research on SNI and it looks like what im trying to do. Is there a plugin or software package that's easily configurable that can be Installed on the OpenWRT router? I'm trying to host a bunch of stuff on all different ports from this IP address and just want different names rout to them

12

reread my last and 2nd last post ?

13

Ok so in the 'DHCP & DNS - General' tab of OpenWRT I go down to where it says 'Resolve specified FQDNs to an IP.' I then enter:

files.coolnet.com/123.123.123.1
stuff.coolnet.com/123.123.123.2
nas.coolnet.com/123.123.123.3

Then then I go over to 'Firewall - Port Fowards' tab and I create port forwards for each of the BS IP's 123.123.123.1, 123.123.123.2, 123.123.123.3

I kinda understand it but I wish someone made a tutorial or video on this exact thing I'm trying to do. Im sure it would get allot of views and comments. I think I'm doing something wrong though because I cant Save/Apply the changes and it keeps giving me an error message 'Option "Domain" contains an invalid input value. Expecting: non-empty value' But there's no felid I can find anywhere that is for me to enter a domain. I wish I could afford some collage classes on this stuff and get a degree in Network administration IT

14

Notice that this is going to work only for the devices inside your network, right?

1 Like
15

make sure your LAN clients use your DNS for name resolution, that's usually not the case...

1 Like