Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
COMMUNICATION WITH A NETWORK DEVICE OVER A DATA NETWORK
Document Type and Number:
WIPO Patent Application WO/2009/086837
Kind Code:
A3
Abstract:
The present invention provides an access gateway, a device gatewayand a relay server for aiding an establishment of a network connection between a first computer having a first network address on a first network and a second computer having a second network address on a second network. An access gateway can actively establish a network route in the first computer and can forward traffic between the first computer and a relay server via a first persistent connection. A device gateway can connect to the second computer and can forward traffic between the second computer and the relay server via a second persistent connection. A relay server according to the invention can maintain persistent connections with an access gateway and a device gateway and can relay traffic between the two persistent connections.

Inventors:
STORM KIM FABRICIUS (DK)
Application Number:
PCT/DK2009/050002
Publication Date:
September 03, 2009
Filing Date:
January 06, 2009
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SECOMEA AS (DK)
STORM KIM FABRICIUS (DK)
International Classes:
H04L29/06
Domestic Patent References:
WO2005047991A22005-05-26
Foreign References:
US20020029276A12002-03-07
EP0838930A21998-04-29
Other References:
SIKORA A ET AL: "Virtual private infrastructure (vpi) initiative - an industry consortium for unified and secure web control with embedded devices", EMERGING TECHNOLOGIES AND FACTORY AUTOMATION, 2003. PROCEEDINGS. ETFA '03. IEEE CONFERENCE SEPT. 16-19, 2003, PISCATAWAY, NJ, USA,IEEE, vol. 1, 16 September 2003 (2003-09-16), pages 288 - 291, XP010670442, ISBN: 978-0-7803-7937-4
Attorney, Agent or Firm:
PLOUGMANN & VINGTOFT (P.O. Box 831, Copenhagen, DK)
Download PDF:
Claims:

Claims

1. An access gateway connectable to a first network for aiding an establishment of a network connection between a first computer having a first network address on a first network and a second computer having a second network address on a second network, the access gateway being capable of:

• establishing a persistent network connection to a relay server;

• establishing a network route in the first computer, the network route causing the first computer to route traffic having the second network address as destination address to the access gateway;

• receiving, from the first network, network traffic having the first network address as a source address and the second network address as a destination address, and forwarding said traffic to the relay server using the persistent network connection.

2. The access gateway according to claim 1, further being configurable to forward, to the first computer, using the second network address as source address, network traffic received via the persistent connection.

3. The access gateway according to claim 1 or 2, further being dynamically configurable to obtain the second network address from the relay server;

4. The access gateway according to any of claims 1 to 3, further being configurable to dynamically obtain, from the relay server, a list of port numbers, and to configure itself to not forward, for at least a first port number which is not on said list, traffic having said first port number as destination port.

5. The access gateway according to any of claims 1 to 4, further being configurable to dynamically obtain, from the relay server, a list of port numbers, and to configure itself to not forward traffic having a destination port which is not on said list.

6. The access gateway according to any of claims 1 to 5, wherein the access gateway is embedded in the first computer, enabled via a computer program running on the first computer.

7. The access gateway according to any of claims 1 to 5, wherein the access gateway is embedded in the first computer and is enabled via a computer program being executed in a virtual machine running on the first computer.

8. The access gateway according to any of claims 1 to 7, furthermore being capable of requiring an authentication before providing a functional connection to the second computer.

9. The access gateway according to any of claims 1 to 8, further being configurable to receive connectivity information from the relay server, a connectivity information comprising an identification of the second computer.

10. The access gateway according to any of claims 1 to 8, further being configurable to send a request for connectivity information to the relay server, and in response to receive connectivity information from the relay server, a connectivity information comprising an identification of the second computer.

11. The access gateway according to any of claims 1 to 10, further being configurable to send an indication to the relay server that the relay server shall send traffic that it receives from the access gateway via the first persistent connection, to a device gateway to which the second computer is connected,

12. A device gateway for aiding an establishment of a network connection between a first computer having a first network address on a first network and a second computer having a second network address on a second network, the device gateway being capable of:

• establishing a persistent network connection to a relay server;

• becoming configured to forward, to the second computer, network traffic received via the persistent connection and having the second network

address as destination address, using a first forwarding network address as source address;

• dynamically configuring itself to forward, to the relay server, via the persistent connection, traffic having the second network address as source address and said forwarding address as destination address,

