Secure remote access public communication environment

A method and system provide a user device with secure access to an enterprise application in an enterprise network through VPN. The enterprise application is accessed from a user device such that it sends and receives data packets through the VPN client. For this, a request to send packets, originating from the user application, is intercepted by a VPN agent associated with the user application. In turn, the VPN agent associates an address of a loop-back interface with the user application. Thereafter, packets sent by the user application, are re-directed to the VPN client through the loop-back interface. Similarly, packets received by the VPN client from the enterprise network are routed through the loop-back interface to the user application.

TECHNICAL FIELD

The invention generally relates to accessing a remote application in a secure network through a virtual private network (VPN) and particularly relates to data transfer by the remote application.

BACKGROUND OF THE INVENTION

A network is a system of hardware and software, put together for the purpose of communication and resource sharing. A network includes resources such as transmission hardware and devices to interconnect transmission media and to control transmissions, and software to decode and format data, as well as to detect and correct problems in transmission. There are several types of networks in use today. In some networks, such as local area networks (LAN) and wide area networks (WAN), the resources are physically connected to each other. In other networks, such as virtual private networks (VPN), some of the links between the resources are carried by virtual connections routed through a larger network.

A VPN typically uses a public communication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to an enterprise network. A VPN works by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols such as Layer Two Tunneling Protocol (L2TP), Secure Socket Layer (SSL) protocol, and Internet Protocol security (IPSec) protocol.

Traditional VPN systems required dedicated software, referred to as client software, to be installed and managed on user computing devices to establish modules in the computing device that enable connection to the VPN and the use of remote applications. As maintaining software on user computing devices became relatively costly and time consuming, clientless VPN systems were developed. These clientless VPN systems do not require a device to be pre-configured with the client software. Such clientless VPN systems, however, are limited by their applicability to static port remote applications alone. With a growing demand for dynamic port applications, such as Voice over Internet Protocol (VoIP) and Video Conferencing, it would be advantageous to implement a way of providing clientless VPN access that can support the dynamic port applications as well.

SUMMARY OF THE INVENTION

Methods and systems of providing a user device with secure access to an enterprise network through a VPN are described. The user device may include a VPN client and a user application. An agent in the user device can intercept a request to an operating system service for establishing a connection that originates from the user application and, a communication channel can be established between the agent and the VPN client application based upon the intercepted request. Thereafter, packets sent by the user application, may be re-directed to the VPN client through the loop-back interface. The VPN client can establish a VPN tunnel with the enterprise network and forward data packets to the enterprise network. Similarly, packets received by the VPN client from the enterprise network are routed to the remote application through the loop-back interface. In one embodiment of the invention, the user application and VPN client may be dynamically downloaded onto the user device. The VPN client can execute the user application on the user device and associate an agent with it.

DETAILED DESCRIPTION

The present invention provides a method and apparatus for providing remote access over a virtual private network (VPN). The method and apparatus enable users to access resources within an enterprise network, using a user computing device, connected through public network such as Internet, even without having administrative privileges for the user computing device.

FIG. 1shows an example user device102that communicates with an enterprise network104via a public network106. The user device102may include various types of computing devices, such as a laptop, a personal digital assistant (PDA), and a personal computer. The user device102may include a publicly accessible device, such as a device in an Internet booth, a kiosk, and the like.

The enterprise network104and the public network106may be wireless or wired networks or a combination of the two. The enterprise network104includes network elements such as routers or switches connected together to enable data to be transmitted within the enterprise network104. The enterprise network104may have many components, such as e-mail servers, hosts, resources, and other common network elements which are not shown in this example. The invention is not limited to use with an enterprise network configured in any particular manner and, accordingly, details of the internal structure of the enterprise network104have been omitted to avoid obfuscation of the invention.

In a preferred embodiment, the enterprise network104includes an enterprise application108and a VPN gateway110. VPN gateways are well known and the invention is not limited to a particular embodiment in which particular types of external resources are used. The VPN gateway110enables a user to use the user device102to obtain remote access to the enterprise network104across the public network106in a secure way, for example by creation of a VPN tunnel between the user device102and the enterprise network104. The enterprise application108may be included on a single server or a variety of servers, which may be a server farm or part of a server farm. Various types of servers are well known and the invention is not limited to a particular embodiment in which particular types of servers are used.

