Secure Remote Access to Devices on Overlapping Subnets

This application is a continuation of U.S. patent application Ser. No. 17/687,838, filed on Mar. 7, 2022, which claims priority to U.S. Prov. Appl. Ser. No. 63/237,309, filed on Aug. 26, 2021, both entitled SECURE REMOTE ACCESS TO DEVICES ON OVERLAPPING SUBNETS, by Michael Freed, et al., the contents of which are incorporated herein by reference.

The present disclosure relates generally to computer networks, and, more particularly, to secure remote access to devices on overlapping subnets.

The Internet of Things, or “IoT” for short, represents an evolution of computer networks that seeks to connect many everyday objects to the Internet. Notably, there has been a recent proliferation of ‘smart’ devices that are Internet-capable such as thermostats, lighting, televisions, cameras, and the like. In many implementations, these devices may also communicate with one another. For example, an IoT motion sensor may communicate with one or more smart lightbulbs, to actuate the lighting in a room when a person enters the room. Vehicles are another class of ‘things’ that are being connected via the IoT for purposes of sharing sensor data, implementing self-driving capabilities, monitoring, and the like.

Today, it is a common practice in many industrial environments to use a ‘cookie-cutter’ approach to deploying IoT devices, including the reuse of Internet Protocol (IP) addresses and subnets. Indeed, it is very common in factories for different cells, zones, bays, etc. having the same types of devices to have overlapping subnets, which greatly simplifies the deployment of those devices. However, overlapping subnets also present various challenges with respect to accessing a particular device, remotely.

According to one or more embodiments of the disclosure, a remote access manager receives an access request from a client to remotely access a device on a local network. The remote access manager generates a universally unique identifier for the access request. The remote access manager sends a response to the client having a one-time use domain name system name that is based on the universally unique identifier. The remote access manager communicates with a web proxy to authorize the client to remotely access the device.

A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations, or other devices, such as sensors, etc. Many types of networks are available, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), synchronous digital hierarchy (SDH) links, or Powerline Communications (PLC), and others. Other types of networks, such as field area networks (FANs), neighborhood area networks (NANs), personal area networks (PANs), etc. may also make up the components of any given computer network.

In various embodiments, computer networks may include an Internet of Things network. Loosely, the term “Internet of Things” or “IoT” (or “Internet of Everything” or “IoE”) refers to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. In particular, the IoT involves the ability to connect more than just computers and communications devices, but rather the ability to connect “objects” in general, such as lights, appliances, vehicles, heating, ventilating, and air-conditioning (HVAC), windows and window shades and blinds, doors, locks, etc. The “Internet of Things” thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., via IP), which may be the public Internet or a private network.

Often, IoT networks operate within a shared-media mesh networks, such as wireless or PLC networks, etc., and are often on what is referred to as Low-Power and Lossy Networks (LLNs), which are a class of network in which both the routers and their interconnect are constrained. That is, LLN devices/routers typically operate with constraints, e.g., processing power, memory, and/or energy (battery), and their interconnects are characterized by, illustratively, high loss rates, low data rates, and/or instability. IoT networks are comprised of anything from a few dozen to thousands or even millions of devices, and support point-to-point traffic (between devices inside the network), point-to-multipoint traffic (from a central control point such as a root node to a subset of devices inside the network), and multipoint-to-point traffic (from devices inside the network towards a central control point).

Edge computing, also sometimes referred to as “fog” computing, is a distributed approach of cloud implementation that acts as an intermediate layer from local networks (e.g., IoT networks) to the cloud (e.g., centralized and/or shared resources, as will be understood by those skilled in the art). That is, generally, edge computing entails using devices at the network edge to provide application services, including computation, networking, and storage, to the local nodes in the network, in contrast to cloud-based approaches that rely on remote data centers/cloud environments for the services. To this end, an edge node is a functional node that is deployed close to IoT endpoints to provide computing, storage, and networking resources and services. Multiple edge nodes organized or configured together form an edge compute system, to implement a particular solution. Edge nodes and edge systems can have the same or complementary capabilities, in various implementations. That is, each individual edge node does not have to implement the entire spectrum of capabilities. Instead, the edge capabilities may be distributed across multiple edge nodes and systems, which may collaborate to help each other to provide the desired services. In other words, an edge system can include any number of virtualized services and/or data stores that are spread across the distributed edge nodes. This may include a master-slave configuration, publish-subscribe configuration, or peer-to-peer configuration.

