1. Home
  2. Embedded Programming
  3. Plug&Play solution to reach an embedded HTTP server under a router
  4. Page 2

Plug&Play solution to reach an embedded HTTP server under a router

I know, but I would need a public server, a man-in-the-middle, a cloud server that I have to mantain, manage, support... this isn't free and is over my knowledge.

MQTT is a popular choice for IoT and it can run over TLS. As before, I would need a MQTT broker or a HTTP(S) server in the public Internet.

Let me explain my idea. I have a HTTP server that runs behind a NAT. The user can connect to it after forwarding the port to the internal private IP address of the device and setting a DDNS account. Those two steps are too complex for "standard user".

I know *the solution* is to have only *outgoing* connections and this means a public server. What I want to achieve is to have the simplest server I can. I don't need to save persistent data of remote device or other data from the users. I want to only allow the user connect to his remote device behind his router when he wants. Nothing more.

My idea is to create a TCP tunnel between the devices (clients) and a public server. Over this "transparent" TCP tunnel I could transfer any data, such as HTTP requests/response.

The end user will connect to a public "non standard" HTTP server. Every request from the browser will be forward to the correct tunnel (of course, I need a mechanism to link the user to the right tunnel).

The device-side of the tunnel will forward any data to local(host) HTTP server in both directions.

There are many solutions available and I think a similar solution already exists, for the public server and the tunnel protocol.

Reply to
pozz
Loading thread data ...

It sounds like what you actually need is something like STUN, which helps establish a peer-to-peer connection between two applications (potentially) both being behind NAT gateways. If I remember correctly, STUN is intended for UDP traffic, so that means that you're going to need a custom client for communicating with the devices.

Another option is to use UDP (which automatically punches a nice hole for incoming traffic through a NAT gateway, if sent from from the inside) between the devices and your cloud server. If the devices regularly send your cloud server a keep-alive telegram, your cloud server can forward data requests to the devices over UDP. - But this isn't much of an improvement over having the device keeping a connection based on some other protocol open to your cloud server.

I'm not fully versed in STUN, but you might be able to buy access to a STUN server run by somebody else, so you don't have to worry about server operations.

As some of my work involves writing server frameworks, and operating servers, I consider a cloud server the easy solution. Using STUN, and routing the actual data directly from the device to the client is the proper, privacy-friendly solution.

Greetings,

Jacob

--
"Look!  Ugly one-horned mule."
Reply to
Jacob Sparre Andersen

I can't wait for the reaction from IT staff at fabs using our products ;-)

Reply to
Dave Nadler

Here's an excellent overview of the how-to-escape-NAT problem:

formatting link
Shows pros/cons of several approaches discussed in this thread.

Reply to
Dave Nadler

Il 06/04/2018 17:51, pozz ha scritto:

What about reverse SSH tunnel? I think it is what I need. A public "relay" server runs a "standard" ssh server, so it will be very simple to delivery.

On my device should be running a ssh client that creates, with an outgoing connection, a permanent SSH tunnel with the "relay" server.

Now the end user can connect to the device by using the public "relay" server.

I think it should work, even if I didn't test this configuration. However the only problem is to implement a simple SSH client on lwip device... I think it will be a very complex task. Anyway I don't need encryption provided by SSH... maybe a simple telnet tunnel should be sufficient. Is it possible?

Reply to
pozz

My ISP was flaky/down for a bit ... catching up.

:

You want/need a public server, but (per above) you don't have the skills or funds to maintain one. Hmmm. I saw your other message re: public relay servers. Relay servers are a forward proxy: they take an incoming call, make an outgoing call and patch the two together.

What you seem to want is more kin to a load balancer: but one that allows the "targets" (your devices) to call in rather than it calling out to them.

I'm not aware of any OSS software that does that. I think you are going to have to do some work on the server side. There certainly are OSS proxy and load balancer programs that you could modify to do what you want.

George

Reply to
George Neuner

Pozz, what did you end up doing to solve your "hidden behind NAT" problem?

Reply to
Dave Nadler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.