18

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:

enter image description here

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:

enter image description here

  • 6
    "Ethernet IP"? Isn't that just... a regular LAN-like network? – grawity Nov 13 '18 at 9:53
  • “Programming via Ethernet IP" — what exactly does that mean? It would help if you could specify what device and IDE you are talking about. I assume the IDE connects to the device on a given IP address and TCP port to receive commands? – slhck Nov 13 '18 at 9:53
  • @grawity yes it's a regular LAN.Like network & at slhck I'm use codesys IDE and a device with codesys Runtime on it ! – Engine Nov 13 '18 at 9:59
  • 3
    The obvious answer is IPv6, of course. – Michael Hampton Nov 13 '18 at 15:56
  • 1
    @grawity Ethernet/IP is an industrial automation protocol, not to be confused with IP over Ethernet :( – richardb Nov 16 '18 at 13:14
50

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.

  • 10
    It would also help to make a note, that if OP sets a portforwarding open to do this, everyone else in the whole world could potentially change the code. Unless there's some form of authentication too, sooner or later, portsniffers will find the port and a hacker will attempt to break in, that's a guarantee. – LPChip Nov 13 '18 at 10:08
  • @LPChip Indeed! I should've mentioned that, my bad. – rahuldottech Nov 13 '18 at 10:11
  • Nice addition. :) I would give you a +1 for it, but I already gave it earler, because even without the warning, it was already a good answer. :) – LPChip Nov 13 '18 at 11:04
  • 2
    @FreeMan later as in, it can take days before a bot crawler comes along, depending on what port you use, but sooner in the sense that, if you are unlucky, it can happen in a matter of minutes. – LPChip Nov 13 '18 at 13:35
  • 1
    @IsmaelMiguel Of course, you should do all the obvious basic security stuff. I just have no way of knowing what they are in this specific case. – rahuldottech Nov 13 '18 at 14:50
10

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.

  • 5
    Buying 3rd-party services is not the only answer. You can get the same effect with SSH or RDP. – jpaugh Nov 14 '18 at 3:21
  • 4
    The two and only correct answers are VPN or SSH tunnels...Some VPN protocols aren't very good either at preventing MITM... – trognanders Nov 14 '18 at 7:46
  • 5
    SSH is way cheaper, more convenient, and easier to set up and probably the better option in this scenario – rahuldottech Nov 14 '18 at 12:30
  • @jpaugh: VPN does not involve any 3rd party services. While I'll readily agree that SSH can be made to work, it is nowhere near the same as VPN when it comes to ease of setup, no-extra-installs-no-hoops universal availability, and last but not least, seamless usability. Now, about RDP... you are of course joking, right? Not only is it the pristine implementation the probably most exploited software in the world (or at least in the top-5), but also the protocol itself is inherently insecure, using broken (workable, not theoretical) ciphers, and a TLS version which was superseded a decade ago. – Damon Nov 14 '18 at 13:25
  • 4
    -1 simply for "one and only" in the title, SSH with port forwarding is also completely valid and probably safer since you don't necessarily have to give remote access to your entire network, just one port of one device, and most likely it's easy to configure and you aren't relying on a router's random software implementation of a rarely used feature. – Bill K Nov 14 '18 at 20:45
2

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.

1

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.

  • You can... Just run an SSH server on Windows, you don't need Linux here. – rahuldottech Nov 14 '18 at 12:32
  • "Then when programming on your remote machine with an IDE, you will connect to localhost instead of the LAN IP." This bit doesn't make sense to me, elaborate? – rahuldottech Nov 14 '18 at 12:33
  • @rahuldottech SSH port forwarding works at the tcp level. On the server the sshd opens connections to the resource on the local lan and forwards the contents of that socket over SSH. On the remote machine the ssh client listens on a localhost port. When you connect to localhost on that port it is the SSH client, and it just hooks the tcp connections together. Kinda weird but really versatile since there is no ip routing! – trognanders Nov 14 '18 at 23:46
-1

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.

  • 4
    Using onion services will only make this way more complicated with no added benefits. Tor can be useful. Won't be in this case. – rahuldottech Nov 14 '18 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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