Traditionally, when a user wanted to obtain remote access to an enterprise network, the remote user would need to install a VPN client on a user computer that was to be used to access the enterprise network. The installed VPN client would enable the remote computer to connect to the enterprise network through a VPN tunnel. VPN clients available today need kernel level components to be installed in the device which requires higher-level user privilege (e.g., administrative user privilege). Since the VPN client was specifically installed on a particular computer, if the user wanted to obtain access from a different computer, the user would need to install the VPN client on that computer. For example, if a user wanted to log into the enterprise network104from home, the user would need to install the VPN client on their home computer, and then use the VPN client to access the enterprise network104. If the user was traveling without a computer in which the VPN client had been installed, VPN access was often not feasible since administrative user privilege of the publicly available device would not generally be granted.

To overcome these limitations, according to an embodiment of the invention, VPN tunnels may be established using dynamically downloadable VPN clients, such as a VPN client112shown inFIG. 1. The VPN client112may be downloaded from, for example, a web portal, or an external memory device such as a USB drive. In a preferred embodiment, the user is authenticated by the web portal or the memory device before the VPN client112is downloaded onto the user device102.

By causing the VPN client to be dynamically downloaded during a session, the user device102does not need to be pre-loaded with a VPN client. Thus, any computer with an Internet browser may be used to log into the enterprise network104. The dynamically downloaded components may be deleted upon termination of the session so that the availability of the components of the VPN client112may be terminated once the session has ended. Accordingly, a user will be able to access a corporate network even from a publicly available computer.

In one embodiment, the VPN client112may be downloaded along with user application114that is to be remotely executed through a web interface. In operation, the user, on authentication, can be provided with a list of applications that can be made available to the user. On selection of a user application, both the user application114and the VPN client112can be dynamically downloaded onto the user device102. The VPN client112may execute the user application114and associate a VPN agent116with the user application114in order to intercept requests for establishing a connection, such as a socket calls, originating from the user application114.

Further, the VPN agent116can establish a communication channel with the VPN client112to redirect packets, such as data packets, originating from the remote application114. The VPN client112also establishes a logical tunnel or VPN tunnel with the VPN gateway110to encrypt and forward the packets. The various aspects of embodiments of the user device102will be explained in detail with reference toFIGS. 2-4.

FIG. 2represents an example of a user device102. For ease of explanation, the embodiment shown inFIG. 2is shown in the state where the VPN client112has been dynamically downloaded so that the user device102is ready to communicate using a tunnel on the public network106. As discussed above, once the session is completed, some or all of the VPN components may be removed from the computer to return the user device102to a normal configuration.

In a preferred embodiment, the user device102includes a central processing unit (CPU)202, a memory204and network interfaces206. The CPU202implements control logic for processing modules stored in the memory204. The memory204can include volatile and non-volatile memory. The user device102interacts with the public network106and the enterprise network104via the network interfaces206. The network interfaces206include, for example, a physical adapter containing ports configured to connect to physical links on the public network106and to VPN networks established through the VPN client112.

In operation, as discussed, the VPN client112and the user application114may be downloaded dynamically on to the user device102. The VPN client112can then associate the VPN agent116with the user application114. For this, the VPN client112executes the user application114and associates the VPN agent116with the user application114such that the VPN agent116can intercept a request to an operating system service for establishing a connection, such as socket calls, generated by the user application114. Socket calls may include calls related to socket creation, obtaining destination socket address, and the like. In one implementation, the socket calls may be calls that interact with application program interfaces (API), such as the WinSock API that is available in the Windows Operating System, provided by Microsoft Corporation.

Further, the VPN agent116can establish a communication channel with the VPN client112. This can be accomplished by changing the destination address in the request intercepted by the VPN agent to a loop-back-interface address. The loop-back interface is a virtual network interface that may be integrated with an operating system and used to route data back to a source entity without intentional processing or modification. The most commonly used IP address for a loop-back is 127.0.0.1 for IPv4, although any address in the range 127.0.0.0 to 127.255.255.255 is mapped to it. A loopback interface may be used by network client on a computer to communicate with an application on the same computer. The loop-back interface208can be configured to forward packets to either the VPN client112or the user application114.

In addition, the VPN client112establishes a logical tunnel or VPN tunnel with the VPN gateway110and receives tunnel IP addresses. In one embodiment, the tunnel IP addresses correspond to IP addresses of a proxy at the VPN gateway110and of the enterprise application108.

In operation, when the user application114is to send packets to the enterprise application108, the packets are redirected to the VPN client112via the loop-back interface208. The VPN client then suitably encrypts and sends the packets via the VPN tunnel to the VPN gateway110. Similarly, packets received by the VPN client112from the VPN gateway110are sent to the user application114via the loop-back interface208.

