Method and readable medium for multi-ap micro-branch deployment configuration based on optimized packet forwarding

Abstract

Embodiments of the present disclosure relate to multi-AP micro-branch deployment configuration based on optimized packet forwarding. Systems and methods are provided for authenticating a client device in a micro-branch deployment. In response to the client device connecting to a LAN AP, a first client entry associated with the client device can be created to indicate that the client device is local to the LAN AP. An authentication request can be transmitted to a WAN AP to be forwarded to an authentication server. A second client entry associated with the client device at the WAN AP can be created based on the authentication request. Upon successful authentication, the second client entry can be designated as external to the WAN AP based on the first client entry being local to the LAN AP. Accordingly, data packets from the client device can be analyzed via a first firewall of the LAN AP while bypassing a second firewall of the WAN AP based on the external designation of the second client entry at the WAN AP.

Description

Technical Field

[0001] This disclosure relates to the field of networking, and more specifically, to a method and readable medium for configuring a multi-AP micro-branch deployment based on optimized packet forwarding. Background Technology

[0002] An access point (AP) provides configuration settings and accessibility for network devices to connect to a wired communication network. An AP can be a wired AP or a wireless AP, in which each network device can connect directly to the AP instead of using a wire to connect to an Internet Service Provider (ISP) to reach the wired communication network. Summary of the Invention

[0003] This disclosure provides a method for forwarding client services. The method includes, in response to a client device connecting to a local area network (LAN) access point (AP), wherein the LAN AP includes an authenticator for the client device, creating a first client entry associated with the client device for the LAN AP to indicate that the client device is local to the LAN AP. The method further includes transmitting an authentication request for authenticating the client device from the LAN AP to a wide area network (WAN AP) for forwarding to an authentication server, and creating a second client entry associated with the client device at the WAN AP based on the authentication request. The method further includes, when the client device is successfully authenticated at the authentication server, designating the second client entry as external to the WAN AP based on the first client entry being local to the LAN AP, and analyzing data packets from the client device via a first firewall of the LAN AP while simultaneously bypassing a second firewall of the WAN AP, the bypassing of the second firewall occurring based on the external designation of the second client entry at the WAN AP.

[0004] This disclosure provides a non-transient machine-readable medium encoded with instructions that, when executed, cause a processor to respond to a client device connecting to a LAN AP, wherein the LAN AP includes an authenticator for the client device, creating a first client entry associated with the client device for the LAN AP to indicate that the client device is local to the LAN AP, and transmitting an authentication request for authenticating the client device from the LAN AP to a WAN AP for forwarding to a RADIUS server. The processor also creates a second client entry associated with the client device at the WAN AP based on the authentication request, and, upon successful authentication of the client device at the RADIUS server, designates the second client entry as external to the WAN AP based on the fact that the first client entry is local to the LAN AP. The processor also analyzes data packets from the client device via a first firewall of the LAN AP while simultaneously bypassing a second firewall of the WAN AP, the bypassing of the second firewall occurring based on the external designation of the second client entry at the WAN AP. Attached Figure Description

[0005] This disclosure is described in detail with reference to the following figures, according to one or more various embodiments. The figures are provided for illustrative purposes only and depict only typical or exemplary embodiments.

[0006] Figure 1A An example system for implementing micro-branch deployment is shown.

[0007] Figure 1B Another example system implementing microbranch deployment is shown.

[0008] Figure 1C An example system for forwarding client services via LAN APs and WAN APs is shown.

[0009] Figure 1D An example system for forwarding client services via a WAN AP is shown.

[0010] Figure 2 An example system for passing client authentication entries via LAN AP and WAN AP is shown.

[0011] Figure 3 An example system is shown for passing client entries via WAN AP authentication.

[0012] Figure 4A A first example method is shown according to the embodiments described herein.

[0013] Figure 4B A second example method is shown based on the examples described in this article.

[0014] Figure 5 It is an example computing component that can be used to implement the various features of the examples described in this disclosure.

[0015] These figures are not exhaustive and do not limit this disclosure to the precise form of disclosure. Detailed Implementation

[0016] Multi-AP micro-branch deployment involves enabling APs at remote sites to be configured and managed by a cloud platform. In traditional systems, client devices connect to a LAN AP, which forwards data packets to the primary WAN AP. Software-defined WAN (SDWAN) allows network administrators to connect branch locations to the core site via a WAN. The use of SDN decouples network service decisions from various devices within the network, such as routers, switches, bridges, and other common network devices. This decoupling essentially turns each network device into a simple packet forwarding device. WAN APs can configure potential service paths for each network device based on client policies (e.g., QoS requirements, bandwidth, etc.) to connect branch locations within the WAN AP to the core site or data center (DC), which is provided to each network device via a control channel. When data is received, the network device does not make decisions about how to route the service; instead, it simply executes the route identified by the WAN administrator.

[0017] Traditional branch deployments support client connectivity requirements across different geographical locations for various types of business operations. Sites in remote locations serve as branch offices, while headquarters or main offices act as data centers (DCs) hosting network resources to store, manage, and distribute data. The main office also hosts a centralized Virtual Private Network (VPN) management system to aggregate business from remote branch sites. For micro-branch deployments, dedicated gateway devices are not required. Instead, a single gateway AP (WAN AP) can be used as a WAN-facing gateway. Additional APs can be added "below" the WAN AP to extend wireless coverage in micro-branch deployments. APs can involve network devices that allow wireless-compliant devices (such as client devices, stations (STAs), etc.) to connect to the wired network. Therefore, APs essentially act as an extension mechanism from the existing wired network to the community of wireless client devices. It should be understood that gateways typically involve APs with Network Address Translation (NAT) routing and Dynamic Host Control Protocol (DHCP) server capabilities.

[0018] In a micro-branch deployment, the WAN AP "owns" a public IP address, provides gateway / gateway-like functionality (e.g., DHCP, NAT, routing capabilities), and can further host VPN clients for providing secure connections to remote (e.g., the main organization) data center or other cloud services, depending on the micro-branch's needs. The configuration of the WAN AP and any additional APs in a micro-branch deployment typically differs because they each play a different role within the micro-branch deployment.

[0019] Once data packets are transmitted from the LAN AP to the WAN AP, client devices can receive access to the Internet or the data center. In a multi-AP micro-branch deployment, client traffic is forwarded through the WAN-facing AP. If a client device is connected to a LAN (non-WAN) AP, data packets will first pass through a firewall at the LAN AP before being transmitted to the WAN AP. At the WAN AP, client packets will pass through a firewall again before being routed to the Internet.

[0020] An example of this type of firewall can be seen in an Instant Access Point (IAP) cluster design. An IAP cluster design includes one or more member IAPs connected to the commanding IAP. Member IAPs include LAN APs or other subnets connected to the commanding IAP. The commanding IAP may include a primary WAN AP or other common network. Inbound firewall rules on the commanding IAP are created for each client device based on its IP subnet. For each client IP subnet, there can be multiple rules added to the inbound access control list (ACL). Here, the ACL relates to the firewall and security requirements that the client device must meet before granting access. Incoming client traffic from any member IAP in the cluster must be processed through the inbound ACL rules on the commanding IAP. Based on the implementation of the ACL rules, client packets can be routed to the Internet or tunneled to the DC. The problem with this approach is that the inbound ACLs are the same for all client devices connected to the member IAPs. The inbound ACLs are also the same for Internet traffic received from the commanding IAP's uplink port. Furthermore, when a new IP subnet or route is formed, the inbound ACL rules are automatically incremented. This is because the inbound ACL rules are updated based on the new IP subnet or route. Therefore, the ACL rule list can become cumbersome. Because inbound ACL rules automatically expand for each client subnet and route, the list of ACL rules can grow rapidly. From this point on, client packets or uplink packets received from member IAPs on slow paths can consume significant processing time on the commanding IAP. This is because the packet must navigate through a massive list of inbound ACL rules. Since there is no visibility for user roles on client devices connected to member IAPs, the same inbound ACL rules can apply to any service application coming from the commanding IAP's uplink port.

[0021] The results are as follows: In an IAP cluster, when a client device connects to a member IAP and sends a service, it is first passed through the firewall by the member IAP and then forwarded to the command IAP. When the client packet enters the command IAP, it is subject to inbound ACL (firewall) rules. The inbound ACL rules are then compared with the client service and used to select the destination (Internet or tunnel). Furthermore, if any routing changes are made in the system or if a new client subnet is added, the inbound ACL rules are reprogrammed and automatically expanded. The problem with this automatic expansion is that the command IAP may exhaust a fixed number of available ACL rule slots. Since every client packet (connected to a member IAP) and every packet received from the IAP's uplink runs through the inbound ACL list, it adds additional overhead to the command IAP and degrades its performance.

[0022] This disclosure addresses the dual firewall by logging user roles and allowing client devices to bypass application inbound ACL / firewall rules. By eliminating the dual firewall, processing time and business overhead can be reduced to optimize the performance of directing IAP. It should be noted that terms such as “optimized” and “optimal” as used herein can be used to mean making or achieving the most efficient or perfect performance possible. However, as will be recognized by one of ordinary skill in the art upon reading this document, perfection cannot always be achieved. Therefore, these terms can also encompass making or achieving the best possible or most efficient performance in a given situation, or making or achieving better performance than could be achieved with other settings or parameters.

[0023] The examples disclosed herein may include one or more LAN APs connected to the WAN AP before transmitting traffic to the Internet or a data center. The LAN AP can be designated as a client device authenticator. The WAN AP can be configured as a RADIUS agent that transmits authentication requests to a RADIUS server. Here, a RADIUS agent refers to a system that forwards requests to a RADIUS server based on predefined rules. The RADIUS server can authenticate the request using the RADIUS protocol. Once the client device is authenticated, the client device can be designated as external to the WAN AP, meaning that data packets originate from the LAN AP before being transmitted to the WAN AP. Alternatively, the client device can be designated as local to the LAN AP because it originates from the LAN AP. This designation can allow the client device to bypass a second firewall at the WAN AP.

[0024] If the client device originates from a WAN AP, the WAN AP may include a client device authenticator. The client device can be authenticated by a RADIUS server and designated as local to the WAN AP. This designation instructs the client device to still pass through ACL rules at the WAN AP. The WAN AP can bypass external designation and authenticate locally, so the client device only passes through the firewall once at either the LAN AP or the WAN AP. These designations apply to multiple LAN APs connected to the WAN AP. Because external designation is sufficient to indicate that the client device has been authenticated, the WAN AP does not need to distinguish which LAN AP the client device originated from.

[0025] One advantage of this configuration is the use and location of the WAN AP in network routing. In a typical configuration, the WAN AP might be connected at the edge of a branch. When client devices connect to the WAN AP, the WAN AP can handle subsequent routing based on its location within the branch. This can make the WAN AP a bottleneck for data packets due to the breadth of its ACL rules. The example described in this article allows all client services in the branch to bypass this bottleneck and simplify client device processing. Furthermore, unlike IAP cluster designs, the example reduces latency caused by processing a large number of unnecessary inbound ACL rule sets. If users have configured hundreds of available routes, the total number of ACL rules for all routes can be very large. Similarly, if hundreds of clients in the branch use different IP subnets, the total number of ACL rules can increase dramatically. Adding user visibility for each client device to the WAN AP helps limit the number of inbound ACL rules. Limiting these rules further reduces packet processing overhead on the IAP.

[0026] Before describing in detail embodiments of the disclosed systems and methods, it is useful to describe an example micro-branch deployment network, which the disclosed systems and methods can be used to implement in various applications. Figure 1A An example of a network 100 including micro-branch deployments is shown. In this example, network 100 may include a data center 102, a single AP micro-branch deployment 120, and a multi-AP micro-branch deployment 130 operationally connected to the corporate data center 102. Parts of network 100 also provide provisioning systems such as cloud-based zero-touch provisioning systems / services 114. As described above, WAN 112 allows various elements / entities of network 100 to interconnect.

[0027] As described above, data center 102 can represent the main organization of an enterprise. Data center 102 may include a controller or core switch 104, with a DHCP server 106 and a policy management platform 108 operatively connected to the controller or core switch 104. It should be understood that the functionality of element 104 may differ depending on how the connection between data center 102 and remote branches (micro-branches 120, 130 in this example) is implemented. Some virtual LANs may be Layer 3 routed, in which case the VPN concentrator can send traffic to the core switch, for example, the core switch 104, which may be a high-speed core switch. The core switch 104 can then route the packets of the flow to the necessary subsequent hops. Alternatively, in the context of a Layer 2 connected virtual LAN, the VPN concentrator can simply route GRE packets (described below) to the controller, in which case element 104 also functions as a controller.

[0028] As will be understood by those skilled in the art, DHCP server 106 may involve a network element that dynamically assigns IP addresses and other network parameters to each device on the network. Policy management platform 108 may be implemented to securely and correctly connect devices, such as client devices, to the network. For example, policy management platform 108 may provide access to new devices, grant different levels of access to the network, maintain network security, etc.

[0029] As in Figure 1A As further shown, data center 102 is connected to micro-branch 120 via overlay channel 116A. As described above, a VPN tunnel can be established between the sites, in which case data center 102 and micro-branch 120 create an SDWAN overlay network. Specifically, overlay channel 116A can connect the WAN AP 122 of micro-branch 120 to headend gateway 110, which can act as a VPN concentrator and overlay endpoint (using, for example, the Generic Routing Encapsulation (GRE) tunneling protocol) to terminate the VPN tunnel, thus providing routing from micro-branch 120 to data center 102. Similarly, micro-branch 130 (a multi-AP micro-branch including WAN AP 132 and leaf LAN APs 134A to 134C, compared to micro-branch 120) can be operationally connected to data center 102 via overlay channel 116B.

[0030] Micro-branch 120 is a single AP micro-branch where one or more client devices, such as client devices 124A through 124E, can be associated with an AP, for example, WAN AP 122 (wireless or via wired connection), to allow connectivity to data center 102. Micro-branch 130 is a multi-AP micro-branch where, in this example, multiple LAN APs 134A through 134C are operatively connected to WAN AP 132, through which connectivity to data center 102 can be established. Micro-branch 130 may include one or more client devices, such as client devices 138A through 138C, where each client device can be directly associated with either WAN AP 132 or one of the LAN APs 134A through 134C. In this example, micro-branch 130 may also include additional client devices, such as client devices 138D through 138E, connected to an unmanaged switch 136.

[0031] For reference Figure 1B Another micro-branch deployment 140 is shown, wherein micro-branch deployment 140 has a daisy-chain topology / hierarchy with respect to its APs. As mentioned above, in a micro-branch deployment such as micro-branch deployment 140, a dedicated gateway is not required. Instead, a WAN AP such as WAN AP 142 acts as a WAN-facing gateway, and in this example, it can be connected via Ethernet connection (Eth-0) through WAN port 141 of WAN AP 142. A first AP, LAN AP 144, can be operatively connected to WAN AP 142, and in turn, a second AP, LAN AP 146, can be operatively connected to LAN AP 144, i.e., LAN APs 144 and 146 are daisy-chained to WAN AP 142.

[0032] As in Figure 1BAs shown, two client devices 150a and 150b, such as laptops, telephones, printers, or other computing devices, can be wirelessly associated with WAN AP 142. In this example, WAN AP 142 can be configured to operate as multiple virtual APs (vAPs). As those skilled in the art will understand, a VAP emulates multiple APs on a single physical AP. Each VAP can have its own unique Service Set ID (SSID), thus segmenting the WLAN into multiple broadcast domains. Security can be customized / configured to control access by wireless client devices. In this example, when client device 150a connects to WAN AP 142, it can be assigned a specific user role. It should be understood that each client device in a network such as network 100 (Figure 1), to which micro-branch deployment 140 can be operationally connected, is associated with a user role. This user role determines the client device's network permissions, re-authentication frequency, applicable bandwidth contract, etc. In this example, client device 150a (from the perspective of WAN AP 142) is associated with user role, role A. The second client device associated with WAN AP 142, namely client device 150b, can have its own associated user role in the eyes of role B of WAN AP 142.

[0033] Relative to the LAN AP 144 in the micro-branch deployment 140, the client device 150c, which could be a laptop, telephone, other user / client device, etc., can be associated with the VAP (VAP-X) configured on the LAN AP 144. From the perspective of the LAN AP 144, the client device 150c can be associated with user role, role A. However, considering that the LAN AP 144 is connected to / under the WAN AP 142, from the perspective of the WAN AP 142, the client device 150c can be associated with user role, role D. It should be understood that user roles can be assigned in various ways based on network configuration. In some embodiments, the assigned user roles can involve static roles (in conjunction with ports), so that all client devices connected to the same port / VAP can be assigned the same user role. Alternatively, user roles can also be derived based on client device attributes (e.g., MAC address, connection port, etc.). Furthermore, it should be understood that user roles can involve policy containers, where different policies can typically be configured for different roles, although the same policy for different roles is possible. Typically, different user roles can be assigned to APs, wired client devices, and wireless client devices. In this case, another client device 150d can be associated with LAN AP 144 via Ethernet and can be assigned the user role, role D. Another client device 150e can be associated with the VAP (VAP-X) of LAN AP 146 and can be assigned its own user role, role A.

[0034] Given that LAN AP 146 is daisy-chained to WAN AP 142 via LAN AP 144, LAN AP 144 can also assign user roles to client device 150e, in this example, role D (similar to client device 216). Moving up the link to WAN AP 142, WAN AP 142 "sees" each client device associated with LAN APs 144 and 146, and can therefore assign a specific user role to each of those client devices, in this case, client device 150d (associated with LAN AP 144), role D. WAN AP 142 can also assign user roles to client device 150e (associated with LAN AP 146), i.e., role D. It is understood that, for example, firewall policy permissions may not necessarily be consistent across all APs (WAN AP 142, LAN AP 144, LAN AP 146). It should also be understood that LAN AP 146, LAN AP 144, and WAN AP 142 are connected via wired connections, such as Ethernet, and the respective user roles assigned to those client devices associated with the daisy-chained APs are served by the Eth-X server (which can serve its own connection, both wired client devices and any other wired / wireless clients served by the downlink APs). The VAP-X server typically only serves wireless client devices connected to the VAP port.

[0035] To address this traditional firewall inconsistency, network administrators can remove port ACL policies for wired (Eth-X) ports. For example, they could configure all wired ports to operate in trusted mode, or configure "allow everything" port ACLs to allow firewall processes to target those wired ports. However, while resolving firewall inconsistencies, configuring wired ports in this way can introduce potential security risks to the network. For instance, an attacker could connect client devices, such as laptops, to one of the wired ports in a daisy-chained access point (AP). Because the wired port operates in trusted mode, or allows bypassing firewall processes without performing client device authentication, the attacker would gain access to the micro-branch deployment network 140. This, in turn, allows the attacker to gain full network access to the main office network (e.g., Figure 1A Data center 110), and other branch networks, such as micro-branch networks 120, 130 ( Figure 1A ).

[0036] Another common mechanism to avoid firewall inconsistencies is chained authentication and role export, such as using RADIUS authentication. For example, when client device 150e connects to an AP, such as LAN AP 146, RADIUS authentication can be triggered immediately on the connected wireless SSID (VAP-X), and a user role, such as role A, can be exported. When packets from client device 150e arrive at the "upper-layer" AP (here, LAN AP 144), RADIUS authentication can be triggered again for the same client device (client device 150e) on the wired port (Eth-X) of LAN AP 144. Therefore, the same user role can be exported and applied to the wired port of LAN AP 144. When packets from client device 150e arrive at WAN AP 142, the same authentication and user role export can occur. While the firewall maintains consistency across APs (and WAN APs), this introduces redundant authentication transactions and generates additional streaming processing time.

[0037] Figure 1C An example system for authenticating client devices at a LAN AP is shown. Client device 160 can connect to one or more LAN APs for forwarding to the Internet. Client device 160 can include a laptop computer, smartphone, desktop computer, or any device capable of connecting to the Internet. Figure 1C The image shows a laptop 160a and a smartphone 160b. Figure 1C In the example, two client devices can connect to LAN AP 162. Laptop 160a can connect to LAN AP 162a, and smartphone 160b can connect to LAN AP 162b. Solid arrow paths indicate that the client devices are routed to the DC, while broken arrow paths indicate that the client devices are routed to the Internet.

[0038] Client device 160 can be authenticated at LAN AP 162. LAN AP 162 can implement any inbound ACL rules or any necessary firewall to authenticate client device 160. Once client device 160 is authenticated, LAN AP 162 can transmit data packets to WAN AP 164. In a traditional system, at WAN AP 164, data packets would pass through the firewall a second time before being forwarded. As mentioned above, WAN AP 164 can implement any and all inbound ACL rules. From WAN AP 164, data packets can be forwarded to the Internet (as indicated by the broken arrow) or to DC 166. DC 166 may include branch offices, headquarters, or main offices that host network resources to store, manage, and distribute data. The main office may also host a centralized VPN management system to aggregate business from remote branch sites. Data packets can be transmitted to DC 166 via the WAN's GRE or IPsec tunnel. Here, IPsec tunnel refers to the protocol used to establish a data channel between devices at the network layer. Figure 1C The path shown can flow from client device 160 to an endpoint (DC 166 or the Internet) in either direction as needed to facilitate communication.

[0039] Figure 1D It shows something similar to Figure 1C Another example system, differing in that client device 160 can connect directly to WAN AP 164 instead of through a LAN AP. Here, client device 160 can directly transmit data packets to WAN AP 164. WAN AP 164 can authenticate client device 160. As follows... Figure 3 As further shown, this functionality is maintained using a RADIUS server implementation. WAN AP 164 can forward authenticated data packets to the Internet or DC 166. (And...) Figure 1C Similarly, data packets can be forwarded to DC 166 via GRE or IPsec channels.

[0040] Figure 2An example workflow is illustrated in the examples described herein. Client device 200 can connect to LAN AP 202 and transmit data packets to LAN AP 202. These data packets can provide client device 200 with access to the Internet or a data center. LAN AP 202 can be designated as the client device authenticator because it is the first AP to which client device 200 connects. When connected to LAN AP 202, LAN AP 202 can create a dormant client entry 204 to identify the client. Client entry 204 can remain dormant until authentication at the RADIUS server is completed, after which client entry 204 can be activated. Client entry 204 can include any identifying information about client device 200 and / or its users. Client entry 204 can indicate situational data about client device 200, such as the network path taken by client device 200. Client entry 204 indicates that the data packets originated from LAN AP 202. This client entry can be designated as local to LAN AP 202, and therefore, can be designated as external to WAN AP 206.

[0041] LAN AP 202 can send a RADIUS request to WAN AP 206. Here, WAN AP 206 can be designated as a RADIUS agent. As described above, as a RADIUS agent, WAN AP 206 can transmit a RADIUS request to RADIUS server 208 for authentication. Once receiving a RADIUS request from LAN AP 202, WAN AP 206 can initiate a second corresponding client entry 210 for client device 200. The second corresponding client entry can also remain dormant, just like the first client entry. WAN AP 206 can transmit the RADIUS request to RADIUS server 208 or any authentication server. RADIUS server 208 can authenticate the RADIUS request and transmit a notification to WAN AP 206 that the RADIUS request has been accepted. WAN AP 206 can download the user role associated with the second client entry 210 and activate the client entry. The user role can include the corresponding authentication information of the client device and indicate the status 210 of the client entry. The user role can determine the client device's network permissions, re-authentication frequency, applicable bandwidth contract, etc. As described above, in some embodiments, the assigned user roles can involve static roles (combined with ports), so that all client devices connected to the same port / VAP can be assigned the same user role. Alternatively, user roles can be derived based on client device attributes such as MAC address, connection port, etc. User roles can involve policy containers, where different policies can typically be configured for different roles, although it is possible to configure the same policy for different user roles.

[0042] Based on the accepted RADIUS request, the active client entry can be marked as external to WAN AP 206. As mentioned above, external designation indicates that the client device does not need to pass through the firewall again at WAN AP 206. RADIUS acceptance can then be further transmitted back to LAN AP 202. At LAN AP 202, the user role associated with the first client entry can be downloaded, and the first client entry can be activated. Similar to the second client entry, downloading the user role can indicate the status of the client entry and the progress of authenticating the client device. Therefore, after authentication, both the first and second client entries for the client device can be activated to grant access to client device 200. The use of the RADIUS server allows the client device to authenticate only once. Because the client entry at WAN AP 206 is active and designated as external, client device 200 will not need to pass through the firewall at WAN AP 206. Client device 200 can bypass WAN AP 206 and forward data packets to the Internet or to the DC, as in Figure 1A As described above, bypassing WAN AP 206 can include skipping firewall rules or quickly forwarding packets forwarded by the client.

[0043] Figure 3 Another example workflow is shown, where the client device first connects to the WAN AP. Figure 3 In this process, client device 300 can transmit data to WAN AP 302. (And...) Figure 2 In contrast to the workflow described above, WAN AP 302 can act as a client device authenticator. As mentioned above, WAN AP 302 can transmit RADIUS requests to RADIUS server 304 for authentication. WAN AP 302 can also create dormant client entries 306. RADIUS server 304 can authenticate the RADIUS request and transmit the received data to WAN AP 302. (This is in contrast to the workflow described above.) Figure 2 Similar to the system described above, WAN AP 302 can download user roles for dormant client entry 306 and activate the client entry. However, dormant client entry 306 can be designated as local to WAN AP 302. This designation indicates that the client device initially connected to WAN AP 302 and had not been previously authenticated. The local designation indicates that WAN AP 302 should not bypass data packets. WAN AP 302 can apply ACL rules or corresponding firewall policies to authenticate the client device. Therefore, client device 300 can use a one-round authentication at WAN AP 302 to connect to the Internet or DC.

[0044] Various combinations of one or more LAN APs and WAN APs can be used to implement... Figure 2 and Figure 3 The system described herein. Each LAN AP and WAN AP can identify local and external traffic and thus apply firewalls. For example, a WAN AP can receive data packets from multiple client devices. A client entry associated with each client device can indicate whether the client device is local or external. The WAN AP can distinguish which packets have been authenticated and bypass some or all of the data packets. The WAN AP will then apply appropriate firewall rules to the remaining data packets that have not yet been authenticated, i.e., at the previous LAN AP. Thus, each client device can be authenticated once, regardless of where its connection originated. Furthermore, data packets can pass through multiple LAN APs before reaching the WAN AP. Corresponding client entries can be created at each AP to indicate whether the client device is local or external to that particular AP. External traffic can be quickly forwarded to subsequent LAN APs because the client device was previously authenticated at the first LAN AP. Ultimately, the first device to which a client device connects may include a client device authenticator. Subsequent APs or devices may include RADIUS agents to transmit RADIUS requests to a RADIUS server for authentication.

[0045] Figure 4A Example computing components that can be used to authenticate client devices are shown according to various embodiments. Reference is now made to... Figure 4A For example, computing component 400 can be a server computer, a controller, or any other similar computing component capable of processing data. Figure 4A In the example implementation, computing component 400 includes hardware processor 402 and machine-readable storage medium 404.

[0046] Hardware processor 402 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 404. Hardware processor 402 may fetch, decode, and execute instructions, such as instructions 406 through 414, to control processes or operations for authenticating client entries. As an alternative or addition to retrieving and executing instructions, hardware processor 402 may include one or more electronic circuits comprising electronic components for the function of executing one or more instructions, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits.

[0047] Machine-readable storage media such as machine-readable storage medium 404 can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, for example, machine-readable storage medium 404 can be random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some embodiments, machine-readable storage medium 404 can be a non-transient storage medium, wherein the term "non-transient" excludes transient propagation signals. As described in detail below, machine-readable storage medium 404 can be encoded with executable instructions, such as instructions 406 to 414.

[0048] Hardware processor 402 can execute instructions 406 to create a first client entry associated with the client device for the LAN AP in response to a client device connected to the LAN AP. The LAN AP may include a client device authenticator as described above (e.g., in...). Figure 2 (In Chinese). As mentioned above, a LAN AP can create dormant client entries to identify clients. These client entries can be activated when an authentication request is accepted at the authentication server. Client entries can include any identifying information about the client device and / or its user. Dormant client entries can indicate that data packets originated from the LAN AP. This client entry can be specified as being local to the LAN AP.

[0049] Hardware processor 402 can execute instruction 408 to transmit an authentication request to the WAN AP for forwarding to the authentication server. As described above, the authentication request may include a RADIUS request with the RADIUS protocol. The authentication server may be a RADIUS server capable of authenticating client devices based on this request. The authentication server can be any authentication server with any protocol set to authenticate client devices. The WAN AP can be configured as a RADIUS agent to transmit authentication requests to the RADIUS server. Any subsequent AP after the client device authenticator may include a RADIUS agent to transmit RADIUS requests to the RADIUS server.

[0050] Hardware processor 402 can execute instructions 410 to create a second client entry associated with the client device at the WAN AP based on an authentication request. As described above, this client entry may include a second corresponding client entry for the client device. This client entry may also be dormant before authentication occurs at the authentication server. The second client entry may indicate the relationship between the client device and the WAN AP.

[0051] Hardware processor 402 can execute instruction 412 to designate the second client entry as external to the AN AP when the client device is successfully authenticated. As described above, the authentication server can authenticate the authentication / RADIUS request and transmit a notification to the WAN AP that the request has been accepted. The WAN AP can download the user role associated with the second client entry and activate the client entry. Based on the accepted authentication request, the active client entry can be marked as external to the WAN AP. Furthermore, acceptance can be further transmitted back to the first LAN AP. At the first LAN AP, the user role associated with the first client entry can be downloaded, and the client entry can be activated. Because the client entry is active and designated as external at the WAN AP, the client device will not need to pass through a firewall at the WAN AP.

[0052] Hardware processor 402 can execute instructions 414 to analyze data packets from client devices via a first firewall of the LAN AP while bypassing a second firewall of the WAN AP. This bypass of the second firewall can occur based on external specification of a second client entry at the WAN AP. As described above, the client device can bypass the WAN AP and forward data packets to the Internet or to the DC, as illustrated above in Figure 1. As described above, bypassing the WAN AP 206 can include skipping firewall rules or quickly forwarding data packets forwarded by the client.

[0053] Figure 4B A computing component 400 is shown executing instructions 416 to 422 to authenticate a client entry at the WAN AP. Hardware processor 402 can execute instruction 416 to create a client entry associated with the client device for the WAN AP in response to a client device connecting to the WAN AP. Here, the WAN AP may include a client device authenticator, as in... Figure 3 As shown in the diagram. As mentioned above, the WAN AP can create dormant client entries to identify client devices. Dormant client entries can indicate that data packets originated from the WAN AP.

[0054] Hardware processor 402 can execute instruction 418 to transmit an authentication request from the WAN AP to the authentication server for client authentication. The WAN AP can act as a client device authenticator, generating the authentication request and transmitting it directly to the authentication server, instead of... Figure 4A As described in the document, the request is forwarded to the authentication server.

[0055] When a client device is successfully authenticated, the hardware processor 402 can execute instruction 420 to designate the client entry as local to the WAN AP. As described above, the authentication server can authenticate the authentication request and transmit acceptance to the WAN AP. The WAN AP can download the user role for the dormant client entry and activate the client entry. Designating it as local indicates that the client device initially connected to the WAN AP and had not been previously authenticated. Local designation can also instruct the WAN AP not to bypass data packets. The WAN AP can apply the appropriate firewall policy or ACL rule to authenticate the client device.

[0056] Hardware processor 402 can execute instructions 422 to analyze data packets from client devices via the WAN AP's firewall, based on the local designation of client entries at the WAN AP. As described above, client devices can authenticate once before forwarding to the Internet or DC. The WAN AP can apply firewall rules to client devices designated as local while bypassing those designated as external. The WAN AP can maintain tracking of client traffic using the corresponding user roles of active client entries. Therefore, regardless of where the client device initially connects, the WAN AP can facilitate one round of authentication for successful data packet forwarding.

[0057] Figure 5 A block diagram of an example computer system 500 is described, in which various embodiments of the embodiments described herein may be implemented. The computer system 500 includes a bus 502 or other communication mechanism for communicating information, and one or more hardware processors 504 are coupled to the bus 502 for processing information. For example, the hardware processors 504 may be one or more general-purpose microprocessors.

[0058] Computer system 500 also includes main memory 506, such as random access memory (RAM), cache, and / or other dynamic storage devices coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. When such instructions are stored in storage media accessible to processor 504, computer system 500 becomes a special-purpose machine customized to perform operations specific to the instructions.

[0059] Computer system 500 also includes read-only memory (ROM) 508 or a static storage device coupled to a bus 502 for storing static information and instructions for processor 504. Storage device 510, such as a disk, optical disk, or USB flash drive (flash drive), is provided and coupled to bus 502 for storing information and instructions.

[0060] Computer system 500 may be coupled to display 512, such as a liquid crystal display (LCD) (or touchscreen), via bus 502 for displaying information to a computer user. Input device 514, including alphanumeric and other keys, is coupled to bus 502 for communicating information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, trackball, or arrow keys, for communicating directional information and command selections to processor 504 and for controlling cursor movement on display 512. In some embodiments, the same directional information and command selections as cursor control may be implemented via receiving touch on a touchscreen without a cursor.

[0061] The computing system 500 may include a user interface module to implement a GUI that can be stored in a mass storage device as executable software code executed by (multiple) computing devices. By way of example, this and other modules may include components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, program code fragments, drivers, firmware, microcode, circuit devices, data, databases, data structures, tables, arrays, and variables.

[0062] Generally, terms such as “component,” “engine,” “system,” “database,” and “data storage” as used herein can refer to logic contained in hardware or firmware, or to a set of software instructions written in programming languages ​​such as Java, C, or C++ that may have entries and exit points. Software components can be compiled and linked into executable programs that are installed in dynamic link libraries or can be written in interpreted programming languages ​​such as BASIC, Perl, or Python. It will be understood that software components can be called from other components or from themselves, and / or can be called in response to detected events or interrupts. Software components configured for execution on a computing device can be provided on computer-readable media, such as optical discs, digital video discs, flash drives, magnetic disks, or any other tangible media, or as digital downloads (and can be stored raw in a compressed or installable format that requires installation, decompression, or decryption). This software code can be stored, in part or in whole, on a memory device executing the computing device for execution by the computing device. Software instructions can be embedded in firmware, such as EPROM. It will be further understood that hardware components can consist of connected logic units, such as gates and flip-flops, and / or can consist of programmable units, such as programmable gate arrays or processors.

[0063] Computer system 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in conjunction with the computer system, enables or programs the computer system 500 into a special-purpose machine. According to one embodiment, the techniques herein are executed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as storage device 510. Execution of the sequence of instructions contained in main memory 506 causes processor(s)504 to perform the processing steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0064] As used herein, the term "non-transient medium" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-transient media can include non-volatile media and / or volatile media. For example, non-volatile media include optical discs or magnetic disks, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. Common forms of non-transient media include floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs, and EPROMs, flash EPROMs, NVRAMs, any other memory chips or magnetic tape, and the same network versions.

[0065] Non-transient media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transient media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the conductors that make up bus 502. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0066] Computer system 500 also includes a communication interface 518 coupled to bus 502. Network interface 518 provides bidirectional data communication coupled to one or more network links connected to one or more local networks. For example, communication interface 518 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, network interface 518 may be a Local Area Network (LAN) card providing data communication connectivity to a LAN-compatible network (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, network interface 518 transmits and receives electronic, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0067] Network links typically provide data communication to other data devices over one or more networks. For example, a network link can provide connectivity over a local network to a host computer or data device operated by an Internet Service Provider (ISP). The ISP, in turn, provides data communication services through a global packet data communication network now commonly referred to as the "Internet." Both local area networks (LANs) and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. Examples of transmission media include signals over various networks and on network links, as well as through communication interfaces 518 that carry digital data to and from computer system 500.

[0068] Computer system 500 can send messages and receive data, including program code, through multiple networks, network links, and communication interface 518. In the Internet example, the server can transmit request code for the application through the Internet, ISP, local network, and communication interface 518.

[0069] The received code may be executed by processor 504 upon receipt and / or stored in storage device 510, or in other non-volatile storage for later execution.

[0070] Each of the processes, methods, and algorithms described in the preceding sections can be embodied in code components executed by one or more computer systems or computer processors, including computer hardware, and can be fully or partially automated by these code components. One or more computer systems or computer processors can also operate to support performance in “cloud computing” environments or related operations such as “Software as a Service” (SaaS). Processes and algorithms can be implemented partially or wholly in application-specific circuitry. The various features and processes described above can be used independently of each other or combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are not limited to any particular sequence, and associated blocks or states can be executed in other suitable sequences, or can be executed in parallel, or in some other way. Blocks or states can be added to or removed from the disclosed example embodiments. The performance of certain operations or processes can be distributed across computer systems or computer processors, residing not only within a single machine but also deployed across multiple machines.

[0071] As used herein, the circuit can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be implemented to form the circuit. In implementation, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be shared partially or wholly in one or more circuits. Even if the various features or elements of a function can be described or declared separately as independent circuits, these features and functions can be shared in one or more common circuits, and such description does not require or imply the need for a separate circuit to implement such features or functions. Where the circuit is implemented wholly or partially using software, such software can be implemented to operate a computing or processing system capable of performing the functions described herein, such as computer system 500.

[0072] As used herein, the term “or” can be interpreted in an inclusive or exclusive sense. Furthermore, descriptions of resources, operations, or structures in the singular should not be interpreted to exclude the plural form. Conditional language, such as “may,” “can,” “may,” or “possibly,” unless otherwise specifically stated or understood within the context in which they are used, is generally intended to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not.

[0073] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations thereof, should be interpreted as open-ended rather than restrictive. Adjectives such as “regular,” “traditional,” “normal,” “standard,” “known,” and similar terms should not be construed as limiting the items to those available at a given time or within a given timeframe, but should be interpreted to include regular, traditional, normal, or standard techniques that may be available or known now or in the future. In some cases, the appearance of extended words and phrases such as “one or more,” “at least,” “but not limited to,” or other similar phrases should not be interpreted as implying that a narrower instance is intended or required where such extended phrases may not be available.

Claims

1. A method for forwarding client services, comprising: In response to a client device connecting to a local area network (LAN) access point (AP), wherein the LAN AP includes an authenticator for the client device, a first client entry is created associated with the client device for the LAN AP to indicate that the client device is local to the LAN AP; The authentication request used to authenticate the client device is transmitted from the LAN AP to the WAN AP, so that it can be forwarded to the authentication server; Based on the authentication request, a second client entry associated with the client device is created at the WAN AP; When the client device is successfully authenticated at the authentication server, the second client entry is designated as external to the WAN AP, based on the fact that the first client entry is local to the LAN AP. as well as Data packets from the client device are analyzed via the first firewall of the LAN AP, while simultaneously bypassing the second firewall of the WAN AP, the bypass of the second firewall occurring based on the external specification of the second client entry at the WAN AP.

2. The method according to claim 1, wherein the authentication server includes a Remote Authentication Dial-up User Service (RADIUS) server.

3. The method of claim 2, wherein the WAN AP includes a RADIUS agent.

4. The method according to claim 1, further comprising: Specify the first client entry as local to the LANAP.

5. The method according to claim 1, further comprising: Download the first user role associated with the second client entry and activate the second client entry when the client device is successfully authenticated.

6. The method according to claim 5, further comprising: Download the second user role associated with the first client entry and activate the first client entry when the second client entry is activated.

7. The method according to claim 1, further comprising: In response to a second client device connecting to a second LAN AP, the second client device is authenticated at the authentication server; Specify the client entry for the second client device as external to the WAN AP; as well as Data packets from the second client device are analyzed via the third firewall of the second LAN AP, while the second firewall of the WAN AP is bypassed.

8. The method of claim 7, wherein if the additional client device is authenticated by the LAN AP, additional data packets from the additional client device bypass the second firewall of the WAN AP.

9. A non-transient machine-readable medium encoded with instructions that, when executed, cause a processor to: In response to a client device connecting to a LAN AP, wherein the LAN AP includes an authenticator for the client device, a first client entry is created associated with the client device for the LAN AP to indicate that the client device is local to the LAN AP; The authentication request used to authenticate the client device is transmitted from the LAN AP to the WAN AP, so that it can be forwarded to the RADIUS server; Based on the authentication request, a second client entry associated with the client device is created at the WAN AP; When the client device is successfully authenticated at the RADIUS server, the second client entry is designated as external to the WAN AP, based on the fact that the first client entry is local to the LAN AP. as well as Data packets from the client device are analyzed via the first firewall of the LAN AP, while simultaneously bypassing the second firewall of the WAN AP, the bypass of the second firewall occurring based on the external specification of the second client entry at the WAN AP.

10. The non-transient machine-readable medium of claim 9, wherein the WAN AP includes a RADIUS agent.

11. The non-transient machine-readable medium of claim 9, wherein the instructions further cause the processor to: designate the first client entry as local to the LAN AP.

12. The non-transient machine-readable medium of claim 9, wherein the instructions further cause the processor to: download a first user role associated with the second client entry and activate the second client entry when the client device is successfully authenticated.

13. The non-transient machine-readable medium of claim 12, wherein the instructions further cause the processor to: download a second user role associated with the first client entry and activate the first client entry when the second client entry is activated.

14. The non-transient machine-readable medium of claim 9, wherein the instructions further cause the processor to: In response to the second client device connecting to the second LAN AP, the second client device is authenticated at the RADIUS server; Specify the client entry for the second client device as external to the WAN AP; as well as Data packets from the second client device are analyzed via the third firewall of the second LAN AP, while the second firewall of the WAN AP is bypassed.

15. The non-transient machine-readable medium of claim 14, wherein additional data packets from the additional client device bypass the second firewall of the WAN AP if the additional client device is authenticated by the LAN AP.

Images