Is it possible to access an IoT device (which may be a HTTP REST Client or MQTT client) from remote web server over Internet and send text to that particular device (instead of broadcasting message over topic as in the case of MQTT) using the IP address of device? This article describe that IoT devices have IP address (private IPs assigned by router to IoT devices). In such case how the devices can be seen from a web server?

Note: 1-3 devices will be on a home network behind a router and consumers will not be technically capable of setting things like port forwarding up.

  • 1
    I suggest you purchase a simple device (like a webcam) and start doing some experiments. I think this is a most basic NAT question, but is is so vague that it is hard to be sure. Look at the NAT page on your router, you will see lan IP:Port mapped to wan IP:port. Jul 19, 2019 at 7:42
  • 1
    You need to constrain your question. What IoT device, what sort of network is it connected to? Also single point to point messaging is perfectly possible with MQTT (your security architecture in the last question depended on it.)
    – hardillb
    Jul 19, 2019 at 7:44
  • 1
    @hardillb devices like Arduino (with WiFi), Raspberry Pi and a Cloud server on internet.
    – tim3in
    Jul 19, 2019 at 8:21
  • 1
    "on the internet" doesn't help, still way too vague. e.g 1. On a home network behind a consumer grade modem/router 2. Connected to a corporate network that forces all traffic through a proxy. 3. Connected via LTE-M or nb-iot. 4. Do the devices connect to a VPN. All these things change the answer.
    – hardillb
    Jul 19, 2019 at 8:31
  • OK, next set questions, 1. how many of these IoT devices do you expect to be at each location? 2. Do you expect the consumer to be technically capable of setting things like port forwarding up (how to do this differs with every type of router/modem). (p.s. edit the question to add these all details)
    – hardillb
    Jul 19, 2019 at 8:50

3 Answers 3


So the short answer to your question is No, you can not make a HTTP request to the device you have described.

The reason is that in order to reach the device directly the client (Your central cloud app would be a HTTP client at this point) needs to know the following things:

  1. A publicly routed IP address for the device
  2. A fixed port for the device

In the case you have described you have neither. You don't have a publicly routable IP address because the device has private (RFC 1918) IP address that can not be routed to. If you set up port forwarding on the router for this device you could then use the external IP address of the router, but since most home broadband providers do not supply fixed IPv4 addresses this address will not be static, and is subject to change when ever the router restarts. You could have the devices report in every time they regain network access after a router reboot to let the central service know the IP address, but that means keeping a real time list of device locations.

You can't use normal port forwarding for 2 reasons:

  1. You state that you can not depend on your users being tech savy enough actually enable it
  2. How do you deal with multiple devices? You would need a separate port for each device and you need to let each device know what port they were bound to so when they report in to the central service they could include the port. But this means not only would the user have to set up the port forwarding, they would have to configure each device with port information.

There is a solution that allows the devices to set up their own port forwarding called UPnP (Universal Plug and Play) but this requires that the router supports this functionality and it is largely considered to be a security vulnerability and most people are recommended to disable it.

All of the above is why protocols like MQTT are the defacto standard for IoT devices. Because the device connects out to the MQTT broker and then keeps that connection open indefinitely it avoids all the problems I have outlined.

The outbound connection means that there is no need to keep a list of device connection details, no need to set up any port forwarding, no limit on the number of devices behind each NAT router, no need to worry if the public IP address of the router changes.

Each device subscribes to a topic specific to its self (e.g. based on the device serial number) and as such can receive messages directed specifically for that device, it can also subscribe to more general topics allowing for broadcast type messaging.

  • Would that be possible with ipv6 ? Jul 19, 2019 at 10:35
  • 2
    yes, it would be possible with IPv6. But ISPs still seem reluctant to actually deploy IPv6 for consumers and it's still not a good idea, running a HTTP server on your device opens you up to a whole range of possible security problems. Having a client that connects out is a LOT better idea
    – hardillb
    Jul 19, 2019 at 10:36

If your device runs a Linux distro (like a Raspberry Pi), you can set up a reverse SSH tunnel, so you can access your device even if it's behind a router.

The thing here is that your device has to start the connection, opening a tunnel to a server. Then you can connect to the device through the server. So you could send a message to the device (thorough MQTT or HTTP) indicating that it should open the reverse tunnel.

If you're using a microcontroller (Arduino, ESP8266, etc), you have to manually broadcast the messages you want, no other option.


I'm curious why you want to use HTTP instead of MQTT? One of the design goals of MQTT is bi-directional communication.

By using MQTT, you could have a unique topic per device, that only the device itself is authorized to subscribe to. Then the cloud service can publish a message to the device-specific topic to send a message to that device.

  • 1
    I hope @tim3in remembers why he was not wanting to use MQTT 2 years ago when he asked his question. May 10, 2021 at 19:07
  • @kalyanswaroop I was only trying to question his requirements in a polite manner. Other users will stumble upon this question even though it's old, and my suggestion wasn't mentioned by anyone else.
    – gregers
    Jun 9, 2021 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.