Methods for secure access to services behind a firewall and devices thereof

Methods, non-transitory computer readable media, rendezvous gateway (RG) apparatuses, and network security systems that send an RG synchronization message (SYN) to an application in a secure domain following receipt, from a client, of a client SYN comprising an indication of the application. A rendezvous agent (RA) SYN is received, via a firewall coupled to the security domain and in response to the RG SYN, from an RA in the secure domain. A first RG synchronization-acknowledgement message (SYN+ACK) is sent to the client in response to the client SYN. A second RG SYN+ACK is sent, via the firewall, to the RA in response to the RA SYN. The RA is notified of receipt of a client acknowledgement message (ACK) from the client. An RA ACK is received, from the RA and via the firewall, in response to the notification, to thereby establish a full connection between the client and the application.

FIELD

This technology generally relates to network security and, more particularly, to methods and devices for facilitating secure access to services behind a firewall.

BACKGROUND

Providing external users with access to services, such as cloud infrastructure and other Internet services that are located within or behind a firewall is a task that is difficult to both manage and maintain. To allow such secure access, applications, e.g., mobile applications, must create a separate external infrastructure to which a given application program must connect and poll for outside work requests or other requests. Such arrangements are inefficient, often unsecure, and require separate external infrastructure that must be maintained by the application provider.

In one particular example, an external client can use a “special” tunnel that is “punched through” a firewall for connecting to services. The services can be Internet-of-Things (IoT) services and/or the connection can be via a virtual private network (VPN), for example. The special tunnel is not sufficiently restrictive in relation to providing external client access.

As such, the special tunnel inadvertently provides a gateway from an unsecure external client, into a “secure” domain, e.g., having the IoT services, thereby rendering the secure domain vulnerable to malware or hacking. To use the firewall, an external client must be able to support the tunnel protocol of the special tunnel or have special tunneling software for the special tunnel. The special tunnel must be configured in the firewall that is protecting the secure domain. However, this requirement also increases the attackable “surface” of the firewall.

SUMMARY

A method for secure access to services behind a firewall implemented in cooperation with a network security system including one or more rendezvous gateway (RG) modules, rendezvous agent (RA) modules, firewall modules, host modules, or client modules, includes sending an RG synchronization message (SYN) to an application in a secure domain following receipt, from a client, of a client SYN comprising an indication of the application. A rendezvous agent (RA) SYN is received, via a firewall coupled to the security domain and in response to the RG SYN, from an RA in the secure domain. A first RG synchronization-acknowledgement message (SYN+ACK) is sent to the client in response to the client SYN. A second RG SYN+ACK is sent, via the firewall, to the RA in response to the RA SYN. The RA is notified of receipt of a client acknowledgement message (ACK) from the client. An RA ACK is received, from the RA and via the firewall, in response to the notification, to thereby establish a full connection between the client and the application.

An RG apparatus includes memory including programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to send an RG SYN to an application in a secure domain following receipt, from a client, of a client SYN comprising an indication of the application. An RA SYN is received, via a firewall coupled to the security domain and in response to the RG SYN, from an RA in the secure domain. A first RG SYN+ACK is sent to the client in response to the client SYN. A second RG SYN+ACK is sent, via the firewall, to the RA in response to the RA SYN. The RA is notified of receipt of a client ACK from the client. An RA ACK is received, from the RA and via the firewall, in response to the notification, to thereby establish a full connection between the client and the application.

A non-transitory computer readable medium having stored thereon instructions for secure access to services behind a firewall including executable code that, when executed by one or more processors, causes the processors to send an RG SYN to an application in a secure domain following receipt, from a client, of a client SYN comprising an indication of the application. An RA SYN is received, via a firewall coupled to the security domain and in response to the RG SYN, from an RA in the secure domain. A first RG SYN+ACK is sent to the client in response to the client SYN. A second RG SYN+ACK is sent, via the firewall, to the RA in response to the RA SYN. The RA is notified of receipt of a client ACK from the client. An RA ACK is received, from the RA and via the firewall, in response to the notification, to thereby establish a full connection between the client and the application.

A network security system includes one or more RG modules, RA modules, firewall modules, host modules, or client modules, memory comprising programmed instructions stored thereon, and one or more processors configured to be capable of executing the stored programmed instructions to send an RG SYN to an application in a secure domain following receipt, from a client, of a client SYN comprising an indication of the application. An RA SYN is received, via a firewall coupled to the security domain and in response to the RG SYN, from an RA in the secure domain. A first RG SYN+ACK is sent to the client in response to the client SYN. A second RG SYN+ACK is sent, via the firewall, to the RA in response to the RA SYN. The RA is notified of receipt of a client ACK from the client. An RA ACK is received, from the RA and via the firewall, in response to the notification, to thereby establish a full connection between the client and the application.

This technology has a number of associated advantages including providing methods, non-transitory computer readable media, RG apparatuses, and network security systems that provide secure techniques for clients outside a firewall to access services provided by systems, apparatuses, and devices inside the firewall. In particular, this technology authenticates users outside a firewall for providing access to services in a security domain inside the firewall. This technology facilitates scaling and enhancing firewalls and can be used to improve security and access for Internet-of-Things (IoT) deployments, for example.

DETAILED DESCRIPTION

Referring toFIG. 1, an exemplary network environment that incorporates an exemplary network security system10is illustrated. The network security system10in this example includes a rendezvous gateway60that is coupled to an external client20, via communication network(s)30, and a rendezvous agent (RA), via a firewall40. The RA70is coupled to an application91on a host80via a secure domain or network(s)50. In other examples, the external client20, RG60, firewall40, RA70, and host80may be coupled together via other topologies. The network security system10may include other network devices such as one or more routers or switches, for example, which are known in the art and thus will not be described herein. This technology provides a number of advantages including methods, non-transitory computer readable media, network security systems, and RGs that facilitate improved, secure access for clients outside a firewall to services provided by resources inside the firewall.

In this particular example, the external client20, RG60, firewall40, RA70, and host80are disclosed inFIG. 1as dedicated hardware devices. However, one or more of the external client20, RG60, firewall40, RA70, or host80can also be implemented in software within one or more other devices in the network security system10. As used herein, the term “module” refers to either an implementation as a dedicated hardware device or apparatus, or an implementation in software hosted by another hardware device or apparatus that may be hosting one or more other software components or implementations.

As one example, the RA70, as well as any of its components or applications, can be a module implemented as software executing on the host80, and many other permutations and types of implementations can also be used in other examples. Moreover, any or all of the external client20, RG60, firewall40, RA70, or host80can be implemented, and may be referred to herein, as a module.

Referring toFIGS. 1-2, the RG60of the network security system10may perform any number of functions, including providing network security, load balancing network traffic, or accelerating network traffic associated with applications, for example. The RG60in this example includes one or more processor(s)12, a memory14, and a communication interface16, which are coupled together by a bus18, although the RG60can include other types or numbers of elements in other configurations.

The processor(s)12of the RG60may execute programmed instructions stored in the memory14of the RG60for any number of the functions identified above. The processor(s)12may include one or more central processing units (CPUs) or general purpose processors with one or more processing cores, for example, although other types of processor(s) can also be used.

The memory14of the RG60stores these programmed instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programmed instructions could be stored elsewhere. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk, solid state drives, flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s)12, can be used for the memory14.

Accordingly, the memory14of the RG60can store one or more applications that can include computer executable instructions that, when executed by the RG60, cause the RG60to perform actions, such as to transmit, receive, or otherwise process messages, for example, and to perform other actions described and illustrated below with reference toFIGS. 4-15. The application(s) can be implemented as components of other applications. Further, the application(s) can be implemented as operating system extensions, plugins, or the like.

In this particular example, the memory14of the RG60includes an external secure access module22. The external secure access module22is configured to register the RA70and provide secure access for the external client20to the application91in the secure domain50. In particular, the external secure access module22receives an initial synchronization message (SYN) (e.g., in the form of a hypertext transfer protocol secure (HTTPS) request according to the transmission control protocol (TCP)) from the external client20via the communication network(s)30. The SYN from the external client20identifies the application91.

In response, the external secure access module22notifies the RA of the client SYN, which initiates a connection with the RG60through the firewall40and outside of the secure domain50. The external secure access module22proceeds to complete a TCP handshake with the RA from the perspective of the firewall40, as well as with the external client20over the communication network(s)30. The RA70also completes a TCP handshake with the application91, as described and illustrated in more detail later, to thereby facilitate a secure connection between the external client20and the application91.

Referring back toFIGS. 1-2, the communication interface16of the RG60operatively couples and communicates between the RG60, external client20, and RA70, which are coupled together at least in part by the communication network(s)30, although other types or numbers of communication networks or systems with other types or numbers of connections or configurations to other devices or elements can also be used.

By way of example only, the communication network(s)30can include local area network(s) (LAN(s)) or wide area network(s) (WAN(s)), and can use TCP/IP over Ethernet and industry-standard protocols, although other types or numbers of protocols or communication networks can be used. The communication network(s)30in this example can employ any suitable interface mechanisms and network communication technologies including, for example, teletraffic in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Ethernet-based Packet Data Networks (PDNs), combinations thereof, and the like.

While the RG60is illustrated in this example as including a single device, the RG60in other examples can include a plurality of devices or blades each having one or more processors (each processor with one or more processing cores) that implement one or more steps of this technology. In these examples, one or more of the devices can have a dedicated communication interface or memory. Alternatively, one or more of the devices can utilize the memory, communication interface, or other hardware or software components of one or more other devices included in the RG60. Additionally, one or more of the devices that together comprise the RG60in other examples can be standalone devices or integrated with one or more other devices or apparatuses.

Referring toFIGS. 1 and 3, the RA70of the network security system10may perform any number of functions, including load balancing, providing network security, or accelerating network traffic, for example. The RA70in this example includes one or more processor(s)24, a memory26, and a communication interface28, which are coupled together by a bus28, although the RA70can include other types or numbers of elements in other configurations.

The processor(s)24of the RA70may execute programmed instructions stored in the memory26of the RA70for any number of the functions identified above. The processor(s)24may include one or more central processing units (CPUs) or general purpose processors with one or more processing cores, for example, although other types of processor(s) can also be used.

The memory26of the RA70stores these programmed instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programmed instructions could be stored elsewhere. A variety of different types of memory storage devices, such as RAM, ROM, hard disk, solid state drives, flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s)24, can be used for the memory26.

Accordingly, the memory26of the RA70can store one or more applications that can include computer executable instructions that, when executed by the RA70, cause the RA70to perform actions, such as to transmit, receive, or otherwise process messages, for example, and to perform other actions described and illustrated below with reference toFIGS. 4-15. The application(s) can be implemented as components of other applications. Further, the application(s) can be implemented as operating system extensions, plugins, or the like.

Even further, the application(s) may be operative in a cloud-based computing environment. The application(s) can be executed within or as virtual machine(s) or virtual server(s) that may be managed in a cloud-based computing environment. Also, the application(s), and even the RA70itself, may be located in virtual server(s) running in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Also, the application(s) may be running in one or more VMs executing on the RA70. Additionally, in one or more examples of this technology, virtual machine(s) running on the RA70may be managed or supervised by a hypervisor.

In this particular example, the memory26of the RA70includes a secure domain access module32. The secure domain access module32is configured to securely connect and authenticate itself with the RG60, thereby establishing a trusted control connection for subsequent rendezvous connection activity. Once this control connection is established, the external client20can use the RG60to establish connections with the application91inside the firewalled or secure domain50.

In particular, the secure domain access module32facilitates the connection by receiving notification from the RG60that the external client20has initiated a SYN identifying the application91. The secure domain access module32subsequently initiates and establishes a TCP connection with the RG60and the application91, and completed TCP handshakes with the RG60and application91, as described and illustrated in more detail later.

Referring back toFIGS. 1 and 3, the communication interface28of the RA70operatively couples and communicates between the RA70, RG60, and application91hosted by the host80, which are coupled together at least in part by the secure domain50and communication network(s) between the RA70and RG60(not shown), although other types or numbers of communication networks or systems with other types or numbers of connections or configurations to other devices or elements can also be used.

By way of example only, the secure domain50can include LAN(s) and can use TCP/IP over Ethernet and industry-standard protocols, although other types or numbers of protocols or communication networks can be used. The secure domain50in this example can employ any suitable interface mechanisms and network communication technologies including, for example, teletraffic in any suitable form (e.g., voice, modem, and the like), PSTNs, Ethernet-based PDNs, combinations thereof, and the like.

Behind the firewall40, the secure domain50, such as a private home or a data center having a protected set of servers or other host devices (e.g., host80), is configured to permit only outgoing network connections. Computing applications, application programs, or software applications running within the secure domain50are advantageously made capable of providing secure access to firewalled services to the user of the external client20outside the firewalled secure domain50by way of the technology described and illustrated herein.

While the RA70is illustrated in this example as including a single device, the RA70in other examples can include a plurality of devices or blades each having one or more processors (each processor with one or more processing cores) that implement one or more steps of this technology. In these examples, one or more of the devices can have a dedicated communication interface or memory. Alternatively, one or more of the devices can utilize the memory, communication interface, or other hardware or software components of one or more other devices included in the RA70. Additionally, one or more of the devices that together comprise the RA70in other examples can be standalone devices or integrated with one or more other devices or apparatuses.

Even further, the functionality of the RA70is configurable as a separate service, a device (e.g., host80), and an integrated service in the application91. In some examples, the integration is directly performable, e.g., by configuring the application91with a functionality for handling the functions of the RA70, or “invisibly” performable, e.g., by wrapping the network socket APIs of the application91with code that handles the functions of the RA70for appropriate socket operations, such as socket operations that allow the code of the application91to directly perform a functionality of the RA70.

The external client20of the network security system10in this example includes any type of computing device that can exchange network data, such as mobile, desktop, laptop, or tablet computing devices, virtual machines (including cloud-based computers), or the like. The external client20in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link (not illustrated), although other numbers or types of components could also be used.

The external client20may run interface applications, such as standard web browsers or standalone client applications, which may provide an interface to make requests for, and receive content stored on, the host80(e.g., the application91) via the communication network(s)30. The external client20may further include a display device, such as a display screen or touchscreen, or an input device, such as a keyboard for example (not illustrated).

The firewall40of the network security system10in this example monitors and controls incoming and outgoing network traffic based on predetermined security rules or a stored security policy. In this example, the firewall40allows only outgoing connections from the secure domain50(e.g., as initiated by the RA70as described and illustrated in more detail later). The firewall40in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link (not illustrated), although other numbers or types of components could also be used.

The host80of the network traffic management system10in this example includes processor(s), a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers or types of components could be used. The host80in this example can include an application server or IoT device, for example, that hosts application(s) including application91to which the external client20is attempting to communicate, although other types of host devices can also be used.

Accordingly, the application91may be operating on the host80and may be configured to transmit data (e.g., files or web pages) toward the external client20(e.g., via the secure domain50and RA70. The host80may be hardware or software or may represent a system with multiple servers in a pool, which may include internal or external networks.

Although the host80is illustrated as a single device, one or more actions of the host80may be distributed across one or more distinct network computing devices that together comprise the host80. Moreover, the host80is not limited to a particular configuration. Thus, the host80may contain network computing devices that operate using a master/slave approach, whereby one of the network computing devices of the host80operate to manage or otherwise coordinate operations of the other network computing devices. The host80may operate as a plurality of network computing devices within a cluster architecture, a peer-to peer architecture, virtual machines, or within a cloud architecture, for example.

Thus, the technology disclosed herein is not to be construed as being limited to a single environment and other configurations and architectures are also envisaged. For example, the host80can operate within the RA70itself rather than as a stand-alone server device communicating with the RA70via secure domain50. In this example, the host80operates within the memory26of the RA70.

Although the exemplary network security system10with the external client20, RG60, firewall40, RA70, host80, communication network(s)30, and secure domain50are described and illustrated herein, other types or numbers of systems, devices, components, or elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

One or more of the components depicted in the network security system10, such as the external client20, RG60, firewall40, RA70, or host80, for example, may be configured to operate as virtual instances on the same physical machine. In other words, one or more of the external client20, RG60, firewall40, RA70, or host80may operate on the same physical device rather than as separate devices communicating through communication network(s)30or secure domain50. Additionally, there may be more or fewer external clients, RGs, firewalls, RAs, or hosts than illustrated inFIG. 1.

The examples may also be embodied as one or more non-transitory computer readable media having instructions stored thereon, such as in the memory22or26, for one or more aspects of the present technology, as described and illustrated by way of the examples herein. The instructions in some examples include executable code that, when executed by one or more processors, such as the processor(s)12or24, cause the processors to carry out steps necessary to implement the methods of the examples of this technology that are described and illustrated herein.

Referring more specifically toFIG. 4, a flowchart of an exemplary method of facilitating secure access to services (e.g., application91) behind the firewall40with the RG60is illustrated. In step400in this example, the RG60of the network security system10receives a registration request from the RA70in the secure domain50. In this example, the RG70connects, authenticates, or registers the RA70and establishes a control connection with the RA70in response to the received request. The control connection can be initiated by the RA70, via the firewall40, for example, as described and illustrated in more detail later with reference to step500ofFIG. 5, although other methods of initiating or establishing the control connection can also be used in other examples.

In step402, the RG60intercepts a SYN from the external client20that identifies the application91in the secure domain50. In one example, the external client20supplies at least one of a special uniform resource identifier (URI) or a special uniform resource locater (URL) that uniquely identifies the application91to which the external client20wishes to connect. In another example, authentication information for the external client20that is sent to the RG60may enable the RG60to identify a set of firewalled applications (e.g., application91) with which the external client20is authorized to connect. In this example, the RG60can facilitate selection by the external client20of one of the firewalled applications (e.g., application91) from a menu or any other selectable feature provided by the RG, for example. Other methods of identifying the application91can also be used in other examples.

In step404, the RG60sends a notification of the SYN received from the external client20to the RA70. The notification includes an indication of the application91and can be sent via the control connection established in step400, for example, although other methods of sending the notification can also be used. Sending a SYN as part of a handshake to initiate a TCP connection would be considered an inbound connection request by the firewall40and would therefore be blocked. However, the notification of the SYN is not blocked by the firewall40in this example.

In step406, the RG60receives a SYN from the RA70as part of a TCP handshake to initiate a connection. Accordingly, the RA70sends the SYN via the firewall40to the RG60. Since the SYN is an outbound connection request, the firewall40does not block the SYN sent from the RA70in this example. In response to the notification in step404, the RA70also initiates a TCP connection with the application91, as described and illustrated in more detail later with reference toFIG. 5.

In step408, the RG60sends a SYN+ACK to the external client20in response to the SYN received from the external client20in step402. Accordingly, the RG60acknowledges the SYN received from the external client20in order to continue the handshake as part of establishing a TCP connection with the external client20.

In step410, the RG60sends a SYN+ACK to the RA70in response to the SYN received from the RA in step406. In this example, the RG60acknowledges the SYN received from the RA70in order to continue the handshake as part of establishing a TCP connection with the RA70. Accordingly, the RG60effectively negotiates a separate TCP connection with each of the external client20and the RA70.

In step412, the RG60receives an ACK from the external client20. Receipt of the ACK from the external client20completes the TCP handshake with the external client20and establishes the TCP connection with the external client20. Subsequent to completion of the TCP handshake, the RG60and client20can optionally initiate a TLS handshake to establish a secure connection between those devices.

In step414, the RG60notifies the RA70of receipt of the ACK from the external client in step412. Because the RG60established a TCP connection with the external client20, based on receipt of the ACK in step412, the RA70can confirm, based on the notification in step414, that the external client is authenticated and is authorized to access the application91.

Accordingly, in step416, the RG60receives an ACK from the RA70. The ACK from the RA70effectively completes the TCP connection between the RG60and the RA70. Subsequent to completion of the TCP handshake, the RG60and RA70can optionally initiate a TLS handshake to establish a secure connection between those devices. Subsequent to receiving the ACK from the RA70, the RG60optionally proceeds back to step402and intercepts a SYN from the external client20or a different client that is external to (i.e. on the other side of the firewall40from) the secure domain50. In other examples, one or more of steps402-416can be performed in a different order or in parallel.

Referring more specifically toFIG. 5, a flowchart of an exemplary method of facilitating secure access, to services (e.g., application91) behind the firewall40, with the RA70is illustrated. In step500in this example, the RA70of the network security system10sends a registration request to the RG60based on a pre-configuration that includes identifying information for the RG60or a discovery process, for example. In response to the registration request, the RG60authenticates the RA70, registers the RA70, or otherwise establishes a control connection with the RA70, as described and illustrated in more detail earlier with reference to step400ofFIG. 4.

In one example, the RA70can be configured to select the RG60from a plurality of RGs (not shown) through an L4 load balancer or a domain name system (DNS) (not shown) based on load balancing techniques, although other methods of selection can also be used. Facilitating RG selection introduces improved scalability and disaggregation of workload into the network security system10.

By way of example only, the RG selection can be based on a prearranged hash that the RA70is configured to use for selecting the RG70from a plurality of RGs. In this example, the prearranged hash can also be used to determine the desired RG (e.g., RG60) to which an initial access request from the external client20is to be redirected (e.g., by another RG). Using the prearranged hash is performable by applying at least one HTTP response code, for example, although other methods of using the prearranged hash or selecting the RG60can also be used in other examples.

In some examples, the RG60has a constant control connection with each of a plurality of RAs (not shown), including RA70, that the RG60supports, and the RAs are configured to transmit information relating to system health, system state, resource usage reports, or a list of applications behind each RA. The transmitted information facilitates determination, by the RG60, of the number and health state of the available population of applications and other capacity metrics for each application for which external access may be provided.

The control connection between the RG60and the RA70also permits implementation of a “simultaneous open” mechanism, wherein each device of two devices may open a connection to one another by issuing outgoing SYN, SYN+ACK, and ACK packets that simultaneously pass through a network. When such “simultaneous passage” is performed, a fully bidirectional connection is enabled between the two devices, and each device is effectively the simultaneous initiator of the TCP “simultaneous connection.”

The RG60can also be configured to force a meeting of the timing requirements for the TCP simultaneous connection via a feature of the RG60for sending control commands to the RA70and to control the timing and characteristics of the packets that the RA70sends between the external client20and the application91. Moreover, the RA70can provide any number of policy settings for security or networking parameters that are similar to, or the same as, that of the RG60for effecting the connection in some examples. At least some distribution of management and self-determination for these policy settings is optionally effected for the secure domain50.

In step502, the RA70receives a notification from the RG60that a SYN was received by the RG60from the external client20. The notification includes an indication of the application91and could have been sent by the RG60as described and illustrated in more detail earlier with reference to step404ofFIG. 4, for example. The notification can also be sent via the control connection established in step500and via the firewall40, for example. Additionally, the SYN could have been received by the RG60from the external client20as described and illustrated earlier with reference to step402ofFIG. 4.

In step504, the RA70sends a SYN to the application91in the secure domain50to initiate a TCP handshake with the application91. The application91was identified in the notification received in step502. The RA70effectively initiates a TCP connection with the application91on behalf of the RG60and external client20.

In step506, the RA70receives a SYN+ACK from the application506in response to the SYN sent to the application in step504. In this example, the RA70does not respond to the application91with an ACK until the RA70confirms that the RG60has authenticated the external client20and establishes a TCP connection with the external client20, as described and illustrated in more detail with reference to steps512-514.

In step508, the RA70sends a SYN to the RG60in response to the notification from the RG60received in step502. Accordingly, the RA70initiates a TCP handshake with the RG60that, from the perspective of the firewall40, is an outbound connection request with respect to the secure domain50, and is therefore permitted.

In step510, the RA70receives, and optionally drops, a SYN+ACK from the RG60. Although the RA70subsequently acknowledges the SYN+ACK so that the stateful firewall40perceives a completed handshake, the SYN+ACK does not need to be maintained by the RA70. The RG could have been sent by the RG60as described and illustrated in more detail earlier with reference to step410ofFIG. 4, for example.

In step512, the RA70receives a notification from the RG60that an ACK was received by the RG60from the external client20. Accordingly, the RG60confirms to the RA70that the external client20is authenticated and that a complete TCP connection has been established with the external client20. The notification could have been sent by the RG60as described and illustrated in more detail earlier with reference to step414ofFIG. 4.

In step514, the RA70sends an ACK to the application91and another ACK to the RG60. The ACK sent to the application91is in response to the SYN+ACK received from the application91in step506. Accordingly, the ACK completes the TCP handshake and establishes a TCP connection with the application91. The TCP connection with the application91is therefore not completed until the RA70confirms that the external client20has been authenticated by the RG60based on the notification received in step512. The ACK sent to the RG60completes the TCP handshake with the RG60from the perspective of the firewall40.

Subsequent to sending the ACKs to the application91and RG60, the RA70optionally proceeds back to step502an receives a notification from the RG60, or a different RG, that a SYN was received from the external client20or a different external client. In other examples, one or more of steps502-514can be performed in a different order or in parallel.

Referring more specifically toFIGS. 6-14, flow diagrams of an exemplary method for providing secure access to services (e.g., application91) behind the firewall40are illustrated. Referring more specifically toFIG. 6, the network security system10in which the RG60and the RA70are configured to communicate with one another through a trusted connection85is illustrated.

Secure access15to the firewalled application91, which can be an IoT service in a secure domain50within a home, for example, is provided to an authenticated external client20in this example. Optionally, a home gateway device90hosts the RA70as an application. The RA70securely authenticates with the RG60by announcing its presence and providing authentication credentials. Once trust is established, secure access to unmodified TCP-based IoT services that are residing within the secure domain.50can be provided to an authenticated external client20. Software for the authenticated external client20is also advantageously unmodified and no additional software is required for the authenticated external client20.

Referring more specifically toFIG. 7, the RA70performs at least one of connecting, authenticating, or registering with the RG60through a control connection101, e.g., in a first step. The RA70, running on the home gateway device90, registers with the RG60configured to provide a service to make home services, such as an application91, available to an authenticated external client20.

Referring more specifically toFIG. 8, the unsecure external client20transmits an HTTPS request, in a second step, that corresponds to a unique home IoT URL associated with the application91, to the RG60through a connection102. In this example, the HTTPS request includes a TLS server name indication (SNI).

Referring more specifically toFIG. 9, the RG60transmits a command or notification, indicating a SYN from the external client20, to the RA70via the control connection101in a third step. Additionally, the RA70generates a SYN, indicating the client SYN, to the application91via a connection103.

Referring more specifically toFIG. 10, the application91responds by transmitting a SYN+ACK to the RA70in a fourth step. The RA70then converts the SYN+ACK into a SYN and transmits the SYN to the RG60. The RG60and the firewall40advantageously perceive a “new” TCP connection based on the SYN from the RA70, and the connection is outbound from the secure domain50and therefore permitted by the firewall40.

Referring more specifically toFIG. 11, the RG60responds to the SYN sent by the RA70by transmitting a SYN+ACK to the RA70in a fifth step. The RA70drops the SYN+ACK in this example. However, the stateful firewall40perceives a complete TCP “handshake” and connection, subsequent to the RA70acknowledging the SYN+ACK in an eighth step.

Referring more specifically toFIG. 12, the RG60transmits a SYN+ACK to the unsecure external client20in a sixth step to acknowledge the SYN sent from the external client20in the second step (FIG. 8). The RG60can also authenticate a user of the external client20by performing an authentication, authorization, and accounting (AAA) process, for example, or any other type of authentication, prior to sending the SYN+ACK. If the external client20is not authenticated, then the SYN from the external client20is dropped and the process ends.

Otherwise, referring more specifically toFIG. 13, the unsecure external client20transmits an ACK to the RG60in a seventh step. The TCP connection opening handshake with the RG60is then completed. At this stage, the user of the external client20is now regarded as authenticated.

Referring more specifically toFIG. 14, the RG60then notifies the RA70, through the control connection101, of the ACK received from the external client20in an eighth step. The RA70then transmits an ACK back to the RG60, completing a connection and the RA70transmits another ACK to the application91, thereby completing a full connection wherein the authenticated external client20and the application91are enabled to communicate.

Once the foregoing complete data connections are established, the RG60transmits, by proxy, TCP segment data in both directions through the two complete data connections. Optionally, if establishment of the foregoing complete data connections is carefully performed, wherein both sides of the firewall40have the same maximum segment size (MSS), the RG may transmit, by proxy, the TCP segment data on a packet-by-packet basis with nearly zero buffering or zero state. With this optional feature, a TCP sequence number offset in either direction of each complete data connection, and a network address translation of the IP addresses and port numbers from one side of the RG60/RA70to the other side of the RG60/RA70, can be used in a manner performable by an L4 load balancer, for example.

In some examples, the TCP connection may be fully proxied, wherein the RG60terminates the TCP protocol on either side of the RG60/RA70and copies TCP segment data between the two data connections at the TCP protocol level, rather than the packet level. In these examples, a fully proxied TCP connection may be implemented if one side of the TCP connection is encrypted, the other side of the RG60/RA70is encrypted, both sides of the RG60/RA70are encrypted but using different keys, or the MSS is different on each side of the RG60/RA70.

Referring more specifically toFIG. 15, a timing diagram of an exemplary method for providing secure access to services (e.g., application91) behind the firewall40is illustrated. The step numbers indicated inFIG. 15correspond to those described and illustrated in more detail earlier with reference toFIGS. 7-14. Accordingly, in a first step, the RG60sends a “Hello” message in this example to the RA70to initiate establishment of a control connection, although other methods of establishing a control connection can also be used in other examples.

In a second step, the external client20initiates an HTTPS request (also referred to herein as a client SYN), which is intercepted by the RG60. The HTTPS request identifies the application91, such as in an SNI TLS extension, for example.

In a third step, the RG60sends a “SYN” or notification of receipt of the HTTPS request from the external client20. The RA70subsequently sends a SYN to the application91to initiate a TCP handshake and connection with the application91. In response, the application91sends a SYN+ACK.

In a fourth step, the RA70sends a SYN to the RG60based on the SYn+ACK from the application91. The SYN is sent by the RA70in order to initiate a TCP handshake from the perspective of a firewall disposed between the RG60and RA70(not shown inFIG. 15), which only allows connections that are outbound from a secure domain50in which the RA70and application91are disposed.

In a fifth step, the RG60sends a SYN+ACK to the RA70in response to the SYN sent by the RA70to the RG60in the fifth step. The SYN+ACK is sent via a firewall as part of a TCP handshake observed by the firewall for an allowed outbound connection.

Additionally, in a sixth step, the RG60sends a SYN+ACK to the external client20in response to the HTTPS request received by the RG60in the second step. Optionally, the RG60authenticates a user of the external client20prior to sending the SYN+ACK.

In a seventh step, the external client20sends an ACK to the RG60to complete the TCP connection with the RG60. The external client20is now considered authenticated.

Accordingly, in an eighth step, the RG60sends an “ACK” or notification to the RA70that the ACK was received from the external client20in the seventh step, which indicates to the RA70that the external client20was authenticated. Following receipt of the notification, the RA70sends an ACK to the application91to complete the TCP connection with the application91, as well as another ACK to the RG60to complete the TCP connection with the RG60from a perspective of the firewall disposed between the RG60and RA70.

Accordingly, as described and illustrated by way of the examples herein, the firewall40, protecting the secure domain50, perceives only an outgoing connection from the RA70to establish the control connection with the RG60, and an outgoing connection from the application91behind the firewalled secure domain50toward the RG60. The conditions that the firewall40typically enforces for providing security, e.g., only allowing an outgoing connection, are completely satisfied by the examples of this technology, notwithstanding that the external client20is effectively provided with a connection to a service (i.e., application91) residing behind the firewalled secure domain50.

Therefore, this technology advantageously allows clients external to a secure domain behind a firewall to access services or applications within the secure domain. By using an external RG to prompt an RA, which is internal to a secure domain and behind a firewall, to initiate a connection with the RG, this technology facilitates access to services within the secure domain by an external client while complying with security requirements of the firewall. Accordingly, this technology extends firewalls and facilitates improved scalability of firewalls. This technology also improves the security of services and applications in firewalled, secure domains, including those associated with IoT devices.