Low power and Lossy Networks (LLNs), e.g., certain sensor networks, may be used in a myriad of applications such as for “Smart Grid” and “Smart Cities.” A number of challenges in LLNs have been presented, such as:

In other words, LLNs are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints, e.g., processing power, memory, and/or energy (battery), and their interconnects are characterized by, illustratively, high loss rates, low data rates, and/or instability. LLNs are comprised of anything from a few dozen and up to thousands or even millions of LLN routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint-to-point traffic (from devices inside the LLN towards a central control point).

An example implementation of LLNs is an “Internet of Things” network. Loosely, the term “Internet of Things” or “IoT” may be used by those in the art to refer to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. In particular, the next frontier in the evolution of the Internet is the ability to connect more than just computers and communications devices, but rather the ability to connect “objects” in general, such as lights, appliances, vehicles, HVAC (heating, ventilating, and air-conditioning), windows and window shades and blinds, doors, locks, etc. The “Internet of Things” thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., IP), which may be the Public Internet or a private network. Such devices have been used in the industry for decades, usually in the form of non-IP or proprietary protocols that are connected to IP networks by way of protocol translation gateways. With the emergence of a myriad of applications, such as the smart grid advanced metering infrastructure (AMI), smart cities, and building and industrial automation, and cars (e.g., that can interconnect millions of objects for sensing things like power quality, tire pressure, and temperature and that can actuate engines and lights), it has been of the utmost importance to extend the IP protocol suite for these networks.

is a schematic block diagram of an example simplified computer networkillustratively comprising nodes/devices at various levels of the network, interconnected by various methods of communication. For instance, the links may be wired links or shared media (e.g., wireless links, PLC links, etc.) where certain nodes, such as, e.g., routers, sensors, computers, etc., may be in communication with other devices, e.g., based on connectivity, distance, signal strength, current operational status, location, etc.

Specifically, as shown in the example IoT network, three illustrative layers are shown, namely cloud layer, edge layer, and IoT device layer. Illustratively, the cloud layermay comprise general connectivity via the Internet, and may contain one or more datacenterswith one or more centralized serversor other devices, as will be appreciated by those skilled in the art. Within the edge layer, various edge devicesmay perform various data processing functions locally, as opposed to datacenter/cloud-based servers or on the endpoint IoT nodesthemselves of IoT device layer. For example, edge devicesmay include edge routers and/or other networking devices that provide connectivity between cloud layerand IoT device layer. Data packets (e.g., traffic and/or messages sent between the devices/nodes) may be exchanged among the nodes/devices of the computer networkusing predefined network communication protocols such as certain known wired protocols, wireless protocols, PLC protocols, or other shared-media protocols where appropriate. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

Those skilled in the art will understand that any number of nodes, devices, links, etc. may be used in the computer network, and that the view shown herein is for simplicity. Also, those skilled in the art will further understand that while the network is shown in a certain orientation, the networkis merely an example illustration that is not meant to limit the disclosure.

Data packets (e.g., traffic and/or messages) may be exchanged among the nodes/devices of the computer networkusing predefined network communication protocols such as certain known wired protocols, wireless protocols (e.g., IEEE Std. 802.15.4, Wi-Fi, Bluetooth®, DECT-Ultra Low Energy, LoRa, etc.), PLC protocols, or other shared-media protocols where appropriate. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

is a schematic block diagram of an example node/device(e.g., an apparatus) that may be used with one or more embodiments described herein, e.g., as any of the nodes or devices shown inabove or described in further detail below. The devicemay comprise one or more network interfaces(e.g., wired, wireless, PLC, etc.), at least one processor, and a memoryinterconnected by a system bus, as well as a power supply(e.g., battery, plug-in, etc.).

Network interface(s)include the mechanical, electrical, and signaling circuitry for communicating data over links coupled to the network. The network interfacesmay be configured to transmit and/or receive data using a variety of different communication protocols, such as TCP/IP, UDP, etc. Note that the devicemay have multiple different types of network connections, e.g., wireless and wired/physical connections, and that the view herein is merely for illustration. Also, while the network interfaceis shown separately from power supply, for PLC the network interfacemay communicate through the power supply, or may be an integral component of the power supply. In some specific configurations the PLC signal may be coupled to the power line feeding into the power supply.

