US20140366120A1 - Systems and Methods for Application-Specific Access to Virtual Private Networks - Google Patents
Systems and Methods for Application-Specific Access to Virtual Private Networks Download PDFInfo
- Publication number
- US20140366120A1 US20140366120A1 US14/231,209 US201414231209A US2014366120A1 US 20140366120 A1 US20140366120 A1 US 20140366120A1 US 201414231209 A US201414231209 A US 201414231209A US 2014366120 A1 US2014366120 A1 US 2014366120A1
- Authority
- US
- United States
- Prior art keywords
- application
- network
- data
- private network
- header
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
Definitions
- VPNs provide users with a secure and restrictive private network within a public telecommunication infrastructure, such as the Internet.
- a VPN may allow for a host computer to send and receive data across shared and/or public networks, as if the host computer is an integral part of the private network with all the functionality, security and management policies of the private network.
- VPN connection across the Internet is technically a wide area network (“WAN”) link between the sites. More specifically, a VPN may be established using virtual point-to-point connections via dedicated connections, encryption, or any combination thereof. From a user perspective, the extended network resources are accessed in the same way as resources available from the private network. To prevent disclosure of private information, VPNs typically allow only authenticated remote access and make use of encryption techniques. For instance, VPNs operate by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols. Accordingly, by encrypting data at the sending end and decrypting it at the receiving end, these tunneling protocols send the data through a “tunnel” that cannot be “entered” by data that is not properly encrypted. An additional level of security may encrypt not only the data, but the originating and receiving network addresses, as well.
- FIG. 1 shows an exemplary system utilizing application-specific access to a virtual private network (“VPN”).
- VPN virtual private network
- FIG. 2 shows an exemplary data packet structure for application-specific access to a VPN in comparison to a data packet structure for routing table access to a VPN.
- FIG. 3 shows an exemplary method utilizing application-specific access to a VPN.
- a method may comprise receiving a request for a network data flow to a private network from an application executing on a device, comparing identification information associated with the application against a set of rules stored on a memory of the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network, and establishing a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network
- a system comprising a memory storing a plurality of rules and a processor receiving a request for a network data flow to a private network from an application executing on a device, comparing identification information associated with the application against a set of rules stored on the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network, and establishing a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network.
- Non-transitory computer readable storage medium with an executable program stored thereon, wherein the program instructs a processor to perform the following steps: receive, from an application executing on a device, a request for a network data flow to a private network; compare identification information associated with the application against a set of rules stored on the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network; and establish a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network
- the exemplary embodiments may be further understood with reference to the following description and the appended drawings, wherein like elements are referred to with the same reference numerals.
- the exemplary embodiments show systems and methods utilizing application-specific access to a VPN.
- the exemplary embodiments described herein may allow for a VPN to establish a set of rules on the device at the application level.
- tunneling uses a tunneling protocol where one network protocol (e.g., the delivery protocol) encapsulates a different payload protocol.
- one network protocol e.g., the delivery protocol
- tunneling typically contrasts with a layered protocol model such as those of Open Systems Interconnection (“OSI”) or Transmission Control Protocol/Internet Protocol (“TCP/IP”).
- OSI Open Systems Interconnection
- TCP/IP Transmission Control Protocol/Internet Protocol
- the delivery protocol may operate at a higher level in the model than does the payload protocol, or at the same level.
- the conventional approach for tunneling IP packets using an IP-layer approach wherein an IP routing table is used to decide which packets are to be tunneled.
- an application writes data to a socket, the TCP/IP stack packetizes the data into IP packets, and the IP packets are routed to the tunnel.
- there is no application intelligence built into the process In other words, all applications have access to the same IP routing table. Any application is potentially routable through an IP-layer VPN, and is only limited based on the IP address the application attempts to access.
- the access limitation is on a device (e.g., the VPN access is limited to the certain devices that are registered as users of the VPN).
- Company X may maintain a VPN to be used by its employees.
- Company X may issue computing devices (e.g., desktops, laptops, tablets, notebooks, smart phones, etc.) to the employees. These devices may be registered devices with the VPN, allowing the employees to access the VPN of Company X.
- computing devices e.g., desktops, laptops, tablets, notebooks, smart phones, etc.
- These devices may be registered devices with the VPN, allowing the employees to access the VPN of Company X.
- BYOD bring-your-own-device
- the BYOD model does not work due to the user's personal device not being a registered device with the VPN of Company X.
- the exemplary embodiments described herein may be advantageous to such BYOD private network enterprises. This is due to the fact that the enterprise may easily control which applications may access the VPN, as opposed to controlling every device attempting access. Furthermore, the application-specific access systems and methods enable the enterprise to perform traffic inspection, as the actual application data stream is readily accessible for examination. Conventional inspection would otherwise require the enterprise to perform traditional packet inspection.
- While one exemplary embodiment describes an application-specific VPN wherein specific applications are authorized to use a VPN tunnel, additional embodiments may feature any number of procedures, or a combination of procedures, for permitting access to a VPN.
- a further embodiment may be an application-layer VPN wherein streams of application data are tunneled to the VPN.
- the exemplary application rules described herein are not restricted in implementation to the authorization of Application-layer VPN. In other words, the exemplary application rules described herein may also be implemented to authorize specific applications to use an IP-layer VPN.
- the exemplary embodiments may provide application-specific access to a VPN. Accordingly, when an application creates a network object, the library may match the application against a set of rules that dictate which applications are allowed to use the VPN tunnel. If the application matches one of these rules, the flow of network data may then be diverted through the VPN tunnel, as opposed to entering the TCP/IP stack.
- This application-specific VPN access is not limited to a specific device and allows an authorized VPN user to access the VPN using any device. It is noted that the VPN tunnel may be established after authenticating the user. Once established, access to the tunnel may then be restricted to applications that match the rules.
- the exemplary systems and methods described herein provide control over which applications have access to the private network.
- the enforcement of this access may be achieved through application VPN rules.
- these systems and methods may eliminate data leakage from the applications that match the rules. Accordingly, applications that do not match the rules may be prevented from sending data through the VPN tunnel.
- an exemplary embodiment may be application-based access to a private network
- additional embodiments are not limited to such schemes.
- an account-based matching system for accessing a private network may also be used.
- the account may include mail, contacts, and/or calendar accounts of a user's device.
- An exemplary account-based access system will be described in greater detail below.
- the set of rules within the embodiments may be generated by an administrator at an entity controlling the VPN.
- FIG. 1 shows an exemplary system 100 for application specific access to a VPN 110 for a device 105 executing any number of applications.
- the exemplary system 100 may include an electronic device 105 having a processor 120 and a memory 130 , such as a non-transitory computer-readable storage medium.
- the device 105 may be a device such as, for example, a desktop, laptop, tablet, notebook, smart phone, etc.
- the system 100 may allow for an application 140 to access a VPN server 115 within the VPN 110 based on a set of rules 135 stored within the memory 130 , wherein the rules 135 dictate which specific applications have access to the VPN 110 .
- application 140 of the device 105 may be linked to a network library 145 .
- the processor 120 may utilize the library 145 to match the application 140 to the set of rules 135 . If the application 140 matches one of the stored rules 135 , the processor 120 may divert the flow of network data through a VPN tunnel 125 , as opposed to entering the TCP/IP stack. In other words, each packet of the application data may traverse a network stack (e.g., TCP/IP stack) only a single time before being communicated to the VPN 110 .
- a network stack e.g., TCP/IP stack
- the network flow data may be diverted from a socket layer to a VPN agent 150 process running in user space.
- the VPN agent 150 process may pass the network data to a third-party plugin 160 that tunnels the data over a tunnel connection to the VPN 110 .
- the exemplary system 100 includes the third-party plugin 160 for tunneling data to the VPN 110
- alternative embodiments may include first-party and/or integrated data transportation components for tunneling network flow data to the VPN 110 .
- the network data may not traverse the TCP/IP stack before being diverting to the VPN agent 150 , the data would not be packetized and the third-party plugin 160 operating in the VPN agent 150 may have access to the stream of network data in the same, or similar, format as written by the application 140 .
- the processor 120 may write the data back to a receive buffer of a socket. Accordingly, the application 140 may then be notified by the processor 120 that the data is available and may read the data from the socket.
- the network data may only have to traverse the TCP/IP stack once. For example, the network data may arrive at the TCP/IP stack after being processed by the third party plugin 160 , so the packets may be routed over the Internet.
- the set of rules 135 may include any number of authentication procedures for permitting the application 140 to access to the VPN 110 .
- the rules 135 may optionally utilize a signing identifier that uniquely identifies the application 140 , a designated requirement that identifies the party who signed the application 140 , a list of allowed domains, or any other rules that uniquely identify an application and/or an account. Accordingly, the signing identifier and the designated requirement of the application 140 may be matched against the signature of a calling application.
- a host name of a host within the private network that the application 140 is trying to access may be suffix-matched against the list of domains. If the host matches any one of the names, or if there are no domains in the rules 135 , then the application 140 satisfies the rules 135 .
- the set of rules 135 may include account-based access procedures for authorizing the application 140 to access the VPN 110 .
- the application 140 may be modified to “tag” the network data flow with a string identifying the account for which network access is being established.
- Exemplary accounts may include mail accounts, contact lists, calendar accounts, etc.
- the string identifying the account may then be matched against a list of account identifiers in the rules 135 .
- a “wildcard” account may also be used, wherein every account identifier matches the wildcard account. Accordingly, if there is a match with one of the account identifiers, or if there is a wildcard account, then the account satisfies the rules 135 .
- the device 105 may also include one or more network interfaces.
- a network interface may implement, among other functionality, the lower layers (i.e., the physical and data link layers, and/or portions thereof) in the network stack in the device 105 .
- a network interface may be or include components such as a transceiver, a processor and/or specific-purpose DSP circuitry, and/or analog signal processing circuitry for implementing wired/wireless communications.
- the device 105 may include one or more network interfaces that communicate using technologies such as but not limited to: Ethernet; WiFi (IEEE 802.11a/b/g/n/ac and/or other IEEE 802.11 technologies); cellular technologies (including but not limited to LTE, LTE-A, UMTS, CDMA2000, and/or GSM-EDGE); and/or other wired and/or wireless communications technologies.
- the device 105 may also include an antenna (also not shown in FIG. 1 ) coupled to the wireless network interface.
- this communication of data may be performed using one or more of the network interfaces.
- FIG. 2 shows an exemplary data packet structure 220 for application-specific access to a VPN in comparison to a conventional data packet structure 210 for routing table access to a VPN.
- the structure 210 includes an IP header 211 having a source IP address and a destination IP address, a User Datagram Protocol (“UDP”) header 212 have a source port and a destination port, a further IP header 213 , a TCP header 214 having a source port and a destination port, and the payload of application data 215 .
- UDP User Datagram Protocol
- TCP Transmission Control Protocol
- the exemplary structure 220 includes an IP header 221 , a TCP header 222 , a transport layer security (“TLS”) header 223 , and the payload of application data 224 .
- TLS transport layer security
- the flow of this exemplary network data may be diverted through the VPN tunnel, as opposed to entering the TCP/IP stack. Accordingly, the exemplary structure 220 may not require the UDP header and IP header of transport layer segments.
- the exemplary structure 220 of the application-specific access to the VPN allows for improved traffic inspection within the network. Specifically, the traffic may be easier to monitor since data is not wrapped in the IP/UDP layer. As opposed to traditional packet inspection of the conventional data packet structure 210 , the exemplary systems and methods described herein allow, in some instances, for the inspection of the actual application data stream. It is noted that any filtering software running within the VPN agent 150 process or the VPN server 115 may receive the application data wrapped in the IP and TCP headers, while not including the IP UDP headers. The IP and UDP headers will have been stripped off by the TCP/IP stack before the packet is delivered to the filtering system.
- the filtering system will receive from the TCP/IP stack, the filter would receive the IP header 213 , the TCP header 214 , and the applications data 215 for the conventional data packet structure 210 .
- the filter would receive the applications data 224 .
- FIG. 3 shows an exemplary method 300 utilizing application-specific access to the VPN 110 .
- the method 300 is a overview of the network data flow including the application 140 starting up, setting up the VPN tunnel 125 , and communicating data between the application 140 and the VPN server 115 of the VPN 110 .
- the step performed by the method 300 will be described in reference to the exemplary system 100 and its components described above with reference to FIG. 1 .
- each of the steps of method 300 may be performed by an AppTunnel framework, including the VPN agent 150 and the processor 120 , which may be a physical hardware processing component of the system 100 .
- the processor 120 may receive a query from the application 140 to connect with a destination host over the VPN 110 via the VPN tunnel 115 .
- this query may be a domain name system (“DNS”) query to access a specific identification string (e.g., HTTP request) on the network.
- DNS domain name system
- the processor 120 may create a network object, such as a TCP connection object, from the application 140 .
- the network object may be used to establish a new network data flow between the application 140 and the exemplary VPN 110 .
- the processor 120 may match the network object against the set of rules 135 stored in the memory 130 of the system 100 . For instance, the processor 120 may obtain a process identifier (“PID/ID”) of the application 140 as well as a destination host for the application 140 . Accordingly, the processor 120 may perform a look-up for the PID/IP of the application 140 and the destination host within the rules 135 .
- PID/ID process identifier
- the processor 120 may determine whether the application 140 satisfies the rules 135 . If the tunneling rules 135 dictate that the network data flow may be tunneled to the VPN 110 , then the method 300 may advance to step 350 . However, if the application 140 fails to satisfy the rules 135 , the application 140 may be denied access to the VPN 110 in step 345 .
- step 350 the processor 120 may determine whether the application 140 specifies a destination host by name. If the application 140 specifies the destination, then the method 300 may advance to step 360 . However, if the application 140 does not name a host destination, the application 140 may bypass the DNS resolution, and the method may advance to step 370 .
- step 360 the processor 120 sends the host name to the third party plugin 160 of the VPN agent 150 for resolution and, the third party plugin 160 may resolve the host name and send the results to the processor 120 .
- host name resolution allows for successfully mapping the host name to an IP address, wherein the host name is an alias assigned to an IP node to identify it as a TCP/IP host.
- the processor 120 may open a flow divert socket of a kernel to the VPN server 115 .
- the processor 120 may open the socket to the destination host and the TCP connection object may set a socket option indicating that network flow data should be tunneled to the VPN server 115 .
- the processor 120 may alternatively, set a rule in the socket filter indicating that a particular PID/ID and host combination should be allowed to tunnel via the VPN server 110 .
- the processor 120 may establish a network data flow with the VPN server 115 .
- the socket filter in the kernel may send the data to the third party plugin 160 for tunneling.
- the processor 120 may communicate data between the VPN 110 and the application 140 via the VPN tunnel 125 .
- the third party plugin 160 may send the data to the socket filter of the kernel.
- the socket filter may place the data in the receive buffer of the socket, and the application 140 may then read the data from the socket.
- signing identifiers are only examples of any number of rules that may be used to uniquely identify the application and/or other characteristics for VPN access. Accordingly, alternative rules for identifying applications may be performed during the method 300 .
- the above-described exemplary embodiments provide application-specific access to a private network that does not require the use of the TCP/IP layer. Specifically, network data originating from certain applications may be routed through the VPN tunnel, while all other traffic may be routed outside the VPN. It is noted that application-specific routing may, in some instances allow for sockets of a kernel to be mapped to application identifiers of the application that opened it.
- a lookup may be performed on the application identifiers based on a set of rules for VPN access. If the lookup satisfies the rules, a network interface may be obtained and a routing socket option is set on the socket. Accordingly, all traffic generated by the socket may be routed to the specified network interface.
- the above-described exemplary embodiments may be implemented in any number of enforcement procedures to ensure that only the applications that satisfy the set of rules may be allowed to use the exemplary VPN. For instance, in a “whitelist” procedure, wherein specific applications may be routed to the VPN 110 , enforcement may be achieved by not installing any routes to the VPN tunnel 125 in the rules 135 . Access to the VPN 110 may then be limited to a set of applications in the whitelist. Alternatively, in a “blacklist” procedure, wherein specific applications may not be routed to the VPN 110 , enforcement may ensure that sockets used by these applications are not routed through the VPN tunnel 125 . In other words, these blacklist applications may not be scoped to the VPN interface even if explicitly scoped via a socket option.
- a further enforcement embodiment may be to enhance the filtering of traffic (e.g., PacketFilter) to support rules based on application identifiers.
- this embodiment may also serve as a replacement implementation for application firewalling.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Described herein are systems and methods utilizing application-specific access to a virtual private network (“VPN”). A method may comprise receiving, from an application executing on a device, a request for a network data flow to a private network, comparing identification information associated with the application against a set of rules stored on a memory of the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network, and establishing a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network.
Description
- Virtual private networks (“VPNs”) provide users with a secure and restrictive private network within a public telecommunication infrastructure, such as the Internet. A VPN may allow for a host computer to send and receive data across shared and/or public networks, as if the host computer is an integral part of the private network with all the functionality, security and management policies of the private network.
- The VPN connection across the Internet is technically a wide area network (“WAN”) link between the sites. More specifically, a VPN may be established using virtual point-to-point connections via dedicated connections, encryption, or any combination thereof. From a user perspective, the extended network resources are accessed in the same way as resources available from the private network. To prevent disclosure of private information, VPNs typically allow only authenticated remote access and make use of encryption techniques. For instance, VPNs operate by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols. Accordingly, by encrypting data at the sending end and decrypting it at the receiving end, these tunneling protocols send the data through a “tunnel” that cannot be “entered” by data that is not properly encrypted. An additional level of security may encrypt not only the data, but the originating and receiving network addresses, as well.
-
FIG. 1 shows an exemplary system utilizing application-specific access to a virtual private network (“VPN”). -
FIG. 2 shows an exemplary data packet structure for application-specific access to a VPN in comparison to a data packet structure for routing table access to a VPN. -
FIG. 3 shows an exemplary method utilizing application-specific access to a VPN. - Described herein are systems and methods utilizing application-specific access to a virtual private network (“VPN”). A method may comprise receiving a request for a network data flow to a private network from an application executing on a device, comparing identification information associated with the application against a set of rules stored on a memory of the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network, and establishing a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network
- Further described herein is a system comprising a memory storing a plurality of rules and a processor receiving a request for a network data flow to a private network from an application executing on a device, comparing identification information associated with the application against a set of rules stored on the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network, and establishing a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network.
- Further described herein is a non-transitory computer readable storage medium with an executable program stored thereon, wherein the program instructs a processor to perform the following steps: receive, from an application executing on a device, a request for a network data flow to a private network; compare identification information associated with the application against a set of rules stored on the device, wherein the set of rules identifies conditions for the application to be authorized to access the private network; and establish a connection for the network data flow upon the identification information satisfying the conditions for the application to access the private network
- The exemplary embodiments may be further understood with reference to the following description and the appended drawings, wherein like elements are referred to with the same reference numerals. The exemplary embodiments show systems and methods utilizing application-specific access to a VPN. In other words, as opposed to the past approaches, the exemplary embodiments described herein may allow for a VPN to establish a set of rules on the device at the application level.
- Conventional VPNs use a tunneling protocol where one network protocol (e.g., the delivery protocol) encapsulates a different payload protocol. For instance, by using tunneling a system can carry a payload over an incompatible delivery network, or provide a secure path through an untrusted network. Tunneling typically contrasts with a layered protocol model such as those of Open Systems Interconnection (“OSI”) or Transmission Control Protocol/Internet Protocol (“TCP/IP”). The delivery protocol may operate at a higher level in the model than does the payload protocol, or at the same level.
- The conventional approach for tunneling IP packets using an IP-layer approach, wherein an IP routing table is used to decide which packets are to be tunneled. According to this conventional approach, an application writes data to a socket, the TCP/IP stack packetizes the data into IP packets, and the IP packets are routed to the tunnel. It is noted that under this approach, there is no application intelligence built into the process. In other words, all applications have access to the same IP routing table. Any application is potentially routable through an IP-layer VPN, and is only limited based on the IP address the application attempts to access.
- In some conventional systems, the access limitation is on a device (e.g., the VPN access is limited to the certain devices that are registered as users of the VPN). To provide a specific example, Company X may maintain a VPN to be used by its employees. Company X may issue computing devices (e.g., desktops, laptops, tablets, notebooks, smart phones, etc.) to the employees. These devices may be registered devices with the VPN, allowing the employees to access the VPN of Company X. However, in today's world, the paradigm is shifting to a bring-your-own-device (“BYOD”) model, (e.g., people want to have ownership of their own device, have access to the VPN when they do not have access to their employer-issued devices, etc.). When VPN access is limited by device, the BYOD model does not work due to the user's personal device not being a registered device with the VPN of Company X.
- Accordingly, the exemplary embodiments described herein may be advantageous to such BYOD private network enterprises. This is due to the fact that the enterprise may easily control which applications may access the VPN, as opposed to controlling every device attempting access. Furthermore, the application-specific access systems and methods enable the enterprise to perform traffic inspection, as the actual application data stream is readily accessible for examination. Conventional inspection would otherwise require the enterprise to perform traditional packet inspection.
- While one exemplary embodiment describes an application-specific VPN wherein specific applications are authorized to use a VPN tunnel, additional embodiments may feature any number of procedures, or a combination of procedures, for permitting access to a VPN. For instance, a further embodiment may be an application-layer VPN wherein streams of application data are tunneled to the VPN. Furthermore, the exemplary application rules described herein are not restricted in implementation to the authorization of Application-layer VPN. In other words, the exemplary application rules described herein may also be implemented to authorize specific applications to use an IP-layer VPN.
- According to the systems and methods described herein, the exemplary embodiments may provide application-specific access to a VPN. Accordingly, when an application creates a network object, the library may match the application against a set of rules that dictate which applications are allowed to use the VPN tunnel. If the application matches one of these rules, the flow of network data may then be diverted through the VPN tunnel, as opposed to entering the TCP/IP stack. This application-specific VPN access is not limited to a specific device and allows an authorized VPN user to access the VPN using any device. It is noted that the VPN tunnel may be established after authenticating the user. Once established, access to the tunnel may then be restricted to applications that match the rules.
- The exemplary systems and methods described herein provide control over which applications have access to the private network. The enforcement of this access may be achieved through application VPN rules. In addition, these systems and methods may eliminate data leakage from the applications that match the rules. Accordingly, applications that do not match the rules may be prevented from sending data through the VPN tunnel.
- It is noted that while an exemplary embodiment may be application-based access to a private network, additional embodiments are not limited to such schemes. For instance, an account-based matching system for accessing a private network may also be used. For example, the account may include mail, contacts, and/or calendar accounts of a user's device. An exemplary account-based access system will be described in greater detail below.
- Regardless of the type of matching system implemented by the exemplary embodiments (e.g., application-based, account-based, etc.), it is noted that the set of rules within the embodiments may be generated by an administrator at an entity controlling the VPN.
-
FIG. 1 shows anexemplary system 100 for application specific access to aVPN 110 for adevice 105 executing any number of applications. Theexemplary system 100 may include anelectronic device 105 having aprocessor 120 and amemory 130, such as a non-transitory computer-readable storage medium. Thedevice 105 may be a device such as, for example, a desktop, laptop, tablet, notebook, smart phone, etc. Thesystem 100 may allow for anapplication 140 to access aVPN server 115 within the VPN 110 based on a set ofrules 135 stored within thememory 130, wherein therules 135 dictate which specific applications have access to theVPN 110. - According to the exemplary embodiments,
application 140 of thedevice 105 may be linked to anetwork library 145. When theapplication 140 creates a new data flow, such as via a TCP connection object, theprocessor 120 may utilize thelibrary 145 to match theapplication 140 to the set ofrules 135. If theapplication 140 matches one of the storedrules 135, theprocessor 120 may divert the flow of network data through aVPN tunnel 125, as opposed to entering the TCP/IP stack. In other words, each packet of the application data may traverse a network stack (e.g., TCP/IP stack) only a single time before being communicated to theVPN 110. - In addition, the network flow data may be diverted from a socket layer to a
VPN agent 150 process running in user space. Furthermore, theVPN agent 150 process may pass the network data to a third-party plugin 160 that tunnels the data over a tunnel connection to theVPN 110. It is noted that while theexemplary system 100 includes the third-party plugin 160 for tunneling data to theVPN 110, alternative embodiments may include first-party and/or integrated data transportation components for tunneling network flow data to theVPN 110. - Since the network data may not traverse the TCP/IP stack before being diverting to the
VPN agent 150, the data would not be packetized and the third-party plugin 160 operating in theVPN agent 150 may have access to the stream of network data in the same, or similar, format as written by theapplication 140. When the third-party plugin 160 receives data from theVPN tunnel 125, theprocessor 120 may write the data back to a receive buffer of a socket. Accordingly, theapplication 140 may then be notified by theprocessor 120 that the data is available and may read the data from the socket. As noted above, the network data may only have to traverse the TCP/IP stack once. For example, the network data may arrive at the TCP/IP stack after being processed by thethird party plugin 160, so the packets may be routed over the Internet. - According to the exemplary embodiments of the
system 100, the set ofrules 135 may include any number of authentication procedures for permitting theapplication 140 to access to theVPN 110. For instance, therules 135 may optionally utilize a signing identifier that uniquely identifies theapplication 140, a designated requirement that identifies the party who signed theapplication 140, a list of allowed domains, or any other rules that uniquely identify an application and/or an account. Accordingly, the signing identifier and the designated requirement of theapplication 140 may be matched against the signature of a calling application. If the signing identifier and the designated requirement match, and there are domains present in therules 135, then a host name of a host within the private network that theapplication 140 is trying to access may be suffix-matched against the list of domains. If the host matches any one of the names, or if there are no domains in therules 135, then theapplication 140 satisfies therules 135. - According to an additional embodiment of the
system 100, the set ofrules 135 may include account-based access procedures for authorizing theapplication 140 to access theVPN 110. For instance, theapplication 140 may be modified to “tag” the network data flow with a string identifying the account for which network access is being established. Exemplary accounts may include mail accounts, contact lists, calendar accounts, etc. The string identifying the account may then be matched against a list of account identifiers in therules 135. In addition, a “wildcard” account may also be used, wherein every account identifier matches the wildcard account. Accordingly, if there is a match with one of the account identifiers, or if there is a wildcard account, then the account satisfies therules 135. - Although not shown in
FIG. 1 , thedevice 105 may also include one or more network interfaces. A network interface may implement, among other functionality, the lower layers (i.e., the physical and data link layers, and/or portions thereof) in the network stack in thedevice 105. A network interface may be or include components such as a transceiver, a processor and/or specific-purpose DSP circuitry, and/or analog signal processing circuitry for implementing wired/wireless communications. Thedevice 105 may include one or more network interfaces that communicate using technologies such as but not limited to: Ethernet; WiFi (IEEE 802.11a/b/g/n/ac and/or other IEEE 802.11 technologies); cellular technologies (including but not limited to LTE, LTE-A, UMTS, CDMA2000, and/or GSM-EDGE); and/or other wired and/or wireless communications technologies. In an instance where thedevice 105 includes a wireless network interface, thedevice 105 may also include an antenna (also not shown inFIG. 1 ) coupled to the wireless network interface. Whenever it is described in this document that thedevice 105 communicates data to/from theVPN server 115 and/or via theVPN tunnel 125, this communication of data may be performed using one or more of the network interfaces. -
FIG. 2 shows an exemplarydata packet structure 220 for application-specific access to a VPN in comparison to a conventionaldata packet structure 210 for routing table access to a VPN. - As illustrated in the conventional
data packet structure 210, thestructure 210 includes anIP header 211 having a source IP address and a destination IP address, a User Datagram Protocol (“UDP”)header 212 have a source port and a destination port, afurther IP header 213, aTCP header 214 having a source port and a destination port, and the payload ofapplication data 215. Those skilled in the art would understand that both theUDP header 212 and theTCP header 213 both reside within the TCP/IP stack (e.g., transport layer) of the IP suite. - In contrast to the conventional
data packet structure 210, theexemplary structure 220 includes anIP header 221, aTCP header 222, a transport layer security (“TLS”)header 223, and the payload ofapplication data 224. As noted above, the flow of this exemplary network data may be diverted through the VPN tunnel, as opposed to entering the TCP/IP stack. Accordingly, theexemplary structure 220 may not require the UDP header and IP header of transport layer segments. - As noted above, the
exemplary structure 220 of the application-specific access to the VPN allows for improved traffic inspection within the network. Specifically, the traffic may be easier to monitor since data is not wrapped in the IP/UDP layer. As opposed to traditional packet inspection of the conventionaldata packet structure 210, the exemplary systems and methods described herein allow, in some instances, for the inspection of the actual application data stream. It is noted that any filtering software running within theVPN agent 150 process or theVPN server 115 may receive the application data wrapped in the IP and TCP headers, while not including the IP UDP headers. The IP and UDP headers will have been stripped off by the TCP/IP stack before the packet is delivered to the filtering system. Accordingly, of the parts of the packets the filtering system will receive from the TCP/IP stack, the filter would receive theIP header 213, theTCP header 214, and theapplications data 215 for the conventionaldata packet structure 210. Alternatively, for theexemplary structure 220, the filter would receive theapplications data 224. -
FIG. 3 shows anexemplary method 300 utilizing application-specific access to theVPN 110. Specifically, themethod 300 is a overview of the network data flow including theapplication 140 starting up, setting up theVPN tunnel 125, and communicating data between theapplication 140 and theVPN server 115 of theVPN 110. The step performed by themethod 300 will be described in reference to theexemplary system 100 and its components described above with reference toFIG. 1 . In addition, it is noted that each of the steps ofmethod 300 may be performed by an AppTunnel framework, including theVPN agent 150 and theprocessor 120, which may be a physical hardware processing component of thesystem 100. - In
step 310, theprocessor 120 may receive a query from theapplication 140 to connect with a destination host over theVPN 110 via theVPN tunnel 115. For instance, this query may be a domain name system (“DNS”) query to access a specific identification string (e.g., HTTP request) on the network. - In
step 320, theprocessor 120 may create a network object, such as a TCP connection object, from theapplication 140. The network object may be used to establish a new network data flow between theapplication 140 and theexemplary VPN 110. - In
step 330, theprocessor 120 may match the network object against the set ofrules 135 stored in thememory 130 of thesystem 100. For instance, theprocessor 120 may obtain a process identifier (“PID/ID”) of theapplication 140 as well as a destination host for theapplication 140. Accordingly, theprocessor 120 may perform a look-up for the PID/IP of theapplication 140 and the destination host within therules 135. - In
step 340, theprocessor 120 may determine whether theapplication 140 satisfies therules 135. If the tunneling rules 135 dictate that the network data flow may be tunneled to theVPN 110, then themethod 300 may advance to step 350. However, if theapplication 140 fails to satisfy therules 135, theapplication 140 may be denied access to theVPN 110 instep 345. - In
step 350, theprocessor 120 may determine whether theapplication 140 specifies a destination host by name. If theapplication 140 specifies the destination, then themethod 300 may advance to step 360. However, if theapplication 140 does not name a host destination, theapplication 140 may bypass the DNS resolution, and the method may advance to step 370. - In
step 360, theprocessor 120 sends the host name to thethird party plugin 160 of theVPN agent 150 for resolution and, thethird party plugin 160 may resolve the host name and send the results to theprocessor 120. Those skilled in the art would understand that host name resolution allows for successfully mapping the host name to an IP address, wherein the host name is an alias assigned to an IP node to identify it as a TCP/IP host. - In
step 370, theprocessor 120 may open a flow divert socket of a kernel to theVPN server 115. For instance, theprocessor 120 may open the socket to the destination host and the TCP connection object may set a socket option indicating that network flow data should be tunneled to theVPN server 115. As opposed to having the TCP connection object set a socket option, theprocessor 120 may alternatively, set a rule in the socket filter indicating that a particular PID/ID and host combination should be allowed to tunnel via theVPN server 110. - In
step 380, theprocessor 120 may establish a network data flow with theVPN server 115. In other words, upon receiving data from theapplication 140 on the socket, the socket filter in the kernel may send the data to thethird party plugin 160 for tunneling. - In
step 390, theprocessor 120 may communicate data between theVPN 110 and theapplication 140 via theVPN tunnel 125. When thethird party plugin 160 receives data from the tunnel destined for theapplication 140, thethird party plugin 160 may send the data to the socket filter of the kernel. The socket filter may place the data in the receive buffer of the socket, and theapplication 140 may then read the data from the socket. - It is noted that signing identifiers, designated requirements, account identifications and host name matching are only examples of any number of rules that may be used to uniquely identify the application and/or other characteristics for VPN access. Accordingly, alternative rules for identifying applications may be performed during the
method 300. - The above-described exemplary embodiments provide application-specific access to a private network that does not require the use of the TCP/IP layer. Specifically, network data originating from certain applications may be routed through the VPN tunnel, while all other traffic may be routed outside the VPN. It is noted that application-specific routing may, in some instances allow for sockets of a kernel to be mapped to application identifiers of the application that opened it.
- As noted above, a lookup may be performed on the application identifiers based on a set of rules for VPN access. If the lookup satisfies the rules, a network interface may be obtained and a routing socket option is set on the socket. Accordingly, all traffic generated by the socket may be routed to the specified network interface.
- The above-described exemplary embodiments may be implemented in any number of enforcement procedures to ensure that only the applications that satisfy the set of rules may be allowed to use the exemplary VPN. For instance, in a “whitelist” procedure, wherein specific applications may be routed to the
VPN 110, enforcement may be achieved by not installing any routes to theVPN tunnel 125 in therules 135. Access to theVPN 110 may then be limited to a set of applications in the whitelist. Alternatively, in a “blacklist” procedure, wherein specific applications may not be routed to theVPN 110, enforcement may ensure that sockets used by these applications are not routed through theVPN tunnel 125. In other words, these blacklist applications may not be scoped to the VPN interface even if explicitly scoped via a socket option. - A further enforcement embodiment may be to enhance the filtering of traffic (e.g., PacketFilter) to support rules based on application identifiers. In addition, this embodiment may also serve as a replacement implementation for application firewalling.
- It will be apparent to those skilled in the art that various modifications may be made in the present invention, without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
Claims (20)
1. A method, comprising:
at an electronic device that includes a processor, a memory, and a network interface, wherein the processor, memory, and network interface are configured to implement a network stack that includes a transport layer, a network layer, and lower layers:
generating, by an application executing on the electronic device, a request for a network data flow to a private network;
comparing identification information associated with the application against a set of rules stored on the memory, wherein the set of rules identifies conditions for the application to be authorized to access the private network, wherein the set of rules includes:
a signing identifier that identifies the application; and
a designated requirement that identifies a party that signed the application; and
upon the identification information satisfying the conditions for the application to access the private network:
establishing a connection for the network data flow; and
transmitting application data from the application to the private network over the connection, wherein the application data includes one or more packets, and wherein, for each of the one or more packets:
the packet traverses the network stack only a single time before being transmitted by the electronic device to the private network; and
the packet, when transmitted by the electronic device to the private network, includes a single Internet Protocol (IP) header and a single transport layer header and does not include a second transport layer header or a second IP header.
2. The method of claim 1 , wherein the set of rules further includes an account identification of a user account allowed to access the private network,
wherein the identification information includes an account tag, and
wherein the identification information satisfies the conditions when the account tag matches the account identification.
3. The method of claim 1 , further comprising:
receiving, by the network stack of the electronic device, a further packet from the private network, the further packet including header information and application data; and
removing from the further packet, during a single traversal of the network stack by the further packet, all header information from the further packet.
4. The method of claim 1 , wherein the single transport layer header is a Transmission Control Protocol (TCP) header.
5. The method of claim 1 , further comprising:
opening a flow divert socket for application data to flow between the application to a data transportation component of the electronic device, wherein the data transportation component directs the network data flow directly to the private network.
6. The method of claim 5 , wherein the flow divert socket involves a socket filter that places the network flow data in a receive buffer accessible to the application.
7. The method of claim 1 , wherein the connection involves a Transmission Control Protocol (TCP) connection object that sets a socket option indicating that the network flow data will be tunneled over the connection.
8. The method of claim 3 , further comprising:
filtering, by a filter of a private network agent, the application data from the further packet.
9. A device, comprising:
a memory storing a plurality of rules;
a network interface; and
a processor, wherein the processor, memory, and network interface are configured to implement a network stack that includes a transport layer, a network layer, and lower layers, the processor being further configured to perform actions that include:
receiving a request for a network data flow to a private network from an application executing on the device;
comparing identification information associated with the application against a set of rules stored on the memory, wherein the set of rules identifies conditions for the application to be authorized to access the private network, wherein the set of rules includes:
a signing identifier that identifies the application; and
a designated requirement that identifies a party that signed the application;
upon the identification information satisfying the conditions for the application to access the private network:
establishing a connection for the network data flow; and
transmitting application data to the private network over the connection, wherein the application data includes one or more packets, and wherein, for each of the one or more packets:
the packet traverses the network stack only a single time before being transmitted by the device to the private network; and
the packet, when transmitted by the device to the private network, includes a single Internet Protocol (IP) header and a single transport layer header and does not include a second transport layer header or a second IP header.
10. The device of claim 9 , wherein the set of rules further includes an account identification of a user account allowed to access the private network,
wherein the identification information includes an account tag, and
wherein the identification information satisfies the conditions when the account tag matches the account identification.
11. The device of claim 9 , wherein the actions further comprise:
receiving, by the network stack of the device, a further packet from the private network, the further packet including header information and application data; and
removing from the further packet, during a single traversal of the network stack by the further packet, all header information from the further packet.
12. The device of claim 9 , wherein the transport layer header is a Transmission Control Protocol (TCP) header.
13. The device of claim 9 , wherein the processor is further configured to perform:
opening a flow divert socket for application data to flow between the application to a data transportation component of the device, wherein the data transportation component directs the network data flow directly to the private network, and wherein the flow divert socket includes a socket filter placing the network flow data in a receive buffer accessible to the application.
14. The device of claim 9 , wherein the connection is a Transmission Control Protocol (TCP) connection object that sets a socket option indicating that the network flow data will be tunneled over the connection.
15. A non-transitory computer readable storage medium with an executable program stored thereon that is executable by a processor, the computer readable storage medium, processor and a network interface being configured to implement a network stack that includes a transport layer, a network layer, and lower layers, wherein the program instructs the processor to perform actions that include:
receiving a request for a network data flow to a private network from an application executing on the device;
comparing identification information associated with the application against a set of rules stored on the memory, wherein the set of rules identifies conditions for the application to be authorized to access the private network, wherein the set of rules includes:
a signing identifier that identifies the application; and
a designated requirement that identifies a party that signed the application;
upon the identification information satisfying the conditions for the application to access the private network:
establishing a connection for the network data flow; and
transmitting application data to the private network over the connection, wherein the application data includes one or more packets, and wherein, for each of the one or more packets:
the packet traverses the network stack only a single time before being transmitted to the private network; and
the packet, when transmitted to the private network, includes a single Internet Protocol (IP) header and a single transport layer header and does not include a second transport layer header or a second IP header.
16. The computer readable storage medium of claim 15 , wherein the set of rules further includes an account identification of a user account allowed to access the private network,
wherein the identification information includes an account tag, and
wherein the identification information satisfies the conditions when the account tag matches the account identification.
17. The computer readable storage medium of claim 15 , wherein the actions further comprise:
receiving, by the network stack, a further packet from the private network, the further packet including header information and application data; and
removing from the further packet, during a single traversal of the network stack by the further packet, all header information from the further packet.
18. The computer readable storage medium of claim 15 , wherein the actions further include:
opening a flow divert socket for application data to flow between the application to a data transportation component of a device which comprises the computer readable storage medium, wherein the data transportation component directs the network data flow directly to the private network.
19. The computer readable storage medium of claim 17 , wherein the actions further include:
filtering the application data from the further packet.
20. The computer readable storage medium of claim 15 , wherein the connection involves a Transmission Control Protocol (TCP) connection object that sets a socket option indicating that the network flow data will be tunneled over the connection.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/231,209 US20140366120A1 (en) | 2013-06-06 | 2014-03-31 | Systems and Methods for Application-Specific Access to Virtual Private Networks |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/911,789 US9143481B2 (en) | 2013-06-06 | 2013-06-06 | Systems and methods for application-specific access to virtual private networks |
US14/231,209 US20140366120A1 (en) | 2013-06-06 | 2014-03-31 | Systems and Methods for Application-Specific Access to Virtual Private Networks |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/911,789 Continuation US9143481B2 (en) | 2013-06-06 | 2013-06-06 | Systems and methods for application-specific access to virtual private networks |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140366120A1 true US20140366120A1 (en) | 2014-12-11 |
Family
ID=51063820
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/911,789 Active US9143481B2 (en) | 2013-06-06 | 2013-06-06 | Systems and methods for application-specific access to virtual private networks |
US14/231,209 Abandoned US20140366120A1 (en) | 2013-06-06 | 2014-03-31 | Systems and Methods for Application-Specific Access to Virtual Private Networks |
US14/827,953 Active 2034-01-19 US10348686B2 (en) | 2013-06-06 | 2015-08-17 | Systems and methods for application-specific access to virtual private networks |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/911,789 Active US9143481B2 (en) | 2013-06-06 | 2013-06-06 | Systems and methods for application-specific access to virtual private networks |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/827,953 Active 2034-01-19 US10348686B2 (en) | 2013-06-06 | 2015-08-17 | Systems and methods for application-specific access to virtual private networks |
Country Status (3)
Country | Link |
---|---|
US (3) | US9143481B2 (en) |
TW (1) | TWI549452B (en) |
WO (1) | WO2014197371A1 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105049431A (en) * | 2015-06-30 | 2015-11-11 | 深圳市深信服电子科技有限公司 | Data access control method and device |
CN107294800A (en) * | 2016-04-11 | 2017-10-24 | 深圳平安讯科技术有限公司 | Network data access control method and system based on Mobile operating system |
CN109547397A (en) * | 2017-09-22 | 2019-03-29 | 台众电脑股份有限公司 | Network security management system |
US10574659B2 (en) * | 2017-09-22 | 2020-02-25 | Sofnet Corporation | Network security management system |
US11283694B2 (en) * | 2017-07-20 | 2022-03-22 | Movius Interactive Corportion | System and method providing usage analytics for a mobile device |
US11329883B2 (en) * | 2020-03-12 | 2022-05-10 | Fortinet, Inc. | Dynamic establishment of application-specific network tunnels between network devices by an SDWAN controller |
US20220174046A1 (en) * | 2016-02-01 | 2022-06-02 | Airwatch Llc | Configuring network security based on device management characteristics |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140310606A1 (en) * | 2013-04-11 | 2014-10-16 | Xiaomi Inc. | Method and device for providing plugin in contact list |
US20150095469A1 (en) * | 2013-09-30 | 2015-04-02 | Electronics And Telecommunications Research Institute | Identifier-based communication method using application program interface |
US9762571B2 (en) * | 2015-10-19 | 2017-09-12 | Team Internet Ag | Securing connections to unsecure internet resources |
US10404761B2 (en) | 2016-02-04 | 2019-09-03 | Airwatch, Llc | Segregating VPN traffic based on the originating application |
US10484423B2 (en) * | 2016-02-19 | 2019-11-19 | Secureworks Corp. | System and method for detecting and monitoring thread creation |
US10003670B2 (en) * | 2016-06-17 | 2018-06-19 | Airwatch Llc | Remote provisioning and enrollment of enterprise devices with on-premises domain controllers |
US11599890B1 (en) * | 2016-12-22 | 2023-03-07 | Wells Fargo Bank, N.A. | Holistic fraud cocoon |
CN107018063A (en) | 2017-01-19 | 2017-08-04 | 阿里巴巴集团控股有限公司 | Data interactive method and device based on application |
US11057340B2 (en) | 2019-07-19 | 2021-07-06 | Vmware, Inc. | Per-application split-tunneled UDP proxy |
US10992579B2 (en) * | 2019-07-19 | 2021-04-27 | Vmware, Inc. | Per-application split-tunneled proxy |
US11190480B2 (en) | 2019-07-19 | 2021-11-30 | Vmware, Inc. | Transparently proxying connections based on hostnames |
US11652825B2 (en) * | 2021-08-09 | 2023-05-16 | International Business Machines Corporation | Packet authentication in a VXLAN system |
US20230388272A1 (en) * | 2022-05-31 | 2023-11-30 | Microsoft Technology Licensing, Llc | Multiple Virtual Private Network Active Connection Management |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060236370A1 (en) * | 2004-02-26 | 2006-10-19 | Packetmotion, Inc. | Network security policy enforcement using application session information and object attributes |
US20110066841A1 (en) * | 2009-09-14 | 2011-03-17 | Dennis Sidney Goodrow | Platform for policy-driven communication and management infrastructure |
US8316427B2 (en) * | 2007-03-09 | 2012-11-20 | International Business Machines Corporation | Enhanced personal firewall for dynamic computing environments |
US20130298201A1 (en) * | 2012-05-05 | 2013-11-07 | Citrix Systems, Inc. | Systems and methods for network filtering in vpn |
US20140105062A1 (en) * | 2012-10-17 | 2014-04-17 | Verizon Patent And Licensing Inc. | Feature peer network with scalable state information |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7418504B2 (en) | 1998-10-30 | 2008-08-26 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US7188180B2 (en) | 1998-10-30 | 2007-03-06 | Vimetx, Inc. | Method for establishing secure communication link between computers of virtual private network |
US6502135B1 (en) | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
US6636898B1 (en) | 1999-01-29 | 2003-10-21 | International Business Machines Corporation | System and method for central management of connections in a virtual private network |
US6789118B1 (en) * | 1999-02-23 | 2004-09-07 | Alcatel | Multi-service network switch with policy based routing |
US7634455B1 (en) * | 1999-09-23 | 2009-12-15 | Agile Software Corporation | Method and apparatus for providing controlled access to software objects and associated documents |
US20020010866A1 (en) * | 1999-12-16 | 2002-01-24 | Mccullough David J. | Method and apparatus for improving peer-to-peer bandwidth between remote networks by combining multiple connections which use arbitrary data paths |
US7062642B1 (en) * | 2000-05-20 | 2006-06-13 | Ciena Corporation | Policy based provisioning of network device resources |
EP2288083B1 (en) * | 2000-06-16 | 2013-07-31 | Fujitsu Limited | Communication device having VPN accomodation function |
US20030217126A1 (en) | 2002-05-14 | 2003-11-20 | Polcha Andrew J. | System and method for automatically configuring remote computer |
US7231664B2 (en) * | 2002-09-04 | 2007-06-12 | Secure Computing Corporation | System and method for transmitting and receiving secure data in a virtual private group |
US7346770B2 (en) * | 2002-10-31 | 2008-03-18 | Microsoft Corporation | Method and apparatus for traversing a translation device with a security protocol |
WO2004063843A2 (en) | 2003-01-15 | 2004-07-29 | Matsushita Electric Industrial Co., Ltd. | PEER-TO-PEER (P2P) CONNECTION DESPITE NETWORK ADDRESS TRANSLATOR (NATs) AT BOTH ENDS |
US7478427B2 (en) | 2003-05-05 | 2009-01-13 | Alcatel-Lucent Usa Inc. | Method and apparatus for providing adaptive VPN to enable different security levels in virtual private networks (VPNs) |
US7448080B2 (en) * | 2003-06-30 | 2008-11-04 | Nokia, Inc. | Method for implementing secure corporate communication |
US7797752B1 (en) * | 2003-12-17 | 2010-09-14 | Vimal Vaidya | Method and apparatus to secure a computing environment |
US8065418B1 (en) | 2004-02-02 | 2011-11-22 | Apple Inc. | NAT traversal for media conferencing |
US7941827B2 (en) * | 2004-02-26 | 2011-05-10 | Packetmotion, Inc. | Monitoring network traffic by using a monitor device |
US8127045B2 (en) | 2004-09-13 | 2012-02-28 | Apple Inc. | Dynamically configurable connection on demand |
US8166538B2 (en) | 2005-07-08 | 2012-04-24 | Microsoft Corporation | Unified architecture for remote network access |
US9942271B2 (en) | 2005-12-29 | 2018-04-10 | Nextlabs, Inc. | Information management system with two or more interactive enforcement points |
US20070234418A1 (en) * | 2006-03-30 | 2007-10-04 | Samsung Electronics Co., Ltd. | Method and apparatus of remote access message differentiation in VPN endpoint routers |
US8495181B2 (en) | 2006-08-03 | 2013-07-23 | Citrix Systems, Inc | Systems and methods for application based interception SSI/VPN traffic |
US8869262B2 (en) | 2006-08-03 | 2014-10-21 | Citrix Systems, Inc. | Systems and methods for application based interception of SSL/VPN traffic |
US8095786B1 (en) | 2006-11-09 | 2012-01-10 | Juniper Networks, Inc. | Application-specific network-layer virtual private network connections |
WO2008152881A1 (en) * | 2007-06-12 | 2008-12-18 | Nec Corporation | Communication device and communication method |
US8208900B2 (en) | 2008-03-04 | 2012-06-26 | Apple Inc. | Secure device configuration profiles |
US8726007B2 (en) * | 2009-03-31 | 2014-05-13 | Novell, Inc. | Techniques for packet processing with removal of IP layer routing dependencies |
US8607316B2 (en) * | 2010-08-31 | 2013-12-10 | Blackberry Limited | Simplified authentication via application access server |
US9154426B2 (en) | 2011-10-31 | 2015-10-06 | Apple Inc. | Low-latency hole punching |
CN104904178B (en) * | 2012-10-15 | 2018-09-25 | 思杰***有限公司 | The method and apparatus and computer-readable medium of virtual private network tunnel are provided |
US9210128B2 (en) * | 2012-10-25 | 2015-12-08 | Check Point Software Technologies Ltd. | Filtering of applications for access to an enterprise network |
US9584523B2 (en) * | 2012-10-30 | 2017-02-28 | Hewlett Packard Enterprise Development Lp | Virtual private network access control |
US9948675B2 (en) * | 2013-04-04 | 2018-04-17 | The Mitre Corporation | Identity-based internet protocol networking |
-
2013
- 2013-06-06 US US13/911,789 patent/US9143481B2/en active Active
-
2014
- 2014-03-31 US US14/231,209 patent/US20140366120A1/en not_active Abandoned
- 2014-06-02 WO PCT/US2014/040507 patent/WO2014197371A1/en active Application Filing
- 2014-06-06 TW TW103119808A patent/TWI549452B/en active
-
2015
- 2015-08-17 US US14/827,953 patent/US10348686B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060236370A1 (en) * | 2004-02-26 | 2006-10-19 | Packetmotion, Inc. | Network security policy enforcement using application session information and object attributes |
US8316427B2 (en) * | 2007-03-09 | 2012-11-20 | International Business Machines Corporation | Enhanced personal firewall for dynamic computing environments |
US20110066841A1 (en) * | 2009-09-14 | 2011-03-17 | Dennis Sidney Goodrow | Platform for policy-driven communication and management infrastructure |
US20130298201A1 (en) * | 2012-05-05 | 2013-11-07 | Citrix Systems, Inc. | Systems and methods for network filtering in vpn |
US20140105062A1 (en) * | 2012-10-17 | 2014-04-17 | Verizon Patent And Licensing Inc. | Feature peer network with scalable state information |
Non-Patent Citations (2)
Title |
---|
A distributed object-based IPSec multi-tunnels concurrent architecture, Wang et al, IEEE 2011 * |
Analysis of Current VPN Technologies, Berger, Thomas, IEEE 2006 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105049431A (en) * | 2015-06-30 | 2015-11-11 | 深圳市深信服电子科技有限公司 | Data access control method and device |
US20220174046A1 (en) * | 2016-02-01 | 2022-06-02 | Airwatch Llc | Configuring network security based on device management characteristics |
CN107294800A (en) * | 2016-04-11 | 2017-10-24 | 深圳平安讯科技术有限公司 | Network data access control method and system based on Mobile operating system |
US11283694B2 (en) * | 2017-07-20 | 2022-03-22 | Movius Interactive Corportion | System and method providing usage analytics for a mobile device |
CN109547397A (en) * | 2017-09-22 | 2019-03-29 | 台众电脑股份有限公司 | Network security management system |
US10574659B2 (en) * | 2017-09-22 | 2020-02-25 | Sofnet Corporation | Network security management system |
US11329883B2 (en) * | 2020-03-12 | 2022-05-10 | Fortinet, Inc. | Dynamic establishment of application-specific network tunnels between network devices by an SDWAN controller |
Also Published As
Publication number | Publication date |
---|---|
US20150358293A1 (en) | 2015-12-10 |
US20140366081A1 (en) | 2014-12-11 |
US9143481B2 (en) | 2015-09-22 |
US10348686B2 (en) | 2019-07-09 |
WO2014197371A1 (en) | 2014-12-11 |
TWI549452B (en) | 2016-09-11 |
TW201511508A (en) | 2015-03-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10348686B2 (en) | Systems and methods for application-specific access to virtual private networks | |
US10630725B2 (en) | Identity-based internet protocol networking | |
EP2264956B1 (en) | Method for securing remote access to private networks | |
CA3047654C (en) | Vxlan implementation method, network device, and communications system | |
US10587579B2 (en) | Varying encryption level of traffic through network tunnels | |
US9210128B2 (en) | Filtering of applications for access to an enterprise network | |
US20130332724A1 (en) | User-Space Enabled Virtual Private Network | |
US20070016945A1 (en) | Automatically generating rules for connection security | |
US10785196B2 (en) | Encryption key management of client devices and endpoints within a protected network | |
US11689581B2 (en) | Segregating VPN traffic based on the originating application | |
WO2019246331A1 (en) | System and method for creating a secure hybrid overlay network | |
US10079812B1 (en) | Secure content storage by customer-premises equipment | |
US20240195795A1 (en) | Computer-implemented methods and systems for establishing and/or controlling network connectivity |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: APPLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WOOD, JAMES P.;REEL/FRAME:032579/0649 Effective date: 20130606 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |