I have an embedded device that I can program via Ethernet IP when it's connected on the same router with the PC as follows:

Is it possible to send the whole traffic through the Internet and still be able to program it? To make it a little bit more clear, something like:

The simple (and unsafe) method

What you're looking for is called port forwarding ^[1][2].

For example, let us assume the following:

• Your programmable device works on port 22 and has the IP 192.168.1.5




• Your public IP is 122.176.11.55

Then you can go into your router's setting and forward a WAN port (for eg, 8022) to 192.168.1.5:22.

Now, you can remotely access the device from anywhere through the internet by accessing 122.176.11.55:8022 instead of 192.168.1.5:22 in your IDE.

Keep in mind that unless you have a static IP, your public IP can change at any time, in which case you should check out dynamic DNS services.

NOTE: unless your device has some method of authentication, someone with malicious intent will almost certainly find access to it on the open web. See below for safe alternative.

The safe (and honestly not much more complicated) method

Leave a PC (or raspberry pi, or similar) connected to your network, and access that remotely instead through something safe like SSH, and then program your device through it over LAN.

This also has the added advantage of working even if your device doesn't use TCP or UDP :)

A bit tedious, yes. But safe.

The one and only correct answer can be "VPN".

Simply using IPv6 would "work" (assuming the router isn't configured to firewall off the device, and all of ISP, device, and laptop support IPv6), but it is a terrible idea for the same reason port forwarding is.

Other than promoted by the well-known IPv6 propaganda, you actually do not ever want any of the devices on your LAN being uniquely identifiable or even accessible from the internet. No, that is not a good thing.

Port forwarding would "work" with good old IPv4, but it makes the device accessible not only to you but to everybody. Nobody knows, so that's no problem, right?

Well, there's an army of automated port scanners running 24/7 and scanning random addresses/ports in the hope anything, anywhere might possibly answer, so generally having any device that will answer to an external request online isn't optimal. If a device will happily have itself programmed according to what comes in via the network, that's a recipe for desaster.

The above is in principle true for VPN as well, but it's pretty much as good as you can get, if you want access. The only truly safe thing is no internet connection at all, which is not a practical option for obvious reasons. The next safest thing to "no internet" is VPN. Exactly one port on exactly one device (well, it depends, up to three ports), exposing VPN and nothing else, port-forwarded to the internet.

VPN lets you -- but nobody else -- access a device on your LAN via the internet as if you were on the same LAN (although a bit slower). It prevents unauthorized access, it provides confidentiality, and data integrity.

Virtually every no-shit router supports at least one flavor of VPN out of the box. Unluckily, depending on what router model you have, it may be a poor flavor of VPN or it may be poorly documented how to configure the remote computer. Still, despite the possible hassle of figuring out how to configure it -- if you have nothing better, that's by far the best option!

Most common NAS boxes support two or three no-suck methods of VPN, and every $20 credit-card sized 3 Watt computer can run a VPN server, no problem. Even many modern mobile phones support VPN without having to install extra software, so you can even access your home network when you're using your phone's mobile internet (via private hotspot, even).

For example, L2TP/IPSec may not be the most awesome choice, but it's 99% good and takes one minute to set up on my Disk Station and on my Samsung phone. Another minute if my Windows laptop is to use it as well (independently of the phone). No extra software needed.

OpenVPN takes like 3-5 minutes of setup because you'll have to download install the client software on the laptop. But in the greater picture, a 5 min setup counts as "zero", compared to being completely unsafe.

Host a VPN, either in a router/security gateway appliance, or another box with port forwarding to that box. Whenever you want to work remotely, connect to the VPN, and you will see the embedded device as if it were on a local network. It would probably be a good idea to place the embedded device in an isolated subnet, to help prevent attacks on your main network if the VPN or the embedded device is compromised.

Make Windows PC without IDE into a Linux PC in a reasonably secure configuration with sshd running. Port forward from your router to the SSH port on the Linux machine. Use SSH tunnels to connect to the embedded device IP. Then when programming on your remote machine with an IDE, you will connect to localhost instead of the LAN IP.

Listening on the internet with a hardened service like SSH is reasonably safe. Listening directly on the internet with development anything is a fabulously bad idea. SSH is a gatekeeper. If you make sure to verify the host key, it protects against MITM absolutely. It uses good cryptography. The tunneling setup does not involve routing or bridging but instead looks as if you are connecting directly from the SSHD machine. This is vastly simpler to setup correctly.

I have recently come across a better solution for personal only remote access. First let's discuss the scope of the problem. There are three issues that come into play: the nat, the ip address, and the security. For example in the common cases where you wish to run a ssh or web server on a home network the traditional approach is port forwarding and dynamic dns and industry standard best practices for security. This has disadvantages for your case as your device does not have standard security. This can be mitigated by using ssh port forwarding as opposed to opening your device to the internet, but you still have to deal with nat traversal since your device (and the ssh server on your raspberry pi you are about to set up) does not have a publicly reachable IP address and the IP address of your router is subject to change (assuming there is only one nat between you and the internet) you still would need to setup port forwarding (or in the case of multiple routers, multiple port forwarding) and dynamic dns so you can still reach your ssh server.

There is however a simpler solution, and believe it or not that is tor hidden services. tor hidden services basically act as a port forward, but automatically handles nat traversal, and does not have a changing address so dynamic dns is not needed. There are of course issues of the onion address being hard to remember, but If you are the only user, you can write it down in one of your project files. I would recommend still paring this with a ssh server to provide authentication, but you may decide that the long onion address is enough. Also tor hidden services provide encryption of the entire link except for the last hop so the only way to get better is end to end encryption, but that would depend on the device you are programing.