FIG. 3illustrates an exemplary VPN client112in the user device102in accordance with one embodiment of the invention. The user device102is assigned an IP address, which is the IP address of a physical interface302in the network interfaces206. The physical interface302may be a network adapter, such as a network card, that interfaces the user device102with any network. The physical interface302can be either a wired or a wireless network adapter supported by the operating system of the user device102through a variety of modules such as device drivers.

As discussed, upon successful authentication, the user is provided access to a number of pre-configured user applications, which can be located at diverse locations. In one embodiment, the pre-configured remote applications can be located on a USB device. The user can select a desired application, such as the user application114, from amongst the list of pre-configured user applications.

The selected user application114is then downloaded on the user device102along with the VPN client112and is executed by the VPN client112. In case the VPN client112is already executing on the user device102, for example because of a different user application having been selected earlier, the VPN client112may not be re-downloaded. The VPN client112also initiates a VPN agent116that is associated with the user application114. The initiation of the VPN agent may include the associating of a Hook Dynamic-link Library (DLL) file to the user application114.

On execution, the user application114can invoke system calls to establish a communication path through the physical interface302. In one implementation, in the case of Windows operating system, the executing user application114invokes WinSock API calls. These system or API calls are generated by the user application114for creation of sockets at the physical interface302and for acquiring a destination internet protocol (IP) address to establish the communication path. The VPN client112hooks the API calls generated by the user application114to associate the VPN agent116with the remote application114.

Hooking is a programming technique that functions as an event handler by intercepting library functions calls or API calls made by an application. Generally, a hook system includes two parts: a hook server and a hook driver such as Winsock.dll. The hook server injects the hook driver into the address space of the application for intercepting the API calls. Also, the hook server controls and communicates with the hook driver. The hook driver performs the actual interception of the API calls, invoked by the application.

The VPN client112, behaving as a hook server, performs hooking by creating a VPN agent116and associating the VPN agent116with the remote application114. The VPN agent116includes API intercepting logic, or in other words a set of instructions for intercepting API calls generated by the remote application114. The VPN agent116can monitor socket API calls issued by the remote application114and can communicate socket events to the VPN client112. Thus, each time a new user application114is executed on the user device102, the VPN client112creates a new VPN agent116and associates the new VPN agent116with the new remote application114. Accordingly, the WinSock API calls, generated by the new remote application114, are intercepted by the new VPN agent116and communicated to the VPN client112.

In addition, as discussed, the VPN agent116establishes a communication channel with the VPN client112via the loop-back interface208, and the VPN client112establishes a VPN network connection, such as an SSL tunnel, with the VPN gateway110. A loop-back interface is a virtual interface that enables the user application114to send or receive data packets from the VPN client112through an IP address of the virtual interface, rather than through the IP address of the physical interface302. The SSL tunnel is established by receiving IP addresses of the tunnel from the VPN gateway. The SSL tunnel may be established only once by the VPN client112, when the first user application114is executed. Subsequently, each time a new user application114is executed, an additional SSL session may be established for the new user application114in the previously created SSL tunnel.

The loop-back interface208can be configured to forward packets to the VPN client112during egress flow, for sending packets from the user application114to the enterprise application108. With reference toFIG. 3, the path followed by the packets during egress flow is depicted by IE,2E and3E.

In one implementation, the VPN agent116changes the destination address of the packets generated by the user application114to the IP address of the loop-back interface208, while the source address of the packets remains that of the physical interface302. As a result, the packets are routed to the loop-back interface208from the physical interface302. The loop-back interface208can be configured to send the packets received from the physical interface302to the VPN client112. The VPN client112listens at a socket corresponding to the loop-back interface208to receive the packets.

At the VPN client112, the source IP address of the packets is modified to a proxy source IP address provided by the VPN gateway110. The modified source IP address of the packets behaves as an IP address of one end of the SSL tunnel. Also, the destination IP address of the packets is modified to a virtual destination IP address provided by the VPN gateway110. The modified destination IP address of the packets corresponds to the IP address of the enterprise application108in the enterprise network104, and behaves as an IP address of the other end of the SSL tunnel.

The packets with modified source and destination IP addresses, hereinafter referred to as modified packets, are then encapsulated and encrypted using the SSL protocol by the VPN client112for transmission to the enterprise application108through the SSL tunnel. The encapsulated SSL packets are provided with the IP address of the physical interface302as the source IP address and the physical IP address of the VPN gateway110as the destination IP address for transmission. Thus, the packets are transmitted to the VPN gateway110from the physical interface302. After receiving the packets from the user device102, the VPN gateway110can unwrap the packets and forward the packets to the enterprise application108.

Similarly, during ingress flow, packets can be received by the user application114from the enterprise application108through the VPN client112and loop-back interface208. With reference toFIG. 3, the path followed by the packets during ingress flow is depicted by1I,2I and3I.

In an implementation, during ingress flow, the loop-back interface208receives the packets from the VPN client112and routes the packets to the user application114. The user application114, while waiting for a connection request from the enterprise application108, invokes a listening event for which, the user application114invokes API calls, such as WinSock API calls, to communicate the state of the user application114to the enterprise application108. The API calls are intercepted by the VPN agent116, which communicates the socket listening information to the VPN client112. The VPN client112initiates connection requests to the user application through the loop-back interface208when it receives connection requests from enterprise applications108through the tunnel.

In return, the enterprise application108sends response packets to the VPN gateway110. The VPN gateway110encrypts the response packets and adds a header to the response packets for sending the response packets through the SSL tunnel. The header added by the VPN gateway110contains the tunnel IP address of the user device102as the destination address. The VPN client112receives these response packets.

On receiving the response packets, the VPN client112unwraps the response packets and forwards the unwrapped response packets (URPs) to the user application114through the loop-back interface208. For this, the loop-back interface208can be configured to forward packets received from the VPN client112to a socket address on the physical interface302that corresponds to the user application114. The physical interface302sends the packets to the user application114as depicted by ingress flow3I.

As discussed, during both egress flow and ingress flow of data packets, the VPN agent116communicates socket listening information regarding the loop-back interface208and the physical interface302to the VPN client112dynamically. Thus the VPN client112does not have to be pre-configured to listen at a few static ports. As a result, the system can support applications that use dynamic ports, such as VoIP, Video Conferencing, and the like.

FIG. 4illustrates modules in an example VPN client112. In one embodiment, the VPN client112includes a control module402, a data handling module404, a socket entry mapping module406, a Transmission Control Protocol/Internet Protocol stack (TCP/IP)408, and a tunnel handling module410.

Upon successful authentication of a user, links to pre-configured user applications are displayed to the user. The user may select multiple user applications from the links displayed on the user device102. For the first user application, such as the user application114, selected by the user, the user application is downloaded to the user device102along with the VPN client112. Thereafter, the user applications alone are downloaded individually in response to selection by the user.

The VPN client112executes the downloaded user applications using the control module402. The control module402can associate a separate VPN agent116with every remote application114selected by the user. As discussed, the VPN agent116intercepts the WinSock API calls invoked by the associated remote application114at the time of execution. The control module402can also establish a communication channel between every VPN agent116and the VPN client112. The communication channel may be established for communicating socket events such as socket creation, deletion and modification. Each VPN agent116in turn creates a loop-back interface208for re-directing packets from the associated user application114to the VPN client112. Further, the control module402may establish a tunnel between the user device102and the VPN gateway110for secure transmission of data. Data in the form of data packets is transferred between the user application114in the user device102and the VPN gateway110through the loop-back interface208and the VPN client112.

The VPN client112uses the data handling module404to receive and/or send the data packets from or to the loop-back interface208. The data handling module404may use a mapping between real sockets, such as the sockets created with the operating system, and tunnel sockets, such as the sockets created in the VPN tunnel, for transmission of the data packets.

The socket entry mapping module406may contain the entries having information regarding the real sockets and the tunnel sockets such as IP addresses of the sockets. These entries allow the data handling module404to identify the appropriate loop-back interface through which the data packets have to be routed.

The TCP/IP stack408handles protocol related with various functions such as header preparation and modification, and timing for sending and/or receiving data packets. Further, the TCP/IP stack408provides an interface for the data handling module404.

The encapsulation, unwrapping, and transfer and receipt of encapsulated data packets are handled through the tunnel handling module410. For example, the tunnel handling module410may encrypt and encapsulate the data packets with their SSL headers so that they may be forwarded to the VPN gateway110. The tunnel handling module410may also unwrap the data packets and forward it to the data handling module404for transmission to the user application114.

Thus, the control module402, the data handling module404, the socket mapping entry406, the TCP/IP stack408, and the tunnel handling module410work together to redirect data packets through the tunnel.

FIG. 5is a flow chart illustrating an exemplary method500for implementing a VPN client112, whileFIG. 6is a flow chart depicting a method600for communicating packets from a user application114to the VPN client112. These exemplary methods may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, and the like, that perform particular functions or implement particular abstract data types. The computer executable instructions can be stored on a computer readable medium and can be loaded or embedded in an appropriate device for execution.

