WO2009062504A1

WO2009062504A1 - Secure communication between a client and devices on different private local networks using the same subnet addresses

Info

Publication number: WO2009062504A1
Application number: PCT/DK2007/050168
Authority: WO
Inventors: Michael Jacobsen
Original assignee: TNM FARMGUARD APS
Current assignee: TNM FARMGUARD APS
Priority date: 2007-11-13
Filing date: 2007-11-13
Publication date: 2009-05-22
Anticipated expiration: 2010-05-13

Abstract

Method and system for providing secure communication between a client and one or more network devices located on private net works placed behind different gateways, which private networks at least partly use the same local subnet addresses for said network devices, wherein a secure IP connection is established between said client and an intermediate server comprising information of accessible gateways and network devices and their corresponding local addresses, and the connections between clients and devices are mapped at a proxy server by means of a virtual network interface and routing at application level.

Description

Secure communication between a client and devices on different private local networks using the same subnet addresses

The present invention relates to a method and a system for pro- viding secure communication between a client and one or more network devices located on private networks placed behind different gateways, which private networks at least partly use the same local subnet addresses for said network devices.

Modern production facilities utilise communication capable de- vices for controlling and monitoring production processes and production equipment used for operating of the production. A computer located in the production facilities typically manages the devices in order to provide an overview of the production and facilitate the operation or the devices themselves can act as computers. Typically, in most production facilities, several equipment vendors are involved and therefore each vendor in principle provides a computer with an interface, which can be used for controlling and monitoring the production facilities.

In many cases, a vendor providing devices for a production facility or third parties related to the production may be able to better serve the customer by having remote access to the devices controlling and monitoring the production or for instance inventory levels or orders maintained on a computer located on a customer's private network. Hence, computers or devices in such production facilities are configured as private local networks, which can communicate with the Internet in order to provide remote access to the devices or computers managing and controlling several devices. Such private local networks are typically placed behind a router with a firewall, which routes the traffic and protects the networks from intruders.

The access to the computers on the networks is typically pro- vided by configuring the router or firewall with a port dedicated to the IP address of the computers on the private network, which then can be accessed via the internet by users knowing of these port and configurations. Even if the access to the computers further more requires login credentials, this approach offers a limited security as the computers are practically directly exposed to everyone on the Internet. It can be crucial if intruders with knowledge of the poor security, be it intended or non- intended, take control of devices controlling and monitoring the production and thereby sabotage the production. From WO 03/041360 a method for accessing resources on a private network via an intermediate server is known, which method comprises receiving a login request from a user for access to the intermediary server, authenticating the user, subsequently receiving a resource request from the user at the intermediary server, obtaining ac- cess privileges for the user, determining whether the access privileges for the user permit the user to perform the particular operation at the private network and preventing performance of the particular operation if the access privileges for the user do not permit the user to perform the particular operation at the private network. Private networks used at production facilities or in small business networks are typically configured with a standard LAN configuration, which facilitates the installation and configuration. However, the use of standard LAN configurations makes it even easier for intruders to gain access to the network, but it also poses another problem, because standard configured networks often use the same private local network addresses.

Even when using an intermediate server for managing the access to the devices controlled by the computers on the private networks, it is still important to provide secure communication between the com- puters at the private networks and the intermediate server. For this purpose standard IPsec disclosed in RFC2401-2412, which is implemented in the kernel of the operating system hosted on the intermediate server, is normally used. However, standard IPsec systems are not capable of connecting to two or more private networks (LANs) using the same sub- net addresses because the routing information turns out to be ambiguous.

When the settings for an IPsec connection is setup between a server and a private network (LAN), a rule is added to the routing table telling the system to use the particular IPsec connection for packets des- tined to local IP subnet addresses on that private network. If the subnet addresses of the private networks overlap, the routing table becomes ambiguous, since the routing table fails to determine which IPsec connection to use for a packet destined for a local subnet address used on more than one private network. This is fatal in order to provide a proper routing when using an intermediate server for providing access to computers on private networks.

In many solutions where an external user accesses a computer on a private network (LAN) via the Internet, the computer requires login credentials such as a user name and password. Often different users are provided with the same standard password, which even can be a standard password provided by the equipment vendor. However, in case of change in business relations or suppliers to a production, it is desirable to deny a single user access to a given system or local computer. Having login credentials at hand and knowing of the local network configurations described above, former business relations can still locally access the computers on the private network. When using an intermediate server handling the access to computers on a private network, the disclosure of such passwords can be prevented. However, traditional login procedures will eventually disclose the login credentials in the data stream between a computer on a private network and a computer client gaining access to said computer on the private network via the Internet, which makes it possible to intercept the login credentials.

