Hi, I’m looking to send messages from some IoT sensors provisioned in The Things Network (community edition) into Azure IoT Central. Is there any way to find out what public IP addresses the sensors use to send messages? We are using a IP whitelist in IoT Central, so need to be able to whitelist the IPs to enable the connections.
We’ve tried whitelisting our The Things gateway IPs (can’t use FQDN), but the connections fail regardless. Worth mentioning that we can’t find the IPs on the Azure end because of log restrictions.
Will the public IP(s) the sensors use to send from The Things change or are they static for our instance?
Sensors do not have IP addresses, at least for their connection and message handling to the LNS so no IP address to white list! (See learn section to understand LoRaWAN). Also GW IP for backhaul connection irrelevant as it would be masked for your application by the LNS.
If you look at the basic diagram of a LoRaWAN infrastructure you learn sensors send data to gateways, gateways send data to the LoRaWAN Network Server (LNS) and that the LNS provides the data to the applications. So you are looking for the IP addresses used by The Things Community Stack, not the sensors.
I doubt that that information is static, however depending on which cluster you are using the DNS name is …cloud.thethings.network. Where you need to add the region (for instance eu1) on the dots.
Thank you for your responses, there are some good things to go on here.
We went back to our network settings in Azure and set it to the following (in screenshot) after running an nslookup on our LNS address-eu1.cloud.thethings.network.
Even though we whitelisted the IPs from the nslookup, we are still getting failed connections into Azure IoT Central from our devices in The Things Network. Any ideas as to why?
A few extra notes: we cannot use FQDNs in these Azure whitelisting screens unfortunately and the connections from the devices work fine when the Azure network whitelisting is set to accept connections from all networks.
The DNS name is pointing to the front of the LNS. It might well be that there are other components that users do not need to connect to and are not in the DNS pool but are used to push the information to Azure IoT central.
You’ve done a lookup for IPv4, which isn’t really a thing for big stuff these days if it can be helped.
Plus you’re assuming that the public facing IP addresses that we tell our gateways and web browser to connect to are the ones that also send out information which is pretty unlikely given the cluster, components for separation of concerns, queuing, database nodes etc etc.
Incoming web hooks from TTN this afternoon were all IPv6. If you write & host a web server script to receive uplinks - doesn’t have to do anything - and then look at the access logs, you may strike lucky that the web hook server is also the one that runs the outgoing Azure messaging.
You could also ask TTI nicely on Slack for the details. But they will be busy with conference prep so I’d capture the IP addresses manually as it shouldn’t be more than a few minutes to do.
We have managed to solve the issue by getting the initial part of the range from Microsoft support. They weren’t able to give us the whole address of the sending devices so we just whitelisted the last octet with a /24 notation. Thanks for all the help.
Moderation note for clarification otherwise Google indexing could mislead others.
Because as we detailed above, sending devices do not have an IP address - they are LoRaWAN radios without any form of Ethernet, WiFi or anything else that can transport IP packets.
