Private Network Access Control Using Grants

This application is related to and claims priority to U.S. Provisional Patent Application 63/726,862, titled “PRIVATE NETWORK ACCESS CONTROL USING GRANTS,” filed December 2, 2024, and which is hereby incorporated by reference in its entirety.

Modern enterprises increasingly depend on private networking technologies to secure communications between distributed systems. These networks often span multiple environments—such as on-premises infrastructure, cloud platforms, and remote endpoints—and must maintain confidentiality and integrity across potentially untrusted underlying transport layers. To achieve this, organizations commonly implement identity-based access controls and encrypted tunnels, ensuring that only authenticated nodes can exchange data within the private network.

While authentication establishes trust at the point of entry, ongoing communication between nodes introduces additional considerations. Nodes may need to interact with specific services or applications hosted within the network, and these interactions often require granular authorization beyond simple network connectivity. Conventional approaches to enforcing such policies typically rely on static configurations or centralized rule sets, which can become cumbersome in dynamic environments where devices, users, and workloads frequently change. These complexities can influence how permissions are defined, distributed, and enforced across diverse layers of the network stack.

The technology disclosed herein enables grant-based control of communication traffic over a private network. In a particular example, a method includes receiving a grant at a destination node of the nodes from a policy engine for the private network. The grant indicates a list of sources and a list of destinations sources in the list of sources are allowed to access. The method further includes caching the grant in a cache at the destination node. Additionally, the method includes receiving one or more packets over the private network from a source node. The one or more packets are directed towards an application executing on the destination node. In response to accessing the grant from the cache to determine the source node is in the list of sources and the destination node is in the list of destinations, the method provides passing the one or more packets to the application.

In another example, another method includes retrieving definitions for access grants. The access grants provide permissions allowing nodes of the private network to communicate with others of the nodes specified by the access grants. The method also includes providing the access grants to the nodes and, in the nodes, allowing communication exchanges over the private network between the nodes when permitted by the access grants.

In a further example, an apparatus is provided having a one or more computer readable storage media and a processing system operatively coupled with the one or more computer readable storage media. Program instructions stored on the one or more computer readable storage media, when read and executed by the processing system, direct the apparatus to execute a client for communicating over the private network and receive access grants from a coordination service of the private network. The access grants define allowed characteristics of communications permitted over the private network. The program instructions also direct the apparatus to identify private-network traffic, allow a first portion of the private-network traffic having first characteristics of the allowed characteristics, and deny a second portion of the private-network traffic having second characteristics absent from the first characteristics.

A private overlay network is a network built on top of an existing physical network infrastructure (e.g., network interfaces, routers, switches, links, etc.), but with a virtual layer that creates a private and secure communication environment between devices. In an overlay network, connected devices (often referred to as nodes of the private network) can communicate as if they were on a dedicated, isolated physical network, even though they are using a public or shared underlying network. This may be achieved through software-defined networking (SDN) and protocols that allow for greater flexibility, security, and control over the communication traffic that flows between the nodes. Overlay networks are commonly used in virtual private networks (VPNs), distributed systems, and cloud environments to segment traffic, ensuring privacy and performance despite the underlying network's potential vulnerabilities.

Packet encapsulation is a key feature enabling a private overlay network. When data is sent from one node to another within the overlay, the original data packet (often called the payload) is “wrapped” within another, outer packet. This outer packet is constructed according to the rules of the overlay network's protocol, allowing it to be transmitted securely across the public network or the physical infrastructure. For instance, the original data packet may include a header directing the packet to a network address of a device on the private network. Encapsulating the original packet may encrypt the original packet using keys known only to nodes on the private network and then adding a new packet header directing the encrypted data to a public network address for the device. The encapsulation serves two purposes: it provides a secure tunnel for the data, ensuring that the packet can travel without being intercepted or altered by unauthorized entities, and it abstracts the details of the underlying physical network, enabling the overlay network to operate independently of it. Once the packet reaches the destination node, the encapsulation is removed (e.g., the encapsulated packet header is removed and the data is decrypted), and the original payload is processed.

To ensure secure communication and prevent unauthorized access, devices joining the private overlay network must authenticate themselves as valid nodes. This authentication process typically involves using cryptographic techniques, such as digital certificates or pre-shared keys, to verify the identity of each node before it can participate in the overlay. In some cases, a public key infrastructure (PKI) may be used, where each node has a unique cryptographic key pair (public and private keys) to prove its identity to other nodes on the network. In some examples, an Identity Provider (IDP) may be responsible for validating user identities and providing the necessary credentials or tokens for users to access protected systems and services. Once authenticated, nodes can encapsulate and exchange data packets for the private network.

The nodes described herein leverage the authentication already provided by the private network to regulate the nodes’ ability to access resources over the private network. The resources may include access to other nodes, access to applications or services on those nodes, or some other type of network accessible computing resource. A destination node can determine the identity of a source node for received packets based on the source nodes authentication to the private network (e.g., the source node may be associated with a particular user that was authenticated by the private network). The destination node can then determine whether the source node is allowed to send packets to the destination node and/or is allowed to access a resource on the destination node. In this case, a policy engine distributes grants to the nodes defining the access afforded to certain nodes. A node can refer to the grants to determine whether packet traffic is allowed. Neither the node nor a resource thereon need perform any additional authentication to determine whether access is allowed.

1 FIGS. 100 100 101 102 103 104 106 101 105 105 105 105 105 106 106 illustrates implementationfor using grants to control access on a private network. Implementationincludes policy engine, source node, destination node, nodes, and communication network. Policy engineand nodes 102-104 communicate with each other over private network. Private networkis a private network, such as a Virtual Private Network (VPN) or a physical private network, that uses an authentication mechanism, such as an IDP, to ensure computing devices connected to private networkare authorized to join private network. Private networkis an overlay network on physical networking hardware, such wired/wireless communication links, routers, switches, firewalls, computing devices, or other type of components for providing network communications between computing systems. In some examples, at least a portion of the physical networking hardware is included in, or underlies a portion of, communication network. Communication networkmay include one or more local area networks, wide area networks (e.g., the Internet), or some other type of network.

105 105 105 101 105 105 105 105 105 105 105 105 105 101 105 105 101 105 In operation, users of computing devices (e.g., personal computers, laptops, smartphones, tablets, servers, virtual machines, or other type of computing devices – including combinations thereof) authenticate themselves to private networkenabling the computing devices to connect to private networkas nodes 102-104 and exchange communications with each other over private network. Policy enginemay be a dedicated computing system, or virtualized computing system, or may be a component of another computing system, such as a coordination system for private network. Private networkmay leverage an external system, such as an IDP, to authenticate users, may use an internal authentication mechanism, or may use some other mechanism for ensuring a computing device is associated with a user authorized to access private network. Devices of users that are unable to authenticate themselves to private network(or are otherwise not allowed to access private network) are not allowed to join private networkas nodes to private network. While shown within private network, is part of the control plane for private network. Thus, policy engineis not necessarily executing on a node connected to private network. In some examples, the control plane of private networkmay be implemented by a coordination service that includes policy engine. The coordination service may function as the control plane for multiple private networks, including private network.

105 103 104 In cases where private networkis a VPN, an overlay network is achieved through a process called encapsulation, where the data packets sent between devices are wrapped inside additional packets that include encrypted information. For instance, when a VPN endpoint device (e.g., device of nodes-) sends data through a VPN, a packet carrying the data is encrypted and then encapsulated with a new packet header that includes a public IP address of another VPN endpoint device as the destination. This encapsulated packet is then sent over a public network to the destination VPN endpoint device.

At the destination VPN endpoint device, the outer packet header is stripped away to reveal the original encrypted packet. The original packet is then decrypted, allowing the data to be processed by the device. In some examples, the VPN endpoint device may be a VPN server operating as a gateway to the public network. In those examples, the decrypted original packet may be transmitted to a destination IP address on the public network identified in a header of the original packet. The above encryption method ensures that the data remains confidential and secure as it travels over potentially insecure networks, as only the VPN destination endpoint can decrypt and access the original information. By creating a secure tunnel through encryption and encapsulation, VPNs effectively simulate a private network over a public infrastructure, providing privacy and security for users. As such, a communication received by a node over the VPN can be trusted to have been sent by another node authorized to access the VPN.

102 104 105 132 103 102 104 105 105 105 105 In this example, nodes-execute clients thereon to handle communications over private network. Private network clientis the instance of the clients executing on destination node. The clients may handle an authentication process for authenticating each of nodes-to connect to private network, encryption and encapsulation of packets for transmission over private network, decryption and decapsulation of packets received over private network, and may perform some other action for connecting to and communicating over private network.

105 101 101 105 105 Private networkuses grants distributed by policy engineto perform access control with resources therein. Grants allow users or groups to be assigned specific permissions to access particular resources or networks. These permissions can be created and managed through an administrative interface into policy engineor automated using an Application Programming Interface (API) for private network. User grants may assign permissions to individual users and group grants may apply to user groups, making it easier to manage access for multiple people at once. Grants may work in conjunction with Access Control Lists (ACLs), which define specific access policies, ensuring that only authorized users or groups can access certain devices or subnets. Grants can be revoked at any time, allowing administrators to easily remove access when necessary. Advantageously, the syntax used to define a grant is shared between network layer and application layer capabilities. Each grant only requires a source and a destination, at least for network layer access. Private networkuses a deny-by-default approach enabling each grant to have an implied accept action. Other private networks may use different approaches requiring additional information in the grant. A grant may further include a listing of applications (or other resources) that are also allowed for the source and destinations listed therein, which enables a grant to apply at the application layer.

2 FIG. 200 200 103 102 103 102 104 105 200 103 101 201 105 105 105 103 202 132 103 103 illustrates operationthat uses grants to control access on a private network. Operationis described from the perspective of destination node. Source nodeand destination nodeare referred to as such due to being the source and destination of packets in this example. Any of nodes-may be a source and destination of packets exchanged over private network. In operation, destination nodereceives a grant from policy engine(step). The grant may be drafted by a user, such as an administrator of private network, or may be autogenerated in the syntax used for grants by private networkto implement a policy for private network. The grant may be received individually or may be received along with one or more other grants. Upon receipt, destination nodecaches the grant locally thereat (step). In this example, private network clienthandles the receipt and caching of the grant at destination nodebut another component executing on destination nodemay handle the steps in other examples.

103 102 203 132 105 103 132 103 204 105 105 132 132 205 132 131 206 After receiving and caching the grant, one or more packets are received at destination nodefrom source node(step). Since private network clienthandles the communications exchanged over private networkfor destination node, private network clientprocesses the received packets to determine whether the grant cached at destination nodeapplies to the packets (step). The grant at least lists one or more sources and one or more destinations allowed for packets but may also list one or more ports and/or one or more protocols that are allowed to be used between the identified sources and destinations. The sources and destinations may be identified in the grant using device identifiers (e.g., network addresses) for nodes or some other type of identifier, such as a user or group of users associated with a node. For instance, “User A” may be identified as a source in the grant. All nodes associated with User A (e.g., all nodes that are authenticated for access to private networkusing User A’s credentials) would, therefore, be considered a source within the context of the grant. A controller for private networkmay distribute information about user-node associations so that private network clientcan determine whether packets are receives from User A’s nodes. If the grant does not indicate the packets are allowed, private network clientdiscards the packets (Step). In this example, if the packets are allowed, then private network clientforwards the packets to application, which is the application to which the packets are directed (step).

132 131 207 131 131 132 131 131 132 102 131 208 131 102 132 131 102 131 209 131 102 102 131 443 132 After forwarding the packets, private network clientreceives a request for authorization from application(step). The packets themselves may carry a request to access applicationor may be some other type of communication with application. Up to this point, private network clienthas used the network-layer portion of the grant. Although, in this example, the grant also defines application-layer authorizations. Specifically, the grant includes applicationin a list of one or more applications, services, and/or other application-layer resources to which the allowed sources have access. Upon receiving the request from application, private network clientdetermines whether the grant indicates source nodeis authorized to access application(step). If the grant does not list applicationas being accessible by source node, then private network clientresponds to the request from applicationwith an indication that source nodeis not allowed access to application(step). Applicationmay simply discard or ignore the communications in the packets or may respond to source nodewith a message indicating that source nodeis not authorized to access application. In some examples, the grant may specify allowed ports (e.g., TCP portfor HTTPS) or protocols (e.g., ICMP for diagnostics). Private network clientmay inspect packet headers to confirm compliance with these characteristics before transmission or forwarding.

132 102 131 131 131 102 131 210 131 131 131 131 102 105 131 132 102 131 102 101 102 105 105 If, however, the grant indicates to private network clientthat source nodecan access application, then applicationresponds to the request from applicationindicating that source nodeis authorized to access application(step). Applicationmay then handle the information in the packets as applicationis configured to do. For instance, if the packets carried a request for a particular feature of application, then applicationmay provide the feature to source nodeover private network. Applicationmay request authorization from private network clienteach time a packet is received from source node, periodically when packets are received (e.g., once an hour), just a first time packets are received for a given session, or on some other schedule. Advantageously, applicationdoes not need to authenticate source nodebut, rather, relies on the grants provided by policy engineand the fact that source nodehad to authenticate with private networkto gain access to private network.