On the basis on the above-mentioned problems it is the object of the present invention to provide a method and system for providing secure communication between a client and one or more devices located on private networks using the same subnet addresses.

It is a further object of the present invention to provide a method and a system for keeping login credentials required for gaining access to computers on a private network secret to users accessing the computers.

This is achieved with a method and a system according to the opening paragraph wherein a secure IP connection is established between said client and an intermediate server comprising information of accessible gateways and network devices and their corresponding local addresses, a virtual network interface comprising a readable and writable file interface and a plurality of virtual IP subnet addresses configured at said intermediate server, each of said network devices is associ- ated with one of said plurality virtual IP subnet addresses, secure IP settings between the intermediate server and the gateways are negotiated and managed at application level on said intermediate server, packets received at the intermediate server from the client for the network devices are sent from the virtual network interface to the virtual IP ad- dresses associated with the devices and then read from the file interface, the source addresses of packets read from the file interface are replaced with the real IP address of the intermediate server and the destination addresses of said packets from the client are replaced with the actual local subnet addresses of the devices, the packets are encrypted and au- thenticated according to the secure IP settings negotiated for the gateways in order to provide encrypted packets, said encrypted packets are sent to the gateways associated with the devices.

Thereby access and the secure connections from a plurality of computers having Internet access to devices such as standard computers on several local private networks, which are using the same private network addresses, is managed by intermediate server. This makes it possible for a user to connect to several devices at one point, but it also makes it considerably easier to manage the users access to the devices. Furthermore, the solution also improves several security aspects of such a system because users of the system are not provided with any information such as IP addresses, which can be used for directly attacking the devices without the intermediate server.

In a further development of the invention, encrypted payload packets received from the gateways are authenticated and decrypted by using the secure IP settings negotiated for the gateways, the source addresses of the incoming packets from the gateways are replaced with the associated virtual IP subnet addresses, and the destination addresses are replaced with the virtual network address, and the packets are written to the file interface of the virtual network interface, received at the virtual network interface and sent to the client.

By using the same virtual network interface in both directions, it is possible to use the connections for communication and still utilize the operating system for sending packets and for linking the correct data streams from the computers to the devices. Hence, the system manages connections and settings for establishing secure connections at the intermediate server where the data streams are linked.

In another aspect of the invention, each network device is associated with a unique connection identifier. This makes it easier for the user to identify the individual devices and also facilitates the administration of the system. When each device furthermore is associated with at least one port number for communication connections, it is possible to differentiate the access to the devices by using different port numbers for different access purposes. This makes it possible to provide a specific access directed at for instance the owner or vendor of a device and another access for standard users of the system such as subcontractors or employees.

In another embodiment of the invention, the checksums of the encrypted payload packets are recomputed after replacing the source addresses and the destination addresses in order to protect against erroneous packets and maintain the robustness of the used protocols.

In another aspect of the invention, the secure IP settings between the intermediate server and the gateways are negotiated at application level by means of an IKE daemon bypassing the kernel of the in- termediate server and accepting ambiguous routing information, which is managed at application level and thereby enabling the use of IPsec connections to the users without providing the kernel of the operating system with ambiguous routing information.

In another embodiment of the invention, the intermediate server monitors the data streams between the client and the devices in order to manage login credentials required by the devices, by modifying the login credentials comprised in said data streams.

This provides for a more secure system because login credentials are removed from the data streams to the computers connecting to the intermediate server.

In order to enable access to devices using virtual network computing (VNC), in a further development the intermediate server manages the login credentials by answering a challenge comprised in said data streams in order to modify the data streams and to provide the devices with the required login credentials.

In another aspect of the invention the system comprises a central server for managing the access of clients to the intermediate server, which adds a further security layer to the system. Another aspect of the invention is a system comprising a plurality of intermediate servers, which makes it possible to provide redundancy to the system and to balance the load on the system to several intermediate servers.

In the following the invention will be described in further detail by means of examples of embodiments with reference to the schematic drawing, in which

Fig. 1 shows a system according to a preferred embodiment of the invention,

Fig. 2 shows a system according to another embodiment of the invention,

Fig. 3 is an exemplified system of an embodiment of the invention,

Fig. 4 shows a detail of a method according to the invention,

Fig. 5 illustrates the mapping used in the example shown in Fig. 3,

Fig. 6 is another detail from the example of the mapping used in the example in Fig. 3.

Fig. 1 shows a system 1 according to the invention comprising a computer client 2 running a client application adapted to connect and communicate with an authentication server 3 and a proxy server 4. The clouds 5a, 5b illustrate a public communication network such as the Internet. The proxy server 4 is adapted to communicate and establish connections with several independent local area networks (LANs) 6a, 6b, 6c, which are located respectively behind gateways 7a, 7b, 7c. The gateways are typically a standard combined router/firewall using one of the reserved private networks (subnets) defined in RFC 1918 such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 and prevent the networks from being directly accessible from the Internet. The private networks 6a, 6b, 6c are for instance used in production facilities such as a factory with a production line and a stockpile, or they can be used in a farm for breeding animals. The devices 8a-8f on the private networks 6a, 6b, 6c are standard computers or special purpose controlling devices used for monitoring and controlling equipment used in the production having a communication interface such as Ethernet. Such devices can for instance be used for monitoring temperature, inventory levels of animal feed or the ventilation system of a farm. Devices for such special purposes are often vendor specific and customized to the specific use. In a preferred embodiment, the invention is used in a system as illustrated in Fig. 1. At a farm comprising a local area network 6a, two different equipment vendors could for instance supply the devices 8a and 8b. The device 8b could be a standard computer only monitoring and controlling a single point in the production.

The device 8a is also a standard communication enabled computer but it is not directly controlling or monitoring the production facilities or specific pieces of equipment. The device 8b is gathering information from special purpose devices 9a, 9b, 9c, which can be integrated in the production facilities more easily than a standard computer. Hence, the devices 9a, 9b, 9c are controlled by the computer 8a and the main purpose of computer 8a is therefore to gather information from the distributed devices 9a, 9b, 9c in order to make them accessible by means of a standard communication interface such as a web browser and the Internet. It is evident that the devices 9a, 9b, 9c can also be standard computers, which are providing the device 8b with the required information and that the devices 9a, 9b, 9c and 8b could be another network within the private local network 6a. The communication between the device 8a and the devices 9a, 9b, 9c is often based on a secret proprietary and vendor specific protocol. Hence, with respect to the present invention a device on the private local networks can be under- stood as standard computers or communication enabled devices connected to such a standard computer, which are hosting one or more services that are needed by the connecting client 2. Fig. 1 illustrates one client 2 connecting to devices on different local private networks. How- ever, the system is designed such that multiple clients may connect to several clients.

In another embodiment shown in Fig. 2, the proxy server 4 is customized for or even integrated with the firewalls used at the private local networks 6a, 6b, 6c. Thereby all traffic is not sent through a central proxy server and thereby the load on the system is distributed between a larger number of servers, which provides a more stable and robust system. However, there is still a connection between the proxy servers 4 and the central server 3 for authentication the setup of connections between a client 2 and the proxy server 4, which central server 3 provides access to the devices of the private local networks. In another embodiment (not shown) a plurality of proxy servers are used, which are positioned with respect to the production facilities but still within the infra structure of the Internet for connecting to several private local networks at the production facilities. When the server 3 has authenticated a user, data streams between the client 2 and the devices 8a-8f are established directly through the proxy server 4. The communication between the client 2 and the proxy server 4, for instance, goes through an encrypted TCP stream e.g. by using RSA encryption. Commands and data are transmitted using a small header comprising the type of operation such as open, close, send data and the data needed to perform a given operation. When a user at a client 2 needs a data stream to a device 8a-8f, a client application adapted to connect to the proxy server 4 is used for opening a listen socket on the local machine. In order to connect to a device 8a-8f, the client 2 sends an open connection message to the proxy server 4 comprising a connection device ID (cf. Fig. 5), which is unique for each device 8a-8f and which is only used within the system in order to provide the devices with identifications with can be put in context by the users of the system. Hence, the client 2 connects to the proxy server 4, which handles the connections to the devices 8a-8f.

Fig. 3 is an example showing the routing problems solved by the present invention. In order to avoid ambiguous routing tables at the proxy server 4, a system according to the invention provides its own routing system. In Fig. 3 the central server 3 is omitted for the sake of simplicity. The gateways 7a, 7b, 7c are IPsec enabled routers assigned with unique IP addresses for interfacing the private local networks 6a, 6b, 6c with the Internet. Since these private local networks are using the same standard IP settings, some of the devices are also using the same local IP addresses. IPsec is a set of cryptographic protocols used to secure packet flow, mutual authentication and to establish cryptographic parameters.

In a preferred embodiment, an IKE daemon is used to negotiate the IPsec settings such as encryption and authentication keys in order to handle IPsec connections from the proxy server 4 to the devices 8a-8d and in order to keep the routing information away from the kernel of the operating system, which normally handles the routing information contained in the IPsec settings. This is done by using a modified version of an IKE daemon such as the Racoon IKE daemon, which is modified not to fail if it detects possible ambiguous routes, and which provides the negotiated settings to the proxy server running at application level instead of providing it to the kernel of the operating system. With this information the proxy server 4 receives and sends encapsulated security payloads (ESPs) comprising encrypted and authenticated data instead of the operating system.

The proxy server 4 comprises a virtual network interface having a private subnet with virtual IP subnet addresses that does not collide with the real network that the proxy server 4 is connected to. A virtual network interface has the same characteristics as a physical network in- terface, such as a network address, a subnet and MTL), but instead of being connected to a physical cable, it is associated with a readable and writeable file. If a virtual network interface sends data, the data can be read from the file, and if data is written to the file, the virtual network interface sees it as incoming data. Data written to the file destined for the virtual network interface will be handled just as if it arrived on a network cable to a physical network interface. In some operating systems, the option of setting up virtual network interfaces is implemented in the kernel and by making a call to the system a virtual network inter- face can be configured. However, the functionality can also be installed as an extra module to the operating system.

As an example, the private network 192.168.32.0/24 is used and the proxy server 4 is assigned the virtual IP address 192.168.32.1. The aforementioned virtual network interface enables reading and writ- ing of IP packets to the file interface. When a number of bytes are written to the file interface, the network interface sees it as something on its virtual network. If a packet is generated on the virtual network, the bytes can be read from the file interface.

In the following example, it is assumed that the real IP address of the proxy server 4 is 100.100.100.100. At the proxy server 4, there is made a mapping between virtual IP addresses and the IPsec connections to the routers negotiating access to the devices. For example as illustrated in the table of Fig. 5 the virtual IP address 192.168.32.2 is mapped to the device with the ID A having the local IP address 192.168.1.50 (cf. Fig. 3) behind the router with IP 77.77.77.77, and correspondingly the virtual IP address 192.168.32.3 is mapped to the device B also having the local IP address 192.168.1.50 (cf. Fig. 3) but behind the router with IP address 88.88.88.88. Hence, the virtual IP addresses are also mapped to the IPsec connections from the proxy server 4 to the routers 7a, 7b, 7c. The entries in the table of Fig. 5 correspond to the situation illustrated in Fig. 3

Fig. 4 illustrates the mapping of virtual IP addresses to the IPsec connections and the devices associated thereto. Data, illustrated with 15, arrives from a client 2 to the proxy server 4. A part of the proxy server 4 denoted 10 receives the data and sends it to the virtual network interface. Hence, the data is send to the virtual network at the point 13. Depending of the state of the system, connections to the devices 8a, 8b, 8c, 8d can be set up at this point as well. The packets sent to the virtual network interface can then be read from the file interface, which is illus- trated with 14a, 14b. In other modules 12a, 12b of the proxy server 4, packets read from the file interface are adapted and encrypted before they are sent towards the right hand side of the figure, i.e. they are sent to the correct routes, for instance by means of the operating system. The left hand side of the cloud 11 illustrates a network interface adapted to establish connections, send and receive data. At the right hand side of the cloud 11, there is a file interface where the data can be read and written as a series of bytes.

The operating system is handling the correct linking of data streams and in particular TCP data streams between clients 2 and the proxy server 4 at one side and the proxy server 4 and the devices 8a, 8b, 8c, 8d at the other side. The box 10 is handling the connection from the client 2, where the point 13 in this example refers to the virtual IP 192.168.32.1. The cloud 11 illustrates the virtual network and the boxes 12a, 12b illustrate the mapping of virtual IP addresses to IPsec connections and the devices behind them. In the above-mentioned example, the point 14a refers to the virtual IP address 192.168.32.2 and the point 14b refers to the virtual IP address 192.168.32.3. If a packet is sent to a virtual IP from the point 13, the IP packets can be read at the virtual file interface. If the proxy reads a packet on the virtual network interface destined for the virtual IP address 192.168.32.2 (device A), the following steps are performed.

The virtual source IP 192.168.32.1 is changed to 100.100.100.100, which as mentioned above, is the real IP address of the proxy server 4 and the destination IP address 192.168.32.2 is changed to 192.168.1.50, which is the local private IP address used for the device 8a behind the router 7a.

If the packet is a TCP or L)DP packet, the embedded checksums are recomputed as they depend on the changed information. The packet is encrypted and authenticated according to the IP- sec setup for the router 7a in order to create an ESP packet.

The packet is sent to the router by means of the operating system.

When a ESP packet is received from the router 7a, the steps are essentially performed in reverse order, and comprising the following steps:

The authentication field is verified and the ESP packet is decrypted by using the IPsec setup for the router 7a. The decrypted packet contains the source IP that is the local IP address of the device 8a, which is device A in Fig. 3. Provided with the IP of the router 7a and the local IP address of the device 8a, the corresponding virtual IP address can be looked up.

Then the source IP address (192.168.1.50) is replaced with the virtual IP address (192.168.32.2) and the destination IP address is changed from the real IP address (100.100.100.100) of the proxy server 4 to the virtual IP address (192.168.32.1).

If needed, checksums are computed and the packet is written to the virtual network at point 14a. The packet then appears at the network interface at point 13 and the subsystem of box 10 receives and connects the packet to the correct data stream to the client having made a request of communication with the device. Hence, the proxy server 4 connects the data streams between the client and the proxy server 4 and between the de- vices and the proxy server 4.

This procedure effectively maps a virtual IP address to a device behind a IPsec router, and it is possible to connect to several routers using the same subnet addresses because the routing is managed by the proxy server and not by the operating system. All TCP and L)DP ports are transported through the connections. Other protocols such as ICMP can also be supported as long as it is possible to perform network address translation.

As shown in Fig. 6, there may exist a number of connection types for each device. This is shown in Fig. 6 where device A is associ- ated with two different connection types denoted by the connection ID Ci and another connection ID C₂, which are characterized by different port numbers. Connection Ci uses port 80 and is used for ordinary connections and connection C₂ uses port 443 and is used for administrative purposes. When each connection to a device is associated with both a port number and a connection ID it is possible to provide differentiated access to the users of the system and thereby improving the overall security. A system according to a preferred embodiment of the invention is designed such that users from outside a local private network via the system can access services on devices on the network. In some cases such services require a user name and a password or other credentials. When a user is logged in to the proxy server 4, the user does not have to remember passwords or manually establish access to any devices. Hence, as described in detail in the above, the proxy server 4 establishes the connections to the devices and handles the logon. This makes it possible to remove a user form the system and thereby deny access to the devices. If the user had the password, it would be possible manually to connect to and login to the devices.

Therefore, the proxy server 4 manipulates the content of the data streams comprising the above-mentioned login credentials. In http form login the credentials are hidden to the user by creating a logon POST with the appropriate fields. However, instead of the correct user name and password the request is supplied with fake data. The proxy server 4 monitors the stream and when the fake data are observed, they are changed to the correct data, which are then solely sent to the devices. If the devices are using http basic authentication, the proxy server 4 simply adds an extra header field to each http request comprising the login information needed by the service on the device.

The VNC protocol allows for logins with and without password where the password login is based on a challenge/response scheme. The process for using VNC for login goes as follows. The proxy server 4 receives an "open request" for a VNC connection from the client 4 and connects to a VNC server (not shown) for exchanging version information and authentication modes. If the VNC server demands password authentication, the proxy server 4 answers the password challenge using the password for the current user requesting the connection. Hence, the proxy server 4 exchanges data to make the connection appear to the application at the client as if the server did not need a password. When the challenge/response login has been accepted by the VNC server, the data streams from the client 4 to the proxy server and from the proxy server 4 to the devices are connected and can continue to forward data back and forth without interference.

The invention should not be regarded as limited to the embodiments shown and described in the above, but several modifications and combinations may be carried out without departing from the scope of the appended claims.

Claims

P A T E N T C L A I M S

1. Method for providing secure communication between a client and one or more network devices located on private networks placed behind different gateways, which private networks at least partly use the same local subnet addresses for said network devices, wherein a secure IP connection is established between said client and an intermediate server comprising information of accessible gateways and network devices and their corresponding local addresses, a virtual network interface comprising a readable and writable file interface and a plurality of virtual IP subnet addresses configured at said intermediate server, each of said network devices is associated with one of said plurality virtual IP subnet addresses, secure IP settings between the intermediate server and the gateways are negotiated and managed at application level on said intermediate server, packets received at the intermediate server from the client for the network devices are sent from the virtual network interface to the virtual IP addresses associated with the devices and then read from the file interface, the source addresses of packets read from the file interface are replaced with the real IP address of the intermediate server and the destination addresses of said packets from the client are replaced with the actual local subnet addresses of the devices, the packets are encrypted and authenticated according to the secure IP settings negotiated for the gateways in order to provide encrypted packets, said encrypted packets are sent to the gateways associated with the devices.

2. Method according to claim 1, wherein encrypted payload packets received from the gateways are authenticated and decrypted by using the secure IP settings negotiated for the gateways, the source addresses of the incoming packets from the gate- ways are replaced with the associated virtual IP subnet addresses, and the destination addresses are replaced with the virtual network address, and the packets are written to the file interface of the virtual network interface, received at the virtual network interface and sent to the client.

3. Method according to claim 1 or 2, wherein each network device is associated with a unique connection identifier.

4. Method according to claim 3, wherein each network device is furthermore associated with at least one port number for communication connections.

5. Method according to any of the previous claims, wherein the checksums of the encrypted payload packets are recomputed after replacing the source addresses and the destination addresses.

6. Method according to any of the previous claims, wherein the secure IP settings between the intermediate server and the gateways are negotiated at application level by means of an IKE daemon bypassing the kernel of the intermediate server and accepting ambiguous routing information, which is managed at application level.

7. Method according to any of the previous claims, wherein the intermediate server monitors the data streams between the client and the devices in order to manage login credentials required by the devices, by modifying the login credentials comprised in said data streams.

8. Method according to claim 7, wherein the intermediate server manages the login credentials by answering a challenge comprised in said data streams in order to modify the data streams and to provide the devices with the required login credentials.

9. System for providing secure communication between a client and one or more network devices located on private networks placed behind different gateways, which private networks at least partly use the same local subnet addresses for said network devices, wherein a secure IP connection is established between said client and an intermediate server comprising information of accessible gateways and network devices and their corresponding local addresses, a virtual network interface comprising a readable and writable file interface and a plurality of virtual IP subnet addresses configured at said intermediate server, each of said network devices is associated with one of said plurality virtual IP subnet addresses, secure IP settings between the intermediate server and the gateways are negotiated and managed at application level on said intermediate server, packets received at the intermediate server from the client for the network devices are sent from the virtual network interface to the virtual IP addresses associated with the devices and then read from the file interface, the source addresses of packets read from the file interface are replaced with the real IP address of the intermediate server and the destination addresses of said packets from the client are replaced with the actual local subnet addresses of the devices, the packets are encrypted and authenticated according to the secure IP settings negotiated for the gateways in order to provide encrypted packets, said encrypted packets are sent to the gateways associated with the devices.

10. System according to claim 9, wherein encrypted payload packets received from the gateways are authenticated and decrypted by using the secure IP settings negotiated for the gateways, the source addresses of the incoming packets from the gate- ways are replaced with the associated virtual IP subnet addresses, and the destination addresses are replaced with the virtual network address, and the packets are written to the file interface of the virtual network interface, received at the virtual network interface and sent to the client.

11. System according to claim 9 or 10, wherein each network device is associated with a unique connection identifier.

12. System according to claim 11, wherein each network device is furthermore associated with at least one port number for communication connections.

13. System according to any of the previous claims, wherein the checksums of the encrypted payload packets are recomputed after replacing the source addresses and the destination addresses.

14. System according to any of the previous claims, wherein the secure IP settings between the intermediate server and the gateways are negotiated at application level by means of an IKE daemon bypassing the kernel of the intermediate server and accepting ambiguous routing information, which is managed at application level.

15. System according to any of the previous claims, wherein the intermediate server monitors the data streams between the client and the devices in order to manage login credentials required by the devices, by modifying the login credentials comprised in said data streams.

16. System according to claim 15, wherein the intermediate server manages the login credentials by answering a challenge comprised in said data streams in order to modify the data streams and to provide the devices with the required login credentials.

17. System according to any of the previous claims, which comprises a central server for managing the access of clients to the intermediate server.

18. System according to any of the previous claims, comprising a plurality of intermediate servers.