Method500is initiated at block502, where a VPN portal link, such as a web portal of an enterprise network that can be accessed through a web browser, is accessed by a user. In another example, the VPN client112can be accessed from a web portal of an enterprise network104through a web browser.

At block504, the user is authenticated on the VPN gateway110. For providing a secure and restricted access to an enterprise application108, the user can be authenticated on the VPN gateway110by using a variety of techniques. For example, the user can be authenticated on the VPN gateway110with the help of a dedicated username and password. The authentication of the user also facilitates the VPN gateway110to identify the enterprise applications which the user is authorized to access.

At block506, the user selects a user application link for the user application114that is desired to be executed. Upon successful authentication of the user on the VPN gateway110, the desired user application114can be selected from multiple of user applications for which the user has authorized access.

At block508, the VPN client112and the user application114selected via the link are downloaded and executed. The selected user application114is executed by the VPN client112for performing the requisite function. In an alternate implementation of steps504to508, the VPN client112, as well as the user application114, may be located in an intermediate device. For example, they can be located in a universal serial bus (USB) device. Additionally, such a device may include additional indicia for the authentication of the uses in step504.

At block510, a VPN agent116is attached with the user application114. For example, the VPN client112can initiate the hooking of socket API calls generated by the user application114to associate the VPN agent116with it. The VPN agent116is a module that includes an API intercepting logic. In other words, the VPN agent116is adapted to intercept API calls such as WinSock API calls in a Windows platform.

At block512, a communication channel is established between the user application114and the VPN client112. In an implementation, the VPN agent116, attached with the user applications114, facilitates establishing a communication channel between the user applications114and the VPN client112through the loop-back interface208by using a variety of techniques. For example, the VPN agent116can employ the functionality of creating sockets, through Winsock API calls, provided with the Windows operating system for setting up the communication channel.

At block514, a logical tunnel is established between the VPN client112and a VPN gateway110. The VPN client112establishes the logical tunnel to the VPN gateway110to provide a communication channel between the VPN client112and an enterprise application108in the enterprise network104by using a variety of known techniques.

At block516, IP addresses of the tunnel are received for communication with the enterprise application108. In order to facilitate communication between the user device102and the enterprise network104, IP addresses of the tunnel are received by the VPN client112from the VPN gateway110.

FIG. 6illustrates a method600of communicating packets from the user application114to the VPN client112, where the user application114requests establishment of a connection with an enterprise application108.

At block602, the VPN agent116associated with the user application114intercepts a request from the user application114to establish a connection with an enterprise application108. Typically, in order to send or receive packets, the user application114needs to connect with the physical adapter or interface302. The user application114needs to create a socket in the physical interface302prior to sending the packets. The user application114generally interacts with the physical interface302by raising a socket call. For example, in the Windows platform environment, the user application114generates Winsock API calls to request the physical interface302to create the socket for transmitting data traffic. Further, the call includes a request to the physical interface302to ascertain the IP address of the destination to which packets are to be sent. This request to obtain the destination address, originating from the user application114, is intercepted by the VPN agent116at block602of method600.

At block604, in response to the request for destination address, the VPN agent116creates a loop-back interface208. This can be accomplished by changing the destination IP address in the request to establish a connection to a loop-back interface address. The loop-back interface208can then serve as an intermediate module that may temporarily hold packets and redirect them to a predetermined location or application within the user device102. In block606, the VPN agent sends a request to the VPN client to listen in for packets addressed to the loop-back interface208.

In block608, the packets originating from the user application114are assigned the address of the loop-back interface208as the destination address. Thus the packets are now re-directed to the loop-back interface208.

In block610, the VPN client receives packets originally destined to the enterprise application108and, upon arrival of the packets at the loop-back interface208, the packets are forwarded to the VPN client112.

FIG. 7illustrates a method700of communicating packets from the VPN client112to the user application114, where the enterprise application118requests establishment of a connection with the user application114.

At block702, the VPN agent116associated with the user application114intercepts a request from the user application114to enable listening for other applications to connect. This request may include a Winsock API call to the physical interface302.

At block704, the VPN agent requests the VPN client to forward requests that it receives from the enterprise application108to the user application114via the loop-back interface208.

At block706, the enterprise application108sends a connection request through a tunnel established between the VPN client112and the VPN Gateway110.

At block708, the VPN client112initiates a connection with the user application114through the loop-back interface208.