One of the challenges with installing LoRaWAN gateways on corporate or even private networks is having to deal with port forwarding and potentially dynamic dns issues. For example, I am part of the Boston IoT group and I am in the process of prototyping a mLinux multitech Ethernet gateway at the company I work for. The first step is to get IT involved in order to put the gateway on a secure part of the network with ports 1700 forwarded. The multitech I have is Ethernet only and is likely to be the lowest cost solution for a free and open network.
While this is doable in my case it is a quite a hurdle in general. It makes it more difficult to find willing participants to install gateways when IT has to get involved.
Googling around I discovered that Websockets might be an attractive alternative if done over port 80 or 443 as these ports are typically open in most networks. There are even examples of Websockets to UDP bridges: https://gist.github.com/marmorkuchen-net/48544bd61183da666e6d
If the Croft server supported Websockets as an alternative to UDP and if the gateway packet forwarder was forked to add Websockets as an alternative transport this might provide us with a way to make installation behind firewalls less difficult.
I think you raise a very important issue! I have only just started reading up on TTN so my knowledge is very limited at this point, but given what I’ve read, I think it’s critical that gateways are plug-and-play in order to facilitate quick and widespread deployment, especially since crowdsourcing is a key pillar of the effort. Any friction in deploying the gateway may be a showstopper, both in commercial/enterprise environments, but also in residential use.
I think depending on port forwarding or dynamic DNS is going to be difficult due to political or technical reasons, but also due to lack of expertise of home users. Furthermore, more configuration may mean more points of failure and may result in a less reliable network.
I think it’s a fair assumption that the gateway is allowed to connect outbound to either ports 80 or 443 over HTTP or HTTPS, respectively. This is also a common approach used by VPNs behind firewalls or proxies.
Furthermore, I can see some corporate IT departments being wary of letting some unproven box onto their local network (e.g. packet sniffing, interference, rogue access point, etc), but perhaps they could place it in a DMZ or VLAN for the time being and run a packet sniffer on it to see that there’s nothing to worry about. Or just hook it up to a 4G modem and be completely decoupled – in Norway a 10 GB subscription is about $30 per month which shouldn’t be too hard to expense. Anyway, it might be good to have a solid story here so the IT departments feel at ease.
Yes, I agree that a (secure) WebSocket-based alternative would be great to deal with hostile environments. Perhaps one could default to UDP and fall back to WSS/WS if UDP is unavailable. The gateway would have to negotiate this with its routers.
I’m a little iffy on whether the routers persist packets (or are they messages at that point?) or if they immediately relay them to the handlers. I think store-and-forward would be safest in the event of a network failure or handlers being unavailable, but the persistence could also be done at the gateway level, I believe. Then the routers would basically be directory services, but if the gateways were to talk directly to the handlers that might be a potential bottleneck. If the gateway is to be able to use WSS/WS then there needs to be a corresponding end-point for it to send to. It would be nice if a router would support both UDP and WSS/WS for free out of the box. I believe routers are core components so developers won’t typically be creating those, only handlers and servers, right? And if the messages are generic then accepting two (or more) protocols simultaneously should be quite feasible.
Hi Kaare - great to get your thoughts on this. I am sure we are not the only ones with this opinion. I think your point about plug-and-play is spot on for the crowdsourcing audience The Things Network is targeting. Hopefully some of the technical leads on the Things Network team will pick up on this and consider ways to make the gateways easier to deploy behind a firewall on an Ethernet network.
Do you really need any port forwarding if you want to setup just a gateway? The only incoming connection is via radio (the LoRa part itself), the rest is outgoing, the packet forwarder in the gateway connects to the croft instance configured.
It is not the same if you want to setup the entire backend infrastructure (i.e. croft & jolie) but those are not required if just want to plug a gateway to thethingsnetwork.org system, which would be the default for the Kickstarter gateways.
And if you want to hook up any other service to the infrastructure you will be able to do it, already now is possible (since today!) to subscribe to an MQTT topic and build on top of that without having to host the backend in your network.
You make a good point. Port forwarding is probably not needed but opening port 1700 is. This requires IT involvement on a typical company network. I was not aware that MQTT had been rolled out - but now I see the post - thanks. MQTT needs port 1883 opened so that raises the same issue.
Bottom line is that unless the gateway packet forwarder looks like a typical http browser on port 80 or 443, chances are it is not going to work and IT will need to get involved. This is a big hurdle for easy deployment.
MQTT is implemented on the backend (jolie), so again, you don’t need any special handling unless you want to run the full backend on premises, which is not really the idea for most users.
About opening port 1700, perhaps in a very restrictive corporate network, like a bank, you could have problems but in that case you’re anyway very unlikely to be allowed to install a device in the network. Most sane company networks will not block this, and certainly no residential network blocks this because the connection is outgoing, not incoming.
Although slightly different we are trying to reconfigure a Kerlink Gateway so that it will listen to SSH on a port rather than 22. This is because the modem supplied by the ISP doesn’t allow port forwarding for SSH commands. This isn’t unique in the UK at least. The reason is that we will probably need to reconfigure them remotely at some point.
Well from experience in the Netherlands i can tell most (large) corporate networks do block most outgoing connections. Often only outgoing HTTP / HTTPS is allowed (mostly via some proxy construct). But then again you are right that in these cases you are probably not allowed to install a non-standard device in the network (but often nobody notices as long as you use port 433 and preferably HTTPS ;-)).
But I guess these companies are not the typical use cases TTN is about: they are used to paying big money to Telco’s for services with SLA’s.
Hi Batilan - my experience echos yours. The use case for a crowd sourced TTN network is the employee with a window office and an Ethernet jack wanting to install his or her TTN gateway. Particularly in an urban area it would be an easy way to spread TTN. The logistics of installing on roof tops or getting IT involved to open ports will limit deployment I think. Cellular rather than Ethernet is always an option but that is not free.
Corporate IT policies usually do not allow employees to hook any equipment they fancy into the corporate network. So the IT department should be involved anyway.
Indeed - I used to be CIO of a public company so I can confirm that is typically company policy. That being said it is a big hurdle to get IT involved. It is IT’s job to mitigate risk so the chances of getting permission to have an Open Source LoRaWAN gateway installed is low. In a past life my company sold Ethernet connected IoT devices that used port 80 and that looked like a browser. They are deployed on many company networks because it is simply a matter of plugging them in and having them work. Not advocating breaking of company policy but simply saying that ease of installation that does not involve messing with opening ports is much more compatible with a crowd sourced implementation.
@robbo
Ease of installation i certainly something to aim for.
If the gateway will be able to use port 80 and/or 443 with a proxy it will need authentication capabilities Probably NTLM authentication should be included. And I would recommend a large warning note to check company policy on unauthorized devices to prevent accidents.
I appreciate this is an old topic but particularly relevant to me just now and hope one of you guys could guide us with dealing with our IT department. I work for the Scottish Environment Protection Agency, I have a bunch of Lorrier LoRaWAN gateways as well as 1 LoRaNK8 gateway here and we have big plans to trial various sensor tech for flooding, pollution, meteorological applications.
I have asked our IT dept to add the LoRaNK8 gateway to our enterprise network to allow trials to begin. They have all the details for the gateway but already IT have gone mysteriously ‘radio silent’ on me and I just know they are breaking out into a cold sweat. At some point in the very near future they will call us in for a chat to discuss things and I’m wondering if anyone would be helpful and kind enough to give us some specific points of defence to calm the IT dept nerves.
Also on a wider note is anyone aware of any IoT network specialists we could call on for consultancy? Can TTN tech specialists be consulted out does anyone know ?
I’m a IT specialist working in the IT department of a museum in the Netherlands and have multiple (Link Labs and Multitech) gateways in our network. I might be able to help you.
As mentioned in this topic there is only outbound traffic to the Internet, so the firewall should allow outgoing UDP traffic on port 1700 or with the new packet forwarder TCP port 1883. To further reduce possible security risks this firewall rule should have the gateway IP addresses defined as source addresses. This way no other devices on the network can use the open ports. Besides the firewall it is obviously important to properly secure access (SSH, telnet, etc.) to the gateways. In the end adding a LoRaWAN gateway in a IT network is almost the same (in terms of security) as adding a new laptop or PC to the network. But the thing that IT dept are most afraid of/dislike is that they have to support the new devices. They don’t want you calling them every time something goes wrong So if you can tackle the support issue I don’t see a reason why they won’t add the gateway’s to the IT network.
Many thanks for your advice and help on this. Really helpful and you are spot on with the support issue. So far still no response from my IT dept !! The are definitely burying their heads in the sand with this.
I will feedback once they begin engaging properly.
Jonathan
Adding an update to an older but still interesting topic.
I’ve been considering similar problems adding similar network services from inside my personal firewalled LAN. My current strategy is to get a fixed IP address with a virtual linux server in the cloud and then attach it to my personal LAN behind my ISP’s firewalled router and with either port forwarding or a VPN connection, probably VPN. That gets a lot of the functionality and exposure outside of the firewall where it should bother IT less.
There are issues with dynamic IPs but there are tools avaiable to help cope. It is easier with the external public facing box handling public connections. Keeping a single point to point connection up (external server tunneled into the firewalled gateway) is simpler and done right should be invisible to both the LAN and the WAN. There is no time delayed DNS caching issue. The public sees only the fixed IP outside box. A dropped link can be addressed immediately if the link is is maintained from the end inside the firewall.
Part of it is to build a local firewall around the gateway to protect other LAN resources. I assume you don’t need any services from IT except an internet path from the gateway out. I.e. you don’t need access to other inside computers. LoRa devices => gateway => external (outside the firewall) publicly accessable server.
I’m experimenting with providing a secure MQTT broker that my devices can access from anywhere. A mongodb server will be next. LoRa will be third on my plate.
Additional note: There is a tool called autossh which can be used to keep multiple ssh links up. I assume it is not the only one. It should survive dynamic IP changes since it is behind the changing IP. It just reconnects to the fixed outside IP.
One last note. I’m using the cheapest ($5 per month) virtual linux box from Linode. I don’t have a lot of traffic so that should suffice and it is scalable. I can upgrade to any bandwidth I need and am willing to pay for. They just move my virtual machine to faster hardware without changing the IP address.
So if you can tackle the support issue I don’t see a reason why they won’t add the gateway’s to the IT network.