We can easily do that re-mapping in our AWS load balancer, however I can’t figure out if there is a way to get TTS to provide this different domain back to the gateway via CUPS.
Has anyone done something like this before? Either with different domains or with a different technique?
You can also choose to proxy /update-info, /router-info and /traffic/* on your stack.example.com, then you don’t even need to use those additional subdomains. We do the same in the proxies of The Things Stack Community Edition and The Things Stack Cloud.
On those deployments we still tell gateways to connect to the dedicated ports, but if you want to send gateways to port 80/443 you can set the gcs.basic-station.default.lns-uri configuration option, or if it’s just for specific gateways, set the gateway server address in the Console to wss://stack.example.com.
Interesting, I hadn’t considered just routing the paths for those services. I’ll try this out soon.
Do you know if it’s possible to run them on different domains though?
I was thinking it would be good to separate the full stack from the gateway-specific paths (CUPS/LNS), because then I can just restrict access to the full stack for our own internal use, and only open up the gateway-specific paths for public access. So something like:
stack.example.com - full stack, internal use only, default Let’s Encrypt certificate
gw.example.com - reverse proxy, CUPS/LNS only, different certificate (e.g. from AWS ACM)
One of the other reasons I want to have the gateways connect to a different domain is so that we can use an AWS-generated certificate. Our gateways seem to be having issues connecting when we use the default Let’s Encrypt certificate generated by TTS, but they work fine when using an Amazon-generated certificate.
It’s probably possible to split your deployment over different domains, but that’s not officially documented/supported by The Things Stack. So if you do this and it doesn’t work, or if it breaks in a future version of The Things Stack, you’re on your own.
If these gateways don’t work with widely trusted and widely used certificates, I would think twice about using these gateways for anything serious. Of course, if you manage your own CA, it will probably work until that expires, but with publicly trusted certificates from AWS it’s possible that they will at some point (for example) start preferring their ECDSA root over their RSA root, which may suddenly result in the same issues.
Maybe I need to revisit the issues I was having with Let’s Encrypt on these gateways. Perhaps you can provide some advice on how I can investigate further?
I’m using a Dragino LPS8 that has been modified quite a bit, but we’re using their default Basics Station code. I was able to get it to connect to au1.cloud.thethings.network just fine, which seems to use Let’s Encrypt, but when I tried to connect it to my own instance which also uses LE it didn’t seem to work and would return an unhelpful error from Mbed TLS (I don’t have the exact error code with me but can get it next week).
Do you have any suggestions on how I might be able to figure out what was breaking and what was different between these two instances?
Whilst talking of LetsEncrypt & certificates guess worth flagging this issue & pending revocation (starts tomorrow)… claimed only affects <1%, but Sod’s law says some will be in the TTN community!
I’ve finally had a chance to try this out. I’ve temporarily decided to abandon hosting it on different domains (as TTS doesn’t officially support this), but I still want to have LNS running on port 443.
For my initial testing, I am just using Community Edition instead of my own instance.
I can successfully get my gateway to connect to Community Edition when I just use default settings (e.g. LNS on port 8887).
When I try to use 443 for LNS, my gateway isn’t able to connect. As suggested, I have manually set the Gateway Server address to wss://au1.cloud.thethings.network:443, and this is the error I get from Basics Station on my gateway:
2022-01-31 02:32:42.509 [TCE:INFO] Connecting to INFOS: wss://au1.cloud.thethings.network:443
2022-01-31 02:32:42.767 [AIO:ERRO] [3] WS upgrade failed with HTTP status code: 403
2022-01-31 02:32:42.767 [AIO:DEBU] [3] WS connection shutdown...
Seeing the 403 error, I thought maybe it was incorrect API keys, however I checked these and they are correct. I was able to get the gateway to work successfully when I set the Gateway Server address to wss://au1.cloud.thethings.network:8887
Any idea what is happening here? Is this proxy perhaps not set up for LNS-on-443 on the community edition?
That’s correct. The preferred way to connect is with the dedicated port numbers, so we only documented those. There may be some additional customization needed to make everything work on port 443, maybe @KrishnaIyerEaswaran2 knows more about that.
For anyone else trying to do this in the future, I have received some clarification from The Things Industries support - apparently LNS on port 443 isn’t supported on The Things Stack Cloud - only on self-hosted.
I have been able to successfully run LNS on a port other than 8887 or 443, however there is a bug when trying to run it on port 443. I’ve created an issue on GitHub with a potential fix here: https://github.com/TheThingsNetwork/lorawan-stack/issues/5197