the first forwarding address being either

• the first network address; or

• a network address of the device gateway, which network address is reachable by the second computer.

13. The device gateway according to claim 12, further being configurable to dynamically provide the second network address to the relay server.

14. The device gateway according to claim 12 or 13, furthermore being capable of maintaining a list of port numbers corresponding to active ports and/or ports to be accessible on the second computer and to forward said list to the relay server.

15. The device gateway according to any of claims 12 to 14, wherein the device gateway is embedded in the second computer, enabled via a computer program running on the second computer.

16. A relay server, configurable to maintain a first persistent network connection with an access gateway and a second persistent network connection with a device gateway, the relay server being configurable to provide a link for linking traffic between the access gateway and the device gateway by

• receiving network traffic from the access gateway via the first persistent network connection and forwarding the traffic to the device gateway via the second persistent network connection;

• receiving network traffic from the device gateway via the second persistent connection and forwarding the traffic to the access gateway via the first persistent network connection.

17. The relay server according to claim 16, furthermore being capable of maintaining connectivity information and being capable of providing connectivity information to the access gateway via a network connection thereto, a connectivity information comprising an identification of a computer connectable to

5 or connected to the device gateway.

18. The relay server according to claim 16 or 17, furthermore being capable of maintaining connectivity information and being capable of receiving a request for connectivity information from the access gateway via a network connection

10 thereto and to respond to the request by returning connectivity information to the access gateway, a connectivity information comprising an identification of a computer connectable to or connected to the device gateway.

19. The relay server according to any of claims 16 to 18, wherein at least some of 15 said connectivity information maintained by the relay server has an associated information identifier.

20. The relay server according to any of claims 16 to 19, further being capable of receiving, from the access gateway, a request to establish said link, the relay

20 server being configured to only establish the link upon receiving such a request.

21. The relay server according to any of claims 16 to 20, wherein the relay server is capable of receiving an information identifier together with the request for connectivity information, and to provide connectivity information associated with

25 said information identifier in response.

22. A computer program product which, when executed on suitable computing hardware, provides an access gateway according to one of claims 1-11.

30 23. A computer program product which, when executed on suitable computing hardware, provides a device gateway according to one of claims 12-15.

24. A computer program product which, when executed on suitable computing hardware, provides a relay server according to one of claims 16-21.

Description:

Communication with a network device over a data network

Field of the invention

The present invention relates to computer network communication.

Background of the invention

A number of methods exist by which one computer, computer A, connected to one network, network A, can be connected with another computer, computer B, connected to another network, network B. The choice of method often depends on the environment in which the connection is to be used. Factors such as a presence of firewalls or the requirement that encryption be used affects the choice. Some methods provide encryption capabilities, others do not. Some methods can be used across firewalls, others can not.

In the field of controlling/monitoring/maintaining industrial devices, a technician 110 who is on-site can typically obtain direct access to the industrial device 101 and can perform his tasks by connecting his computer (PC) 102 directly to the device, as illustrated in Fig. Ia. A number of the barriers that come with performing the same tasks via a remote connection are not faced.

Traditionally, remote control of industrial devices has been enabled by establishing and using a dial-up connection 105 as illustrated in Fig. Ib between the PC used for controlling the device and the device itself. The technician's PC is connected to a telephone modem 103, and similarly the device is connected to a modem 104, and a connection is formed by phoning the device modem 104 from the PC modem 103.

However, dial-up method is slow. Also, to be properly automated it requires that modems 104, 104b and 104c, illustrated in Fig. 2, used for connecting to corresponding industrial devices 101, 101b and 101c, must each have a unique telephone number associated with it. Though it means that each device is uniquely identifiable, this characteristic is a disadvantage in real-world scenarios. In case there are 10 devices on network B, all of which are to be available for remote control, all 10 devices must have unique telephone numbers. This means

that such telephone numbers must be established, programmed into the devices, and a list of the telephone numbers be maintained by the technician 110. Furthermore, access by a former employee 111 using his modem 113 at PC 112 can usually only be prevented by changing the password often required when using dial-up connections. However, this password is not provided centrally, so the password must be changed locally at each modem 104, 104b and 104c.