The memorycomprises a plurality of storage locations that are addressable by the processorand the network interfacesfor storing software programs and data structures associated with the embodiments described herein. The processormay comprise hardware elements or hardware logic adapted to execute the software programs and manipulate the data structures. An operating system, portions of which are typically resident in memoryand executed by the processor, functionally organizes the device by, among other things, invoking operations in support of software processes and/or services executing on the device. These software processes/services may comprise an illustrative remote access process, as described herein.

It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. Also, while the description illustrates various processes, it is expressly contemplated that various processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes.

As noted above, many industrial IoT (IIoT) networks are now deployed using a ‘cookie-cutter’ approach whereby discrete manufacturing or other control segments are deployed using duplicate IP addresses. In other words, the network may comprise a plurality of units, such as cells, zones, bays, etc., with addresses being repeated across units. As a result, different devices may belong to overlapping subnets. In addition, these devices may be located behind one or more firewalls and/or network address translation (NAT) devices.

The above presents certain challenges to a remote access (RA) user that wishes to remotely access a web application server hosted by one of the endpoint IIOT devices at a particular location. For instance, assume that a particular robot has a web application server that allows a technician to review diagnostic data for that robot, make configuration changes, initiate software updates, and/or perform other maintenance functions. Typically, these web servers communicate using the Hypertext Transfer Protocol (HTTP) or, more likely, HTTP Secure (HTTPS). Because the target device is on an overlapping subnet, though, the client of the RA user and the target device cannot communicate, directly. This is often due to the fact that the target device is behind a NAT, firewall, etc. and does not have a public IP address.

Two potential approaches to remote access of devices on overlapping subnets rely on either:

1. Tunneling (e.g., using IPsec)

While both solutions can potentially address the issue, both require significant configuration to work. More specifically, the downsides to employing tunneling using IPSec for remote access are as follows:

Additionally, if IPSec technology was deployed on the gateways of the remote site, in order to connect the gateway to the remote access service, then the gateway would no longer have access to the private network of the remote network.

Alternatively, a web application proxy could be used to facilitate remote access over HTTP(S) to a web server hosted by a remote device. However, standard web application proxies also do not allow for multiple devices that have different IP addresses, but are otherwise identical, to be distinguished.

For instance, consider the case of two robots having original URLs for login as follows:

For remote access, a web application proxy would attempt to distinguish these devices by using device IDs in the URL path for each device login page, creating a mapping such that https://mycompany: 443/url/dev001/login maps to https://192.168.10.10:80/robot/login for robot 1 and https://mycompany: 443/url/dev002/login maps to https://192.168.10.20:80/robot/login for robot 2.

Now, the login page HTML might return an href to an absolute path such as the following:

This code would cause both URLs to become https://mycompany:443/static/basic_document.html, losing the device ID and creating an invalid URL.

However, since it is likely that the RA user is connecting to third party IoT web servers, it cannot be assumed that they will only use relative paths, which has been observed via real-word testing. In addition, including absolute paths would require modification to the server code, which may not be feasible. Another possibility would be to include the device ID in a header to help distinguish between the different devices. This would, though, still require modification to the server code of the target device for which remote access is desired.

The techniques introduced herein allow for the secure remote access to devices on overlapping subnets. In some aspects, the techniques herein support remote access to web application servers on such devices, without requiring the accessing client to install specialized software and/or reconfiguration. In further aspects, the techniques herein also support fine-grained, role-based access control to the devices.

Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with remote access process, which may include computer executable instructions executed by the processor(or independent processor of interfaces) to perform functions relating to the techniques described herein.

Specifically, in various embodiments, a remote access manager receives an access request from a client to remotely access a device on a local network. The remote access manager generates a universally unique identifier for the access request. The remote access manager sends a response to the client having a one-time use domain name system name that is based on the universally unique identifier. The remote access manager communicates with a web proxy to authorize the client to remotely access the device.

Operationally,illustrates an example 300 of remote access to a device using a remote access manager, according to various embodiments. As shown, assume that there are various endpoint IIOT devicesthat are on a local network of a particular location, such as a factory, warehouse, or the like. In addition, assume that any or all of deviceseach execute their own web application servers, allowing a technician to perform various functions such as reviewing diagnostic information, making configuration changes, and the like.

Typically, IIOT devices are often deployed in a way such that they are assigned IP addresses that overlap across different subnets. For instance, devices-may be on a first subnet and devices-may be on a second subnet, allowing both sets of devices to use overlapping IP addresses (e.g., 192.168.10.2 and 192.168.10.3). As noted, this presents challenges to remotely accessing their application web servers. Indeed, devicesmay be behind different networking devices such as gateways, firewalls, such as firewalls-, NATs, such as NAT, etc.