3 FIG. 300 300 101 105 301 105 105 101 105 102 104 105 302 101 102 104 303 101 102 104 illustrates operational scenariofor using grants to control access on a private network. In operational scenario, policy enginegenerates grants to control access on private network(step). A portion of the grants define network-layer access allowances (e.g., which nodes can communicate with which other nodes) and a portion of the grants define application-layer access allowances (e.g., which applications/services can be accessed by which nodes/users). The grants may be generated at substantially the same time or may be generated as policies change for private network. For instance, an administrator of private networkmay decide to change access policies over time (e.g., may decide a given group of users should have access to a certain application that they did not previously have access). The administrator may script the grant themselves of may rely on an automated grant creation mechanism to create the grant from the desired policy. Grants created by policy enginefor private networkare distributed to all of nodes-over private network(step). In other examples, there may be certain grants that are not relevant to certain nodes and policy enginemay choose not to distribute the non-relevant grants to those nodes. Upon receiving the grants, nodes-cache the grants locally thereat (step). Over time, policy enginemay send updates adding grants, modifying existing grants, or removing existing grants and nodes-may update their cached grants accordingly.

102 131 103 105 304 103 132 305 102 103 131 131 102 103 In this example, source nodetransmits packets directed for applicationto destination nodeover private network(step). Upon receiving the packets, destination node(i.e., private network client) determines the packets satisfy at least one of the grants (step). For example, at least one grant lists source node, destination node, a port used by the packets, and a protocol used by the packets as being allowed. The packets are, therefore, allowed to pass to application. If the packets did not satisfy any of the grants, then the packets would be discarded or otherwise not allowed to pass to application. In other examples, since all of nodes 102-104 receive and cache the grants, source node(specifically a private network client executing thereat) may determine that the packets do not satisfy a grant prior to sending the packets to destination node.

131 131 131 132 132 102 131 306 132 131 131 102 131 307 131 102 102 103 102 Since the packets are passed to applicationbut applicationrequires authentication before handling the packets, applicationrequests authentication from private network client. Private network clientdetermines that a grant lists source nodeas being allowed to access application(step). To that end, private network clientresponds to applicationwith an indication that applicationis allowed to handle the packets from source node. Upon receiving the response, applicationhandles the packets (step). Handling of the packets may include applicationsending packets back to source node. Those packets may similarly be processed at source nodeto ensure a grant allows the packets being sent from destination nodeto source node.

4 FIG. 400 400 401 402 404 401 402 404 401 402 404 402 404 402 404 402 404 401 402 404 411 413 401 402 404 401 illustrates implementationfor using grants to control access on a private network. Implementationincludes coordination serviceand nodes-. Coordination serviceis a computing system performing control plane functions for a private network between nodes-. Coordination servicedistributes network configuration information to nodes-, which nodes use to establish secure connectivity. The configuration information may include private Internet Protocol (IP) addresses for nodes-, public IP addresses for nodes-, encryption keys for nodes-, or other parameters useful for creating a secure private network. In some examples, the configuration information may further include routing policies, posture requirements, or metadata for enforcing zero-trust principles. Coordination serviceenables nodes–to create secure tunnels-over public network infrastructure using encapsulation and encryption protocols such as WireGuard or IPsec. Coordination servicealso distributes access grants to nodes-to provide fine-grained control over communications within the private network. In other examples, coordination servicemay revoke or update grants dynamically in response to policy changes, posture evaluations, or expiration conditions defined in the grants.

402 404 422 424 401 411 413 422 424 422 424 401 441 401 422 424 Each of nodes-executes a respective one of clients-to handle control plane communications with coordination service, maintain tunnels-, exchange packets over the private network, and perform other tasks related to connectivity. Clients-may also perform cryptographic operations, such as encrypting and decrypting packets, encapsulating packets for transmission, and validating integrity of received packets. Since clients-operate within the communication path, they enforce access controls defined by grants received from coordination service. Enforcement may occur before packets are transmitted, after packets are received, or both, depending on whether the client acts as a source or destination. A network administrator, such as user, may define a grant through coordination service, which then distributes the grant to applicable clients-. Grants may specify permissions at both the network layer (e.g., which nodes can communicate) and the application layer (e.g., which services or APIs can be accessed), enabling unified policy enforcement.

422 424 432 434 402 404 402 442 403 404 401 401 422 424 Clients-regulate the transmission of packets between respective applications-, although nodes-may execute multiple applications concurrently. In this example, nodeis a user system operated by user. Nodesandmay also be user systems or other types of computing systems, such as servers, virtual machines, IoT devices, or containerized workloads. In some implementations, coordination servicemay operate in a distributed manner across multiple computing systems for scalability and fault tolerance. Alternative embodiments may integrate coordination servicewith an identity provider or public key infrastructure to validate user identities and rotate encryption keys. Grants may include additional conditions, such as device posture checks or time-based expiration, and clients-may periodically refresh cached grants to maintain compliance with evolving policies.

5 FIG. 500 500 422 401 501 422 401 442 422 401 422 401 422 502 403 404 403 404 401 423 424 402 401 422 401 illustrates operational scenariofor using grants to control access on a private network. In operational scenario, clientexchanges communications with coordination serviceto authenticate itself and join the private network (step). Authentication may involve clientproviding credentials directly to coordination serviceor being redirected to an identity provider for verification. Credentials may include username-password pairs, cryptographic tokens, certificates, or ephemeral keys. In this example, credentials for userare used to authenticate client, but other credential types may be employed in different implementations, such as OAuth tokens or hardware-backed keys. Once coordination servicedetermines that clientis authorized, coordination servicetransmits network configuration information to client(step). This configuration may include private IP addresses for nodesand, public IP addresses for nodesand, encryption keys, routing metadata, and posture requirements for compliance. In some examples, coordination servicemay also push updated configuration data to clientsandalready connected to the private network to ensure seamless communication with node. The configuration information includes access grants that define permissions for network-layer and application-layer interactions. The access grants are cached at the client for quick access without having to query coordination service. Although clientmay query coordination serviceto apply the grants in some examples.

432 403 503 433 422 504 442 422 423 403 422 After joining the private network, applicationgenerates one or more packets for transmission to node(step). These packets may represent a request for data from application, a command to initiate a session, or any other type of message exchanged between applications. In this example, clientdetects that the packets are directed to a private IP address (e.g., as opposed to an address outside of the private network) and references cached access grants to determine whether transmission is permitted (step). For instance, an access grant may specify that user, associated with client, is allowed to communicate with clientand may further define which applications at nodecan be accessed. In alternative embodiments, grants may include additional conditions such as time-based validity or device posture checks, requiring clientto verify compliance before sending packets.

422 411 423 505 423 506 423 423 433 423 423 433 507 433 432 401 Clienttransmits the packets over tunnelto client(step). The packets may be encrypted and encapsulated using protocols such as WireGuard or IPsec to ensure confidentiality and integrity during transit. Upon receiving the packets, clientevaluates whether the packets comply with the access grants (step). In some implementations, clientmay assume compliance based on enforcement at the source node, while in others, clientperforms its own validation for defense-in-depth. Grants may explicitly authorize forwarding packets to application, enabling application-layer control beyond simple network connectivity. This capability allows administrators to define granular permissions, such as permitting access to a database service but denying access to administrative APIs. Once clientconfirms authorization, clientpasses the packets to applicationfor processing (step). In many cases, the same grants enable bidirectional communication, allowing applicationto respond to applicationover the private network. Alternative implementations may include periodic revalidation of grants or dynamic updates from coordination serviceto reflect changing policies or user roles.

6 FIG. 600 401 422 424 501 502 500 432 404 601 434 422 602 422 422 424 404 illustrates an operational scenario for using grants to control access on a private network. Operational scenariooccurs after coordination servicedistributes access grants to clientsandafter authenticating the nodes and establishing tunnels for private network connectivity (e.g., after stepsandof operational scenario). In this example, applicationgenerates one or more packets for transmission to node(step). These packets may represent a request for data from application, a command to initiate a session, or any other type of message exchanged between applications. Clientdetects that the packets are directed to a private IP address and references cached access grants to determine whether transmission is permitted (step). In this example, based on the information about the packets available to client, clientidentifies a grant that allows the packets to be sent over the private network to clientat node.

422 413 424 603 424 604 424 434 605 422 434 422 422 Clienttransmits the packets over tunnelto client(step). The packets may be encrypted and encapsulated using protocols such as WireGuard or IPsec to ensure confidentiality and integrity during transit. Upon receiving the packets, clientevaluates whether the packets comply with the access grants (step). In this example, clientrecognizes that there is no grant allowing the packets to reach applicationand blocks the packets accordingly (step). Clientmay not have been able to identify characteristics of the packets that indicate they were destined for application. This may be the reason for clientnot blocking the packets before transmission. In other examples, clientmay recognize the application(s) associated with packets and apply the grants to that knowledge to block the packets prior to transmitting.

424 402 422 424 401 422 424 In some examples, blocking the packets may involve silently discarding the packets, while in others, clientmay generate an error response or log the denial for auditing and compliance purposes. Alternative embodiments may include proactive enforcement at the source node, reducing unnecessary traffic across the private network. Grants may also include additional conditions such as device posture or time-based validity, requiring clients to verify compliance before allowing communication. For example, if nodefails a posture check or the grant has expired, either clientor clientmay block the packets regardless of network-layer permissions. In other examples, coordination servicemay dynamically update grants to reflect changes in user roles or application availability, and clientsandmay periodically refresh cached grants to maintain alignment with current policies.

7 FIG. 700 700 422 432 402 432 711 731 721 402 422 711 432 711 422 701 illustrates operational scenariofor using grants to control access on a private network. Operational scenariois an example of how clientand applicationof nodemay transmit packets over the private network. Applicationgenerates packetwith payloadand a destination private IP addressin its header. The header may also include a private IP address of source node(or the source private IP address may be added by client) or any other information in designated header fields of packet(e.g., as specified by IPv4 or IPv6). Applicationpasses packetto client(step).

422 711 721 702 422 711 721 422 422 402 422 422 422 Clientdetermines a grant allows packetto be transmitted to private IP addressover the private network (step). Clientmay determine characteristics from packet, such as information in the header (e.g., private IP address, a source IP address assigned to client, or other header fields) and/or information about the payload (e.g., the application that generated the payload, the application to which the payload is being sent, etc.). Clientmay further determine characteristics external to the packet, such as time of day, a location of node, or other posture-related information. In some examples, grants may include posture conditions requiring verification before transmission. Clientapplies access grants to the determined characteristics to ensure an access grant explicitly allows the characteristics. If a given characteristic is not addressed in the grant, clientmay assume that characteristic is not applicable. For instance, if a grant only lists network-layer characteristics, then all application-layer characteristics may be assumed allowable under the grant. In other examples, grants may include explicit application-layer permissions, requiring clientto confirm the originating application is authorized before transmission.

711 422 711 732 712 703 422 721 722 721 712 401 401 422 711 422 422 To transmit the allowed packetover the private network, clientencrypts packetinto payloadof encapsulated packet(step). Clientuses a public encryption key corresponding to private IP addressand then uses public IP addresscorresponding to private IP addressin the destination address field of the header of encapsulated packet. The key and address correspondences are provided by coordination servicein the network configuration information. In some implementations, coordination servicemay also provide ephemeral keys for short-lived sessions to enhance security. The configuration information may further include user identity mappings, enabling grants to reference users rather than device addresses. Thus, clientcan resolve addresses corresponding to a user to determine whether a packet is associated with that user. Before encrypting and encapsulating packet, clientmay verify posture conditions such as operating system version or security patch compliance. If posture requirements are not met, clientblocks the packet rather than transmitting it.

712 722 404 704 413 Encapsulated packetis transmitted over the public network to public IP addressof node(step). The encapsulation is what enables tunnel. In alternative embodiments, encapsulation may include additional metadata for routing or posture verification, and encryption may use algorithms negotiated during the initial authentication exchange. Some implementations may also support multi-hop routing through intermediate nodes, where grants specify permitted paths for traffic.

8 FIG. 800 424 712 413 402 801 424 732 711 712 802 424 422 732 422 424 illustrates operational scenariofor using grants to control access on a private network. Clientreceives encapsulated packetover tunnelfrom node(step). Clientdecrypts payloadto restore packetfrom encapsulated packet(step). Clientuses a private encryption key corresponding to the public key clientused to encrypt payload. In some examples, the decryption process may also validate integrity using cryptographic signatures or message authentication codes to ensure the packet was not altered in transit. In some implementations, grants may include routing constraints requiring packets to traverse specific intermediate nodes or exit nodes. Clientmay encapsulate packets with metadata indicating the required route, and clientmay validate that the packet followed the authorized path.

424 402 404 803 424 402 424 In this example, clientconfirms that a grant allows packets from nodeas the source to nodeas the destination (step). The grant may indicate the source/destination nodes allowed by public IP addresses, private IP addresses, users associated with the nodes, user groups associated with the nodes, or other identifying information. In alternative embodiments, grants may include additional conditions such as device posture, time-based validity, or routing constraints, requiring clientto verify compliance before forwarding the packet. For instance, if nodedoes not meet posture requirements (e.g., running an approved software version), clientmay block the packet even if network-layer permissions exist.

424 402 434 402 711 711 434 424 711 434 804 424 424 In some examples, clientmay further determine a grant allows packets from nodeto reach application, allows the current device posture of node, and/or allows other characteristics associated with packet. This enables application-layer enforcement beyond simple connectivity, such as permitting access to a database service while denying access to administrative APIs. After determining packetis allowed to reach application, clientpasses packetto application(step). In other implementations, clientmay log the decision for auditing purposes or periodically revalidate grants to ensure compliance with dynamic policies. Alternative designs may also support multi-hop routing, where clientchecks whether intermediate nodes were authorized per the grant before accepting the packet.

9 FIG. 900 900 911 912 913 914 434 424 711 434 illustrates access grantfor controlling access on a private network. Access grantlists one or more sources, one or more destinations, one or more applications, and one or more aspects of source posture. Some of the lists are optional. For instance, a grant may apply only to network-layer characteristics of packet traffic, in which case application-layer characteristics would be omitted. In some examples, the grant may allow access to applicationonly for specific capabilities, such as read-only queries, while denying administrative actions. Clientenforces these granular permissions before passing packetto application.

911 Sourcescan include private or public IP addresses of nodes, hostnames, fully qualified domain names, user identities such as email addresses, user groups like “group:engineering” or “group:analytics,” device tags such as “tag:frontend” or “tag:database,” roles or autogroups like “autogroup:admin” or “autogroup:member,” CIDR ranges for subnets, ephemeral node identifiers, and logical selectors such as posture-based conditions.

912 Destinationscan include private or public IP addresses, hostnames or aliases, user identities, tags representing services or clusters such as “tag:internal-tools” or “tag:k8s-operator,” application connectors, virtual machines, containerized workloads, IP sets like “ipset:prod-infra,” and even geographic or network segments for segmentation policies.

913 Applicationscan include specific services or capabilities such as “tailscale.com/cap/tailsql” for database access, “tailscale.com/cap/secrets” for secret management, or “tailscale.com/cap/kubernetes” for cluster control. Applications may also define granular permissions such as read-only access, query execution, or administrative actions, and may reference APIs, microservices, or SaaS endpoints integrated with the private network.

914 Source posturecan include operating system type and version, security patch level, presence of endpoint protection software, encryption status of local storage, hardware attributes like TPM presence, runtime checks such as container image hash validation, and device posture conditions defined in the grant (e.g., “posture:latestMac” requiring a latest macOS version). A single grant may list multiple applications, such as a database service and a monitoring API, allowing unified policy enforcement for related resources.

443 22 53 443 80 443 In addition to these lists, grants may specify network-layer characteristics such as allowed ports (e.g., “,” “tcp:,” “udp:”), allowed protocols (e.g., “icmp:*,” “tcp:”), port ranges (e.g., “-”), and routing constraints using “via” fields to enforce traffic through specific exit nodes or app connectors. Grants may also include time-based validity, expiration conditions, or dynamic posture checks, enabling fine-grained and adaptive access control across both network and application layers.

10 FIG. 1000 1000 402 422 401 1001 422 401 illustrates operationthat uses grants to control access on a private network. Operationis an example of how time-based validity may be implemented in node. Clientreceives a grant from coordination service(step). The grant may be provided when clientjoins the private network or at a later time, such as when coordination servicegives a user temporary access to a resource associated with the grant.

422 1002 422 1003 [Clientcaches the grant with other grants controlling network access on the private network (step). Clientfurther identifies an expiration condition specified in the grant (step). Expiration conditions can take many forms. For example, a grant may expire after a fixed duration such as one hour, one day, or one week from issuance. In other cases, the expiration may be tied to a specific date and time, such as midnight on a given day or the end of a maintenance window. Expiration may also be event-driven, such as when a user logs out, disconnects from the private network, or completes a transaction. Other examples include posture-based expiration, where the grant becomes invalid if the device fails a compliance check, or session-based expiration, where the grant is removed after a VPN session ends.

1004 422 1005 422 1006 422 401 401 401 422 As long as the expiration condition has not been satisfied (step), clientcontinues to apply the grant to traffic exchanged over the private network (step). When the condition is satisfied, clientdeletes the grant from the cache, preventing the grant from being used on subsequent traffic (step). In some implementations, clientmay periodically check the expiration condition or receive updates from coordination serviceto enforce dynamic policies. For example, coordination servicemay revoke a grant early if a user’s role changes or if suspicious activity is detected. In other examples, expiration may involve cryptographic key rotation, where the grant becomes invalid once associated keys are replaced, ensuring that stale grants cannot be exploited. Other expiration conditions may include user logout, completion of a transaction, or detection of suspicious activity. These events may trigger immediate revocation of the grant by coordination serviceor by client.

1000 402 422 401 1001 422 401 Operationis an example of how time-based validity may be implemented in node. Clientreceives a grant from coordination service(step). The grant may be provided when clientjoins the private network or at a later time (e.g., when coordination servicegives a user temporary access to a resource associated with the grant).

422 1002 422 1003 1004 422 1005 422 1006 Clientcaches the grant with other grants controlling network access on the private network (step). Clientfurther identifies an expiration condition specified in the grant (step). As long as the expiration condition has not been satisfied (step), clientcontinues to apply the grant to traffic exchanged over the private network (step). When the condition is satisfied, clientdeletes the grant from the cache preventing the grant from being used on the traffic (step).

11 FIG. 1100 1100 1100 101 1100 1145 1150 1160 1150 1160 1145 1160 1145 1100 illustrates computing systemfor using grants to control access on a private network. Computing systemis representative of any computing system or systems with which the various operational architectures, processes, scenarios, and sequences disclosed herein can be implemented. Computing systemis an example architecture for policy engine, nodes 102-104, although other examples may exist. Computing systemincludes storage system, processing system, and communication interface. Processing systemis operatively linked to communication interfaceand storage system. Communication interfacemay be communicatively linked to storage systemin some implementations. Computing systemmay further include other components such as a battery and enclosure that are not shown for clarity.

1160 1160 1160 1160 Communication interfacecomprises components that communicate over communication links, such as network cards, ports, radio frequency (RF), processing circuitry and software, or some other communication devices. Communication interfacemay be configured to communicate over metallic, wireless, or optical links. Communication interfacemay be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format – including combinations thereof. Communication interfacemay be configured to communicate with other computing systems via one or more networks.

1150 1145 1145 1145 1145 1145 Processing systemcomprises microprocessor and other circuitry that retrieves and executes operating software from storage system. Storage systemmay include volatile and nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Storage systemmay be implemented as a single storage device but may also be implemented across multiple storage devices or sub-systems. Storage systemmay comprise additional elements, such as a controller to read operating software from the storage systems. Examples of storage media include random access memory, read only memory, magnetic disks, optical disks, and flash memory, as well as any combination or variation thereof, or any other type of storage media. In some implementations, the storage media may be a non-transitory storage media. In some instances, at least a portion of the storage media may be transitory. In no interpretations would storage media of storage system, or any other computer-readable storage medium herein, be considered a transitory form of signal transmission (often referred to as "signals per se"), such as a propagating electrical or electromagnetic signal or carrier wave.

1150 1145 1145 1130 1145 1150 1145 1100 1130 1150 1130 1130 132 1100 Processing systemis typically mounted on a circuit board that may also hold the storage system. The operating software of storage systemcomprises computer programs, firmware, or some other form of machine-readable program instructions. The operating software of storage systemcomprises grant module. The operating software on storage systemmay further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When read and executed by processing systemthe operating software on storage systemdirects computing systemto network routing advertisements as described herein. Grant modulemay execute natively on processing systemor the operating software may include virtualization software, such as a hypervisor, to virtualize computing hardware on which grant moduleexecutes. Grant modulemay be a component of a client, like private network client, enabling computing systemto communicate over a private network.

1100 1130 1150 1150 1130 1130 1100 1100 1130 1150 1130 1150 In at least one example, computing systemis a destination node for packets exchanged over a private network. Grant moduleexecutes on processing systemand directs processing systemto receive a grant from a policy engine for a private network. The grant indicates a list of sources, a list of destinations the sources are allowed to access, and a list of applications. Grant modulefurther directs grant moduleto cache the grant in a cache at computing system. Computing systemreceives one or more packets over the private network from a source node. The one or more packets are directed towards an application executing on the destination node. In response to determining the source node is in the list of sources, the destination node is in the list of destinations, grant moduledirects processing systemto pass the one or more packets to the application. Grant modulealso directs processing systemto receive a request from the application asking whether the source node is allowed to access the application and, in response to accessing the grant in the cache to determine the source node is in the list of sources, the destination node is in the list of destinations, and the application is listed in the list of applications, respond to the request with an indication that the source node is allowed to access the application.

The included descriptions and figures depict specific implementations to teach those skilled in the art how to make and use the best mode. For teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these implementations that fall within the scope of the invention. Those skilled in the art will also appreciate that the features described above can be combined in various ways to form multiple implementations. As a result, the invention is not limited to the specific implementations described above, but only by the claims and their equivalents.