If the Internet 108 (see Fig. Ic) is involved when the technician wishes to connect to an industrial device, certain security requirements must typically be met. Furthermore, telephone numbers typically cannot, at least at present, be replaced simply by unique IP network addresses. One reason is that devices are typically placed behind a router 107 employing network address translation (NAT). The router maintains a number of rules and functions for controlling which traffic may enter or leave the network. A NAT router replaces source and destination addresses on traffic passing through it. This is useful for a number of reasons. For instance, it allows more computers to communicate over the Internet, overcoming the limited availability of IP addressed offered by the addressing format used in the current Internet Protocol, IPv4. Secondly, the NAT system in some sense "hides" the computers which it connects to the Internet. The "hidden" network structure is only available if explicitly communicated directly across the NAT router. However, the "hiding" has a cost in terms of flexibility. The very feature of hiding computers also adversely affects the complexity associated with communicating across the NAT router.

When using a NAT router for separating devices from the Internet, unique connectivity can be provided by assigning specific port numbers to each device. Device A might be addressable using port 40001 and device B be addressable using port 40002. However, this requires that the router be configured specifically for this purpose, which is cumbersome. Also, the method is typically undesirable from a security standpoint, for one because it actually exposes each device directly across the internet. Furthermore, implementation of encryption must be provided by software running on the PC, but even then, many industrial devices are not really designed to accommodate encryption.

Furthermore, the technician's PC 102 is also typically located behind a firewall, element 106 in Fig. Ic, which further adds to the NAT-related complications.

On-site configuration over a local network is illustrated in Fig. 3. The technician 5 110 simply connects his PC 102 to the local network 310, and then has access to the industrial devices on the network and can control the devices using his device management software 320. The control thus taking place on a local network, which is typically considered a safe environment, a reason why encryption is rarely built into industrial devices. 10

In view of the issues discussed above, this system is clearly not readily modifiable to accommodate the scenario in Fig. Ic, which includes traffic across the internet 108 and across two NAT-routers, 106 and 107.

15 A solution to the security issues could be to use a setup involving virtual private network connections (VPN). A practical approach, provided that devices have an integrated VPN client, would be to configure the devices to connect to a central VPN gateway. This is presently not easily accommodated for by devices, for much the same reasons that devices typically do not employ encryption as just

20 discussed. A more realistic approach is to install a VPN gateway at each device network. In either case, this creates a potentially very large virtual private network infrastructure, which can be complex to set up and manage, as it has to accommodate the potential network address conflicts which arise when joining existing networks together. For instance, referring to Fig. 4, two devices 401A and

25 401B on separate sites, Site A and Site B, behind firewalls 407A and 407B, respectively, will often have the same local network address (such as 10.0.0.1), simply because they are the same devices and perform the same functions. Thus, the practical thing to do is to simply use the same standard network address for the devices on each site. It is possible, but cumbersome, to overcome such

30 conflicts using explicit address translations, but doing so may cause severe problems for some types of protocols and configurations used by existing industrial devices and device management software. Furthermore, using VPN, all IP addresses in the subnet and ports are forwarded bi-directionally, which typically means that every device in the entire network can communicate with any

35 other device on the network. This is understandably a concern for device owners

who outsource device monitoring to an outside party. Extra measures would therefore be needed to limit access to and from specific devices within one site.

Summary of the invention

Various embodiments of the present invention mitigate various of the issues listed above. The invention uses an access gateway, a relay server, and a device gateway as aids in connecting a PC to an industrial device. The flexibility in connecting a PC to devices is increased over present technology and makes it easier to control access to specific devices at specific sites.

Furthermore, if a device supports more than one service, say it supports both an FTP server and a Web GUI, an administrator of the device gateway can decide which of these services are to be remotely available.

In a first aspect, the invention provides an access gateway connectable to a first network for aiding an establishment of a network connection between a first computer, such as a personal computer (PC), having a first network address on a first network and a second computer, such as an industrial device, having a second network address on a second network. The access gateway is capable of:

• establishing a persistent network connection to a relay server;

• establishing a network route in the first computer, the network route causing the first computer to route traffic having the second network address as destination address to the access gateway;

• receiving, from the first network, network traffic having the first network address as a source address and the second network address as a destination address, and forwarding said traffic to the relay server using the persistent network connection.

The network routes are used in order to make it appear to device management software running on the PC that the PC is connected to the industrial device at the location of the industrial device.

The persistent connection to the relay server helps connect the PC and the industrial device where firewalls otherwise complicate the establishment of such a

connection, for instance for the reasons discussed above. The persistent connection might for instance be established and maintained using the transmission control protocol (TCP). The persistent connection may also advantageously utilize validation and encryption through the use of a secure protocol such as transport layer security (TLS) on top of TCP.

The access gateway in itself does not connect the PC and the industrial device, but it provides functions that aid in the establishment of such a connection. Full connectivity is provided when the access gateway is used in conjunction with a relay server and a device gateway. These aspects of the invention are described in detail later on in this specification.

Device management software and industrial devices are still being designed for the scenario that the PC employing the device management software and the industrial device to be controlled are connected to the same local network. It is advantageous if the access gateway is furthermore configurable to forward, to the PC, using the second network address as source address, network traffic received via the persistent connection. This further helps to establish the appearance that the industrial device and the PC are connected to a local network at the site of the industrial device.

As will become apparent, the relay server can maintain connections to many industrial devices simultaneously. It is therefore advantageous if the access gateway is dynamically configurable to obtain the second network address from the relay server when establishing the routes and forwarding the traffic to and from the PC.

In some embodiments, the access gateway is also able to dynamically obtain, from the relay server, a list of port numbers, and to configure itself to not forward, for at least a first port number which is not on said list, traffic having said first port number as destination port. This step helps to provide a firewalling function in the access gateway. Rather than opening all ports, only ports provided from the relay server are opened. The access gateway may alternatively configure itself to not forward any traffic having a destination port which is not on said list. In other words, only ports on the list are forwarded. Another option is to not

forward certain ports, even if they are featured on the list. This makes it possible to restrict device services at the access gateway.

The access gateway can be implemented on hardware separated from the PC; or it can be implemented as a computer program running natively as a service/daemon on the PC. This can be implemented as a computer program assisted by a set of low-level drivers that implement a virtual network adapter in the PC for interfacing between the access gateway program and the device management software running on the PC.

Other approaches are of course available. However, the inventor has realized that it is particularly advantageous to implement the access gateway via a computer program executed in a virtual machine, such as VMware, running on the first computer, as this provides the possibility to have the access gateway appear to be a separate unit, while utilizing the virtual networking capabilities of the virtual machine to restrict accessibility and visibility to programs running on the hosting PC only. This aspect is described in more detail in relation to Fig. 5.

In some embodiments of the invention, the access gateway is furthermore capable of requiring an authentication before providing a functional connection to the second computer. Such an authentication can involve that the user must provide a password, or a user name and a password. It may also involve use of certificates. Such information could be provided via an interface on the access gateway, or authentication could be provided elsewhere and a signal then be sent to the access gateway to indicate that an authentication has properly taken place.

As will be described in more detail below, the relay server is connected to a device gateway, to which the industrial device is connected. The relay server, having these connections, may therefore provide connectivity information to the effect of "which devices can be contacted?", "may I, as an authenticated operator, control industrial device number 5 on network number 321?" etc. In this light, the access gateway may therefore advantageously also be able to receive connectivity information from the relay server. The connectivity information advantageously at least identifies the second computer (such as an industrial device, as mentioned above), at least if it is connected to the device gateway. The relay server may

also identify the industrial device even if it is not connected to the device gateway.

In case the access gateway is also able to send a request for connectivity information to the relay server, and in response receive such connectivity information, the access gateway can be used to control access to specific industrial devices.

In particular, the access gateway may be configurable via a user interface, the user interface being capable of displaying connectivity information obtained from the relay server, and to receive a user indication that a connectivity to the second computer is desired, and in response, to send an indication to the relay server, instructing it to provide a link to the device gateway connected to the second computer. More specifically, the access gateway sends an indication to the relay server that the relay server shall send traffic that it receives from the access gateway via the first persistent connection, to the device gateway to which the second computer is connected. This means that the relay server provides connectivity on the instruction of the access gateway. This allows the access gateway to be used for controlling access to the device.

A second aspect of the invention provides a device gateway for aiding an establishment of a network connection between a first computer, such as the PC referred to above, having a first network address on a first network, and a second computer, such as the industrial device referred to above, having a second network address on a second network. The device gateway is capable of

• establishing a persistent network connection to a relay server;

• becoming configured to forward, to the second computer, network traffic received via the persistent connection and having the second network address as destination address, using a first forwarding network address as source address;

• dynamically configuring itself to forward, to the relay server, via the persistent connection, traffic having the second network address as source address and said forwarding address as destination address,

the first forwarding address being either

• the first network address; or

• a network address of the device gateway, which network address is reachable by the second computer.

For the purpose of making the system as automated as possible, the device gateway can be configurable to dynamically provide the second network address to the relay server. If a change occurs to devices connected to the device gateway, the device gateway can transmit this information to the relay server, which will then reflect that when receiving a request for connectivity information from an access gateway.

It is advantageous for the security and flexibility of the system if the device gateway is furthermore capable of maintaining a list of port numbers corresponding to active ports on the second computer and/or ports to be accessible and to forward the list to the relay server.

The device gateway could be integrated with an industrial device. Often, though, it is convenient that the device gateway is a separate unit. Integrated or not, the device gateway can be provided embedded in the second computer, enabled via a computer program running on the second computer.

A third aspect of the invention provides a relay server, also referred to above.

A relay server according to the invention is configurable to maintain a first persistent network connection with an access gateway and a second persistent network connection with a device gateway. Furthermore, it is configurable to provide a link for linking traffic between the access gateway and the device gateway by

• receiving network traffic from the access gateway via the first persistent network connection and forwarding the traffic to the device gateway via the second persistent network connection;

• receiving network traffic from the device gateway via the second persistent connection and forwarding the traffic to the access gateway via the first persistent network connection.

In this way, the relay server ultimately provides the connectivity between the PC and the industrial device, or multiple industrial devices. The relay server communicates traffic between the access gateway and the device gateway. However, this translates directly into a connection between the PC and the industrial device by virtue of the functionality of the access gateway and the device gateway.

Advantageously, as also discussed in relation to the access gateway, the relay server can be made able to maintain connectivity information and to provide connectivity information to the access gateway via a network connection thereto. The network connection needs not be the first persistent connection, though this is a convenient choice of connection. A connectivity information comprises an identification of a computer connectable to or connected to the device gateway.

Adding further functionality, the relay server provides the connectivity information in response to a request from the access gateway. More precisely, the relay server is capable of receiving a request for connectivity information from the access gateway via a network connection thereto and to respond to the request by returning connectivity information. The network connection could be the first persistent connection, or it could be a separate connection.

It is useful if the relay server associates an information identifier to at least some of the connectivity information that it maintains. The information identifier may for instance be a username and/or a password, or a certificate of some sort. When the access gateway request information, it might include an information identifier, such as a username (such as of an authenticated user), and the relay server may in response provide only connectivity information which is associated with that information identifier (the username). In this way, access to the various industrial devices connected to the relay server can be controlled.

The relay server may advantageously be enabled to receive, from the access gateway, a request to establish a link between the access gateway and the device gateway, and to establish such a link only after having received such a request.

In a further aspect, a computer program product for enabling suitable computing hardware to perform the function of an access gateway according to the first aspect is provided.

In a further aspect, a computer program product for enabling suitable computing hardware to perform the function of a device gateway according to the second aspect is provided.

In a further aspect, a computer program product for enabling suitable computing hardware to perform the function of a relay server according to the third aspect is provided.

Brief description of the drawings

Fig. Ia illustrates a situation where a technician has direct access to an industrial device to control it with a PC.

Fig. Ib illustrates one conventional way of remotely connecting a PC to an industrial device.

Fig. Ic illustrates a typical network structure faced when desiring to connect to an industrial device via the Internet.

Fig. 2 illustrates some disadvantages associated with the use of a dial-up connection for remotely controlling an industrial device.

Fig. 3 illustrates how a technician can perform on-site configuration of industrial devices that are connected to a local network.

Fig. 4 illustrates a connectivity problem not solved by present technology.

Fig. 5 illustrates a network connection according to the invention, allowing a connection to be made between a PC and devices on two different sites.

Fig. 6 illustrates a flow for setting up a connection between a PC and a device on a 5 remote site.

Detailed description of selected embodiments

Fig. 5 illustrates a how the invention can be used to connect a PC 102 at a maintenance site 505M to industrial devices 401A and 502A at a site, Site A 10 (505A), and to industrial devices 401B, 502B and 503B at another site, Site B (505B), to allow the devices to be controlled remotely using device management software running on the PC.

The devices at Site A each have a local network address, as illustrated. Device 15 401A has address 10.0.0.1 and device 502A has address 10.0.0.2. At Site B, device 401B has address 10.0.0.1, device 502B has address 10.0.0.2, and device 503B has address 10.0.0.6.

The access gateway 511 at the maintenance site has formed a persistent 20 connection 515M to relay server 512, through the maintenance site firewall 106. Device gateways 513A and 513B have each formed persistent connections, 515A and 515B, respectively, to the relay server 512, through site firewalls 407A and 407B, respectively. Device gateway 513A at Site A has address 10.0.0.10 and device gateway 513B at Site B has address 10.0.0.9. 25

The persistent connections 515A, 515B, and 515M are created by the gateways, thereby opening "tunnels" through the firewall. Unless the firewalls 407A and 407B were configured specifically to receive a connection from outside their sites, such as via a port forwarding configuration, the devices and device gateways 30 would not have been readily accessible from outside the sites. In the present invention, the gateways form the connection, thereby circumventing the need to reconfigure the firewalls. Often, maintenance is performed by an outside party, and the firewall configurations of 407A and 407B can therefore be assumed to be off limits to the maintenance party. The device gateways mitigate this.

Fig. 6 illustrates an example of how a connection can be established. At some point, for instance when being connected to the network, the device gateway will establish (step 601) its persistent connection to the relay server. In what is typically a separate workflow, the device gateway has been configured, typically manually, with a list of devices. In Fig. 5, device gateway 513B is configured to "know" one or more of the devices 401B, 502B and 503B. In case a device needs not be remotely accessible, say device 502B, the device gateway is simply not configured to act as a device gateway for that device. When the device is connected to the network at Site B, it will be detected by the device gateway, and the device gateway will provide it in its list (step 603) of devices (and device ports and other information, depending on the desired functionality) to the relay server's storage 650.

When a user wishes to communicate with a device using his PC (102), he will contact his access gateway (step 605) and ask for a list of devices, which can be referred to as "connectivity information". This list could be stored at the PC or in the access gateway, but typically it will be obtained from the relay server (step 609), which has obtained this information from the device gateways, for instance as described above. This allows the PC to display up-to-date configurations and statuses in step 611. If device gateway 513B is configured to deal with device 502B, but registers that the device is not online (cannot be contacted), the list of devices that it sends to the relay server will not include that device, or it might provide an identification of the device, along with a status indicator indicating that the device in non-functional, information which is obviously valuable in itself.

For security reasons, the access gateway may advantageously first ask for a username and password or similar entity. Having been authenticated, the access gateway establishes its persistent connection to the relay server (step 607) and requests connectivity information therefrom (step 609). The request might contain the username (as illustrated by step 610a), which may be used by the relay server to provide only some of the connectivity information back to the access gateway (in step 610). It might for instance be that the user who has just logged in may only access Site A, or only Site B, or only devices 502A, 502B and 503B. The relay server may then provide only this connectivity information to the

access gateway, in step 610. The access gateway therefore will not show any other devices. Of course, the access gateway might instead be provided with all the connectivity information maintained by the relay server, but non-allowed options may be "greyed out" (shown, but not selectable) when the list is shown to the user. Or the user may select the device, but the relay server will not establish a connection between the persistent connection 515M and the relevant persistent connection to the relevant device gateway because the username is not associated with the selected connection.

Once the user has selected an allowed device (in step 613), say 503B, the access gateway configures, in step 615, the PC to forward, to the access gateway address (192.168.1.128), traffic having the device address (i.e. 10.0.0.6) as destination address. The access gateway asks the relay server, in step 617, to setup a link between the persistent connection 515M and the persistent connection to the device gateway to which the device 503B is connected, which is device gateway 513B, and the persistent connection is 515B. Finally, the relay server also informs the device gateway of the address of the PC, in step 619.

At this point, a functional connection has in fact been established.

Device management software on the PC is "used to" sending traffic to the local address of the device, i.e. 10.0.0.6. It continues to do so in the present invention. The route set up in the PC by the access gateway forwards such traffic to the access gateway, which forwards the traffic to the relay server via connection 515M. The relay server then relays the traffic through 515B, as it was asked to do by the access gateway. When the device gateway 513B receives the traffic, the destination address is precisely that of the device 503B, and thus the device gateway can immediately pass the traffic on to the device. It does so by using its own network address as source address, i.e. 10.0.0.9.

The configurations at Site A and Site B are slightly different. At Site A (505A), the device gateway (513A) has two interfaces. It might for instance be incorporated into a local router or similar device. At Site B, the device gateway (513B) is connected to the local network and obtains a local network address (in the present example 10.0.0.9) similarly to the devices themselves. In both cases, the

device gateways provide the connection between the relay server and the devices on the two sites, but they do so slightly differently.

In the case of Site B, the device gateway will forward, as just described, traffic using its own local address (10.0.0.9) as source address. A reply from a device at Site B, say device 503B referred to above, will use that address as destination address on its traffic. The device gateway will forward the traffic to the relay server, which will relay the traffic to the access gateway. The source address is still that of the device 503B, and the access gateway will forward the traffic to the PC using the network address of the device as source address. It does so because it was configured to do so when the user selected which device he wanted to connect to.

At Site A, the device gateway acts as a default gateway and will forward traffic from the persistent connection 515A to a device, say 401A, using the address of the PC as source address (192.168.1.17). The device will respond using that address as destination address and its own address (10.0.0.1) as source address. The device gateway, being the device's default gateway will forward that traffic to the relay server, which relays it to the access gateway. Finally, the access gateway forwards the traffic to the PC using the address of the device (10.0.0.1) as source address.

In the particularly advantageous implementation that uses a virtual machine running on the PC, and an access gateway implemented by executing suitable software within the virtual machine, the access gateway signals to the PC that it shall establish the route described above by broadcasting a message on the virtual network interface of the virtual machine, the message comprising information about the route to be established in the PC. In an implementation using VMware, the same network interface is established "in" the PC by VMware, and the PC will therefore "receive" the broadcast message. To receive such message, the PC runs a "dynamic route setup" service that will listen for such messages on the virtual network and establish the required route upon receiving the message. (The service may also erase the route when the connection to the device is to be closed.)

By running the access gateway as a hosted application on the virtual machine, the access gateway can create the necessary IP aliases for the device in such a way that they are only visible internally to other applications running on the PC itself. This means that the PC can be connected to any network without the risk of interference with existing IP address structures in the network. It also allows several technicians to work on the same local network (such as at location 505M, see Fig. 5) and to connect to different sites with identical device addresses without the risk of mixing such conflicting addresses in the local network. PC 102 (see Fig. 5) at the maintenance site 505M can connect to 401A (with address 10.0.0.1) and a second PC on the maintenance site can connect to device 401B (also having address 10.0.0.1) without experiencing interference in the traffic to 10.0.0.1. At the maintenance site 505M, that traffic actually only exists inside the PCs.

This also means that the integrity of the communication between the PC and the access gateway is ensured. A separate security protocol around the access gateway can therefore be avoided. In case the access gateway is on hardware separated from the PC, a validation or encryption protocol is preferable to avoid traffic hijacking.

In the above implementation, the address 192.168.1.128 of the access gateway is in fact the network address of the virtual machine on the virtual network created by VMware on the PC. The network address 192.168.1.17 is the PC's address on the virtual network. When the user selects device 503B, the access gateway software, running in the virtual machine, broadcasts a message to that effect on the virtual network. The dynamic route setup service on the PC listens to the virtual interface and will receive the message and establish the route in the PC. When the device management software sends traffic to the device address, 10.0.0.6, it does so using the virtual network interface because traffic to 10.0.0.6 is forwarded to the access gateway at 192.168.1.128, which is in the subnet of the virtual network.

The access gateway also establishes the alias 10.0.0.6 (the address of the device to be accessed) for its own address on the virtual interface (192.168.1.128). This

makes the access gateway pick up traffic on the virtual network having destination address 10.0.0.6.

The invention also easily allows the same instruction to be given to multiple devices at once. By indicating that for instance devices 401A, 502B and 503B shall receive a message, the relay server simply relays the traffic from the access gateway to the different devices, for instance by connecting to the persistent connections to respective device gateways in series.

The present invention has been described by way of examples. The examples and the embodiments they employ shall not be considered as limiting the invention to only those embodiments.

Although the invention has been discussed in relation to industrial devices, the invention is generally applicable to other types of computers, such as PC's.

Some of the steps and elements of the invention can be realized in several ways. Some may be realized using dedicated hardware, or they may be implemented by implementing specially adapted software on a general-purpose computer. Certain hardware elements of the invention may be divided into separate but interacting units, and some elements might be integrated to form a single unit, but nonetheless fall within the scope of the claims.