More specifically, as shown, devices-are behind gateway, which utilizes a cellular connection with a cell towerand is behind NAT. Devices-are behind gateway, which is connected to an enterprise networkand behind a firewall. Likewise, deviceis behind gateway. Gatewayand deviceare both behind gateway, which is also connected to enterprise networkand behind firewall.

Remotely accessing the application web server of a particular deviceis quite challenging under normal circumstances. For instance, say the RA user of client devicewishes to access the web server of device. To enable such a connection, a tunnel could be established. However, doing so would also require an agent to be installed to both client deviceas well as device. In addition, IPSec suffers from various pitfalls such as the potential for it being blocked by a firewall, an inability to perform fine grained access control, and the like. Alternatively, a traditional web proxy could be used to enable the remote access connection between client deviceand device. Here, though, this is also not a tenable solution as deviceshares the same local IP address as that of device, meaning that a traditional web proxy would not be able to distinguish between the two and support remote access to both deviceand device

According to various embodiments, the techniques herein propose the use of a remote access managerthat brokers and configures a remote connection between the remote client deviceand deviceon the local network of the location. In general, remote access managermay take the form of one or more specifically configured devices (e.g., one or more devicesexecuting illustrative remote access process) that provide a remote access service to client devices, such as client device.

During use, an administrator operating a devicemay interact with remote access managerto configure access policies for devices. Such policies may be device-specific, user-specific, location-specific, or the like. For instance, one policy may allow the RA user of client deviceaccess to only device, while blocking their access to any of the other devices, such as based on their user identifier.

In various embodiments, remote access managermay enable a remote access connection by assigning a one-time use/random Doman Name System (DNS) name for an individual device to be accessed, remotely. To do so, it may randomly generate a one-time use device ID for each connection to a remote device, which can then be included in the DNS name. This hides the internal network structure for security purposes.

As would be appreciated, a wildcard DNS record is a record in a DNS zone that matches requests for non-existent domain names. A wildcard DNS record uses ‘*’ as the leftmost label (part) of a domain name, e.g. *.example.com. The wildcard DNS record allows any random connection ID to be a prefix of the DNS name, but still map back to the same service, thus making our solution scalable for thousands of devices.

illustrates an example workflowfor providing remote access to a device, according to various embodiments. Continuing the example of, assume that the RA user of client deviceoperates their web browserto log into the remote access service of remote access managerand authenticating themselves to it, via exchange. For instance, the RA user may provide a username/user identifier, password, multifactor authentication information, or the like, to prove their identity to remote access manager.

Once authenticated and logged into the service of remote access manager, the RA user may then send a requestto remote access managerto access a specific devicethat is located in a local network behind a gateway. For example, the service of remote access managermay provide a listing to web browserof the devices to which the RA user is authorized to access. In turn, the RA user may operate their web browserto select a particular devicethat they wish to access.

According to various embodiments, at stepshown and in response to request, the service of remote access managermay generate a random universally unique identifier (UUID) for the devicefor which remote access was requested, such as a UUID of “123.” As would be appreciated, this UUID is for exemplary purposes only and a UUID having a greater number of characters and/or types of characters (e.g., lower case letters, uppercase letters, numbers, and/or symbols) will help to further ensure the security of the system. In further embodiments, the remote access manager may use that UUID as part of a one-time DNS name for the device (e.g., “123.remoteaccess.mycompany”) and return that DNS name to the client device of the RA user via response.

In some embodiments, a wildcard DNS entry may be registered with a DNS system, such that the one-time DNS name returned to web browserwill resolve to an address of a simple web proxy, which may be provided either directly by remote access manageror another device in communication therewith. For instance, a DNS wildcard entry “*.remoteaccess.mycompany” may be registered to resolve to the IP address of web proxyassociated with the domain “remoteaccess.mycompany.”

In turn, web browsermay send a requestto a Uniform Resource Locator (URL) comprising the one-time DNS name returned to it by remote access manager. For instance, the URL may take the form of “https://123.remoteaccess.mycompany/robot/login.” Such a URL resolves to the address of web proxy, meaning that requestwill be sent to web proxy.

After receiving request, web proxymay extract the UUID from the URL to which requestwas sent. Then, web proxymay send an authorization requestto the service of remote access manager, to authorize the remote access to the deviceassociated with the UUID.

In various embodiments, remote access managermay make a determinationas to whether requestis authorized based on any or all of the following: