Mukesh Hira, Jayant Jain, Ganesan Chandrashekhar, Anirban Sengupta, Pankaj Thakkar,

Alexander Tessmer, and Vivek Agarwal

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of ET.S. Non-Provisional Application No. 15/881,703 entitled“UNIFIED SECURITY POLICIES ACROSS VIRTUAL PRIVATE CLOUDSWITH OVERLAPPING IP ADDRESS BLOCKS,” filed January 26, 2018.

[0002] This application relates to: U.S. Provisional Application No. 62/380,411, entitled “EXTENSION OF NETWORK CONTROL SYSTEM INTO PUBLIC CLOUD,” filed August 27, 2016; U.S. Application No. 15/253,829, entitled“EXTENSION OF NETWORK CONTROL SYSTEM INTO PUBLIC CLOUD,” filed August 31, 2016; U.S. Application No. 15/253,832, entitled“MANAGED FORWARDING ELEMENT EXECUTING IN PUBLIC CLOUD DATA COMPUTE NODE WITHOUT OVERLAY NETWORK,” filed August 31, 2016; U.S. Application No. 15/253,833, entitled“MANAGED FORWARDING ELEMENT EXECUTING IN PUBLIC CLOUD DATA COMPUTE NODE WITH DIFFERENT INTERNAL AND EXTERNAL NETWORK ADDRESSES,” filed August 31, 2016; U.S. Application No. 15/253,834, entitled“MANAGED FORWARDING ELEMENT EXECUTING IN SEPARATE NAMESPACE OF PUBLIC CLOUD DATA COMPUTE NODE THAN WORKLOAD APPLICATION,” filed August 31, 2016; U.S. Application No. 15/279,382, entitled“CENTRALIZED PROCESSING OF NORTH-SOUTH TRAFFIC FOR LOGICAL NETWORK IN PUBLIC CLOUD,” filed September 28, 2016; U.S. Application No. 15/279,394, entitled“DISTRIBUTED NETWORK ENCRYPTION FOR LOGICAL NETWORK IMPLEMENTED IN PUBLIC CLOUD,” filed September 28, 2016; U.S.

Application No. 15/279,403, entitled“LOGICAL NETWORK DOMAINS STRETCHED BETWEEN PUBLIC AND PRIVATE DATACENTERS,” filed September 28, 2016; U.S. Application No. 15/279,409, entitled“DISTRIBUTED PROCESSING OF NORTH-SOUTH TRAFFIC FOR LOGICAL NETWORK IN PUBLIC CLOUD,” filed September 28, 2016; U.S. Application No. 15/369,580, entitled“POLICY DEFINITION AND ENFORCEMENT FOR A NETWORK VIRTUALIZATION PLATFORM,” filed December 5, 2016; U.S. Application No. 15/369,596, entitled“MULTI-LAYER POLICY DEFINITION AND ENFORCEMENT FRAMEWORK FOR NETWORK VIRTUALIZATION,” filed December 5, 2016, issued as U.S. Patent No. 9,762,619; and U.S. Application No. 15/406,249, entitled “MANAGING NETWORK TRAFFIC IN VIRTUAL SWITCHES BASED ON LOGICAL PORT IDENTIFIERS,” filed January 13, 2017. The contents of each of these applications are hereby incorporated by reference in their entireties.

FIELD

[0003] The present disclosure relates generally to logical networks, and more specifically to distributing unified security policies through a logical network operating on a software- defined datacenter using logical ports.

BACKGROUND

[0004] An increasing number of users (e.g., organizations, companies) are moving their networks to the cloud, which is built on datacenters. The network may encompass a private datacenter and a public datacenter, or a combination of several private and/or public datacenters. A software-defined datacenter enables an administrator of the network to more easily manage the network running on several datacenters by providing a logical overlay network, which may also referred to simply as a“logical network,” and which are also known in the industry as a software defined network (SDN). Logical overlay networks are decoupled from the underlying physical infrastructure using a tunneling protocol such as VXLAN or Geneve, and can be extended across multiple datacenters.

[0005] As with any network, administrators may wish to enforce a global security policy to a logical network. Security policies are typically enforced by a network using internet protocol (IP) addresses of the virtual machines. However, difficulties in applying a unified security policy uniformly to all endpoints of the logical network may arise if different virtual machines of the network are assigned overlapping IP addresses. For example, if a public datacenter of the software-defined datacenter assigns two isolated sets of computing resources over which the administrator has control, but they are deployed with overlapping IP addresses, a single unified security policy cannot be properly enforced on both sets of computing resources using traditional techniques. OVERVIEW

[0006] The invention disclosed herein enhances the enforcement of unified security policies on a logical network running on a software-defined datacenter by implementing the policies using logical ports.

[0007] In some embodiments, a method for enforcing, on a logical network running on a software-defined datacenter, a unified global policy having rules for two or more isolated computing systems is described. The method comprises, at a central controller: transmitting, to first and second computing systems (e.g., in a public datacenter), the rules of the unified global policy, wherein each computing system includes virtual machines assigned to a particular internet protocol address block. The method further comprises, at a first virtual machine of the first computing system: receiving the plurality of rules of the unified global policy; identifying a packet to be transmitted from the first virtual machine to a destination virtual machine; identifying a source logical port corresponding to the first virtual machine and a destination logical port corresponding to the destination virtual machine; in accordance with a determination, based on the source logical port and the destination logical port, that the packet is prohibited one of the rules from being transmitted from the first virtual machine to the destination virtual machine, forgoing transmitting the packet; and in accordance with a determination, based on the source logical port and the destination logical port, that the packet is not prohibited by the rules from being transmitted from the first virtual machine to the destination virtual machine, transmitting a communication using the destination logical port, wherein the communication includes the packet.

[0008] In some embodiments, one or more non-transitory (and/or transitory) computer- readable storage medium (which optionally includes one or more modules, programs, and/or set of instructions for performing multiple functions) storing one or more programs configured to be executed by one or more processors to enforce, on a logical network running on a software-defined datacenter, a unified global policy having rules for two or more isolated computing systems is described. The one or more programs include instructions for, at a central controller, transmitting, to first and second computing systems, the rules of the unified global policy. The first and second computing system each includes virtual machines that are assigned to a particular internet protocol address block. The one or more programs further include instructions for carrying out the method at a first virtual machine, as described above. [0009] In some embodiments, a system (which optionally includes memory and one or more modules, programs, and/or set of instructions in the memory for performing multiple functions) for enforcing, on a logical network running on a software-defined datacenter, a unified global policy having a plurality of rules to two or more isolated computing systems is described.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The following description and associated figures teach the best mode of the inventions. Thus, those skilled in the art will appreciate variations from the best mode that fall within the scope of the inventions. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the inventions. As a result, the inventions are not limited to the specific examples described below, but only by the claims and their equivalents.

[0011] FIG. 1 illustrates a block diagram showing an exemplary logical network running on a software-defined datacenter.

[0012] FIG. 2 illustrates a flow diagram describing an example operational scenario of enforcing a global security policy on the exemplary logical network using IP addresses.

[0013] FIG. 3 illustrates a table showing the assigned IP addresses and workloads of virtual machines of the exemplary logical network.

[0014] FIG. 4 illustrates a block diagram showing network components of a virtual private cloud of the exemplary logical network.

[0015] FIG. 5 illustrates a flow diagram describing an example operational scenario of enforcing a global security policy on the exemplary logical network using logical ports.

DETAILED DESCRIPTION

[0016] The invention disclosed herein is directed to embodiments for enforcing unified security policies (e.g., a firewall rule, a forwarding rule) at endpoints of a logical network using logical ports. The logical network, which optionally comprises logical switches and routers to connect the network’s virtual machines and/or containers, may operate on a software-defined datacenter. The logical network is further managed by a central management and control system, which in turn is optionally configured by a network administrator of an owner (e.g., an organization, a company) of the logical network.

[0017] In some embodiments, the software-defined datacenter spans across one or more private datacenters, in which the central management and control system can directly access and control the forwarding elements, and/or one or more public cloud multi-tenant datacenters, in which the central management and control system does not have direct access and control over the forwarding elements. Further, the one or more public cloud datacenters may be of the same cloud service provider or of different cloud service providers.

[0018] A typical datacenter (whether public or private) includes a plurality of host computing systems that are each powered by one or more processors and that each includes memory. Memory may include one or more computer-readable storage media. The one or more computer-readable storage media may be tangible and non-transitory, and/or may be transitory. Memory may include high-speed random access memory and may also include non-volatile memory (e.g., one or more flash storage devices, one or more magnetic disk storage devices, and/or other non-volatile solid-state memory devices). The one or more computer-readable storage media included in memory may store one or more programs comprising instructions. The instructions may be configured to implement (at least a portion of) a logical network.

[0019] In some embodiments, the logical network provides connectivity between workloads (e.g., of virtual machines, of containers) that exist on the same host computing system running on a (public or private) datacenter or that operates on separate host computing systems running across one or more (public and/or private) datacenters.

[0020] In some embodiments, the central management and control system expands private datacenter management and control into the public datacenter(s), thereby expanding management and control to the entire logical network spanning the software-defined datacenter. For example, the central management and control system directs network controllers and forwarding elements associated with the logical network to enforce security policies (e.g., firewall rules, forwarding rules) for packets sent to and from a virtual machine and/or containers. In some embodiments, public datacenter(s) provides tenants with one or more isolated sets of computing resources over which the tenant has control, which is referred to herein as virtual private clouds. [0021] FIG. 1 illustrates an exemplary logical network 100 operating on a software- defined datacenter and managed by a central management and control system. In this embodiment, the software-defined datacenter hosting logical network 100 includes a datacenter 110 and a datacenter 111. Datacenter 110 is a private datacenter operating central management and control system 120. In other embodiments, datacenter 110 may be a public datacenter. Datacenter 111 is a public datacenter hosting a plurality of compute virtual private clouds of the logical network, including virtual private cloud 130 and virtual private cloud 131. The software-defined datacenter also optionally includes one or more additional public and/or private datacenters (not shown).

[0022] In some embodiments, in order for central management and control system 120 to manage logical network 100, a first level of network controller (e.g., a gateway controller) connected to its respective virtual machines is deployed on each virtual private cloud. Virtual private cloud 130 includes a local gateway controller 140 and virtual private cloud 131 includes a local gateway controller 141. In some embodiments, the local gateway controllers operate a gateway datapath for communication with other virtual private clouds of the logical network in the same datacenter and/or with other virtual private clouds of the logical network in a different (private and/or public) datacenter and with external networks.

[0023] As also shown in FIG. 1, logical network 100 further operates a plurality of workloads as virtual machines, including virtual machines 150-152 of virtual private cloud 130 and virtual machines 153-155 of virtual private cloud 131. Workloads are optionally also deployed on one or more containers within a virtual machine. A virtual machine of the logical network (or a container of the logical network) optionally executes one or more workload applications, such as a web server, an application server, or a database server. For example, in virtual private cloud 130, virtual machine 150 is executing a web server, virtual machine 151 is executing a database server, and virtual machine 152 is executing an application server. Similarly, in virtual private cloud 131, virtual machine 153 is executing a web server, virtual machine 154 is executing an application server, and virtual machine 155 is executing a database server.

[0024] In some embodiments, each virtual machine of the logical network includes a network interface for connection to the logical network, thereby enabling communication among the virtual machines of the network. For example, the network interface for the virtual machine optionally includes a virtual network interface. Further, within each virtual machine, a managed forwarding element is optionally inserted into a datapath between the workload application and the network interface. A local control agent that configures its respective managed forwarding element is optionally operating on each virtual machine.

[0025] Features concerning the network management and control system and its ability to manage a logical network that spans both a private and public datacenters is described in greater detail in cross-referenced applications U.S. Application No. 15/253,829, U.S.

Application No. 15/253,832, U.S. Application No. 15/253,833, U.S. Application No.

15/253,834, U.S. Application No. 15/279,382, U.S. Application No. 15/279,394, U.S.

Application No. 15/279,403, and U.S. Application No. 15/279,409.

[0026] As discussed above, global security policies are also implemented on a logical network (e.g., logical network 100) running on a software-defined datacenter (e.g., including datacenters 110 and 111). Typically, security policies such as firewall rules are enforced at target endpoints (e.g., virtual machines, containers) based on internet protocol (IP) addresses.

[0027] When the logical network is deployed on a software-defined datacenter, its virtual private clouds are assigned IP address blocks. If there are a plurality of virtual private clouds on the network (e.g., a first virtual private cloud for a first division of a company and a second virtual private cloud for a second division of the company), two or more of the virtual private clouds may be assigned at least partially overlapping IP address blocks upon deployment. That is, at least one virtual machine of the first virtual private cloud and at least one virtual machine of a second virtual private cloud may be assigned the same IP address (or different containers within the same virtual private cloud may be assigned overlapping IP addresses). Further, because the IP addresses are assigned by the cloud service provider of the public datacenter, the administrator may not have direct control of how the IP addresses are assigned to the endpoints (e.g., virtual machines, containers) of the logical network.

[0028] Overlapping IP addresses among two or more virtual private clouds of a logical network may lead to inconsistent and unintended application of a security policy. This is particularly problematic when a single security policy is configured to be enforced at all (or multiple) endpoints of the network (e.g., a unified security policy) and the security policy is enforced based on IP addresses, which is a conventional method of enforcing firewall rules in a network. FIG. 2 illustrates a flow diagram 200 for enforcing a global security policy comprising a plurality of firewall rules to endpoints of logical network 100 using IP addresses. In this example, the global security policy includes a first firewall rule (referred to herein as“Firewall Rule A”) that prohibits a web server workload of a virtual machine from communicating with a database server workload of a different virtual machine. Thus, in brief, Firewall Rule A is a,“Deny Web to Database” firewall rule.

[0029] In some embodiments, in order to distribute the same security policy throughout logical network 100, central controller 120 views all of the logical ports that correspond to workloads in the virtual private clouds of the logical network as being connected to a respective managed forwarding element controlled by its respective gateway controller. As such, at block 210, central controller 120 pushes down the security policy to the gateway controllers of the logical network, including gateway controllers (e.g., 140-141). Thus, the gateway controllers (e.g., 140-141) of the local network receive the same security policy information.

[0030] At block 220, upon receiving the security policy, each gateway controller (e.g., gateway controllers 140-141 of logical network 100) performs a span calculation to identify the target managed forwarding element(s) of a virtual machine(s) that require each rule of the policy and distributes each rule to its respective target managed forwarding element(s). A local control agent managing each virtual machine may then enforce the received rule(s) upon its respective managed forwarding element.

[0031] As mentioned, virtual machines are assigned IP addresses when they are deployed within a network. In some cases, different virtual private clouds may be assigned at least partially overlapping IP address blocks upon deployment. For example, FIG. 3 illustrates, in Table 300, the IP addresses and server groups assigned to each virtual machine of virtual private clouds 130 and 131. As shown in row 310, virtual machine 150 is assigned IP address 10.0.0.10 and a web server workload. As shown in row 320, virtual machine 151 is assigned IP address 10.0.0.20 and a database server workload. As shown in row 330, virtual machine 152 is assigned IP address 10.0.0.30 and an application server workload. As shown in row 340, virtual machine 153 is assigned IP address 10.0.0.10 a web server workload. As shown in row 350, virtual machine 154 is assigned IP address 10.0.0.20 and an application server workload. As shown in row 360, virtual machine 165 is assigned IP address 10.0.0.30 and a database server workload. [0032] A firewall rule is typically enforced at the endpoints of the network based on IP address of the virtual machine. In some embodiments, Firewall Rule A is configured to operate at virtual private cloud 130 and not at virtual private cloud 131 (and thus is not a unified firewall rule that is enforced uniformly across all endpoints of the network). As noted above, Firewall Rule A prohibits a web server workload from communicating with a database server workload. When the rule is translated to IP addresses, Firewall Rule A prohibits communication between a virtual machine with IP address 10.0.0.10 and a virtual machine with IP address 10.0.0.20.

[0033] Returning to FIG. 2, at block 230, the local control agent of virtual machine 150 identifies a packet (referred to herein as“Packet A”) destined for virtual machine 151 (the destination virtual machine). At block 240, upon identifying Packet A, the local control agent of virtual machine 150 further identifies source and destination IP addresses of the packet. In this example, the source and destination IP addresses of Packet A is 10.0.0.10 and 10.0.0.20, respectively.

[0034] At block 250, upon determining the source and destination IP addresses of Packet A, the local control agent of virtual machine 150 compares the IP addresses to the firewall rules being enforced at virtual private cloud 130, which includes Firewall Rule A. Under Firewall Rule A, however, a communication is prohibited between 10.0.0.10 and 10.0.0.20 IP addresses. As such, at block 260, the local control agent of virtual machine 150 blocks a managed forwarding element of virtual machine 150 from transmitting Packet A to its intended destination (virtual machine 151), thereby satisfying Firewall Rule A’s enforcement rule blocking communication between a web server workload (virtual machine 150) and a database server workload (virtual machine 151).

[0035] In some embodiments, Firewall Rule A is a unified firewall rule configured to operate uniformly across all endpoints of the logical network, including at both virtual private cloud 130 and virtual private cloud 131. In this scenario, unified Firewall Rule A is enforced on virtual private cloud 130 as described in blocks 230-260 but also enforced on virtual private cloud 131 as described in blocks 231-261.

[0036] At block 231, the local control agent of virtual machine 153 identifies a packet (referred to herein as“Packet B”) to be transmitted from virtual machine 153 (the source virtual machine) to virtual machine 154 (the destination virtual machine). At block 241, upon identifying Packet B, the local control agent of virtual machine 153 further identifies source and destination IP addresses of the packet. In this example, the source and destination IP addresses of Packet B are 10.0.0.10 and 10.0.0.20, respectively.

[0037] At block 251, upon determining the source and destination IP addresses of Packet B, the local control agent of virtual machine 153 compares the IP addresses to the firewall rules being enforced at virtual private cloud 131, including unified Firewall Rule A. Under unified Firewall Rule A, however, a communication is prohibited between the 10.0.0.10 and 10.0.0.20 IP addresses. As such, at block 261, the local control agent of virtual machine 153 blocks a managed forwarding element of virtual machine 153 from transmitting Packet B to virtual machine 154.

[0038] However, in contrast to the enforcement of Firewall Rule A in virtual private cloud 130, enforcement of Firewall Rule A in virtual private 131 results in the policy blocking communication between a web server workload (virtual machine 153) and a database server workload (virtual machine 154), because, in virtual private cloud 131, IP address 10.0.0.10 corresponds to a web server workload and IP address 10.0.0.20 corresponds to an application server workload. This is not the intent of Firewall Rule A, which is intended to block communication between a web server workload and a database worker, and not to block communication between a web server workload and an application workload.

[0039] Thus, flow diagram 200 illustrates the problem of applying a single unified firewall rule across all endpoints of a logical network of a software-defined datacenter based on, as a firewall rule typically is, IP addresses of virtual machines. This is particularly problematic for a logical network running on a software-defined datacenter, such as logical network 100, which may utilize one or more public datacenters to which the network administrator does not have control over the assignment of IP addresses of virtual machines. Thus, a network administrator is often forced to configure targeted firewall rules instead of a single unified firewall rule to ensure consistent application of a global security policy across its network.

[0040] The techniques disclosed herein solve this problem resulting from overlapping IP addresses between different virtual private clouds of a logical network by enforcing security rules based on logical ports (e.g., a 36-character universally unique identifier (UUID) as per the RFC 4122 format assigned to each virtual machine of the network) instead of IP addresses. In some embodiments, a logical port is a 36-character (e.g., 32 hex characters and 4 hyphens) universally unique identifier (UUID) as per the RFC 4122 format. In some embodiments, a logical port is represented as a 16 byte value in memory and in a packet.

[0041] In some embodiments, when a logical network is deployed in a software-defined datacenter, each virtual machine is assigned a unique logical port, which is used to join the virtual machine to a corresponding logical network or logical switch. As mentioned, these logical ports are unique across the logical network. Thus, unlike IP addresses, logical ports do not overlap across virtual private clouds of the logical network. Similarly, in a logical network that deploys containers, each container is assigned a unique logical port used to join the container to a corresponding logical network or logical switch.

[0042] FIGS. 4-5 describe the enforcement of unified Firewall Rule A (e.g., a unified “Deny Web to Database” rule) on virtual private cloud 131 using logical ports instead of IP addresses to identify the destination virtual machine (or container). FIG. 4 illustrates an enlarged view of virtual private cloud 131 of logical network 100, in accordance with some embodiments. An example operational scenario of enforcing unified Firewall Rule A on virtual private cloud 131 is described with reference to the blocks 510-590 of Flow Diagram 500 of FIG. 5.

[0043] At block 510, gateway controller 141 of virtual private cloud 131 receives, from central controller 120, a global security policy that includes at least one unified firewall rule, including unified Firewall Rule A. At block 520, upon receiving the global security policy, gateway controller 141 translates all relevant rules (including all of the unified policies, such as unified Firewall Rule A) to logical port identifiers (instead of IP addresses), and pushes down the translated policies to each of virtual machines 153-155.

[0044] At block 530, a local control agent 163 of virtual machine 153, which manages managed forwarding element 173 (which may be a virtual switch inside the virtual machine), identifies a third packet (referred to herein as“Packet C”) with the same source and destination (virtual machine 154) as Packet B. At block 540, upon identifying Packet C, local control agent 163 identifies, based on the packet, a source logical port corresponding to the source virtual machine (virtual machine 153) and a destination logical port corresponding to the destination virtual machine (virtual machine 154). [0045] At block 550, local control agent 163 compares the identified source and destination logical ports to the firewall rules being enforced on virtual private cloud 131, which includes unified Firewall Rule A. As mentioned, the firewall rules have been translated to logical port identifiers from IP addresses. Local control agent 163 compares the source and destination logical ports of Packet C to the translated firewall rules, including unified Firewall Rule A, to determine whether Packet C is permitted, under the unified firewall rules, to be transmitted to its destination virtual machine (or destination container).

[0046] In accordance with a determination, at block 560, that the communication is permitted, local control agent 163 permits forwarding of Packet C to its destination virtual machine (or destination container). In some embodiments, if the logical network is an overlay network, the source virtual machine (or the source container) encapsulates the packet with its source logical port prior to transmitting the packet to its destination (as described below at block 570). In some embodiments, if the logical network is a non-overlay network, the source virtual machine (or the source container) transmits the packet to its destination without encapsulating the packet with its source logical port (as described below at block 571).

[0047] In accordance with a determination, at block 560, that the communication is not permitted, the source virtual machine (or the source container), at block 572, drops the packet (and thus the packet is not forwarded to its destination virtual machine or destination container).

[0048] As described with reference to blocks 210-260 and 210-261 of FIG. 2, under IP address-based enforcement, unified Firewall Rule A improperly blocked communication between virtual machine 153 (a web server) and virtual machine 154 (an application server). In contrast, if unified Firewall Rule A is enforced based on logical port identifiers, such unintended enforcement does not occur because logical port identifiers are, as opposed to IP addresses, unique across all of the virtual machines (and/or containers) of the logical network. More specifically, two virtual machines (or two containers) that share the same IP address are each assigned (e.g., upon deployment of the network) a logical port identifier that is unique in the network.

[0049] As such, while IP address-translated unified Firewall Rule A described with reference to blocks 210-261 of FIG. 2 would improperly cause local control agent 163 to prohibit managed forwarding element 173 from transmitting Packet C to virtual machine 154, local port-translated unified Firewall Rule A described with reference to blocks 510-560 causes local control agent 163 to properly allow managed forwarding element 173 to transmit Packet C to virtual machine 154. Thus, communication between virtual machine 153 and virtual machine 154 is not blocked by unified Firewall Rule A under logical port-based application of the rule. As such, if none of the other applicable firewall rules block the communication, communication of Packet C to virtual machine 154 is not blocked by the local control agent.

[0050] In some embodiments, once the source logical port is identified, the local control agent, at block 570, causes managed forwarding element 173 to encapsulate the source logical port (e.g., as a header) with Packet C into an encapsulated packet. Thus, the encapsulated packet includes Packet C with one or more headers including the source logical port of virtual machine 153 encapsulated to the packet.

[0051] In this exemplary operation, because of the distribution of the global security policy down to the workload-level, the security policies are operating right next to the workload (e.g., workloads 183-185 of virtual machines 153-155, respectively)— the security policies are enforced by the local control agent (e.g., local control agents 163-165 of virtual machines 153-155, respectively), which is on the same attachment surface as the workload. As such, if the workload is compromised, the security agent may also be comprised. In view of this potential risk, a benefit of the encapsulation is that, by encapsulating the source logical identifier to packet communications, policies can be enforced by both the sending and recipient workloads (as opposed to only by the sending workload), thereby providing a second level of security to the network.

[0052] In some embodiments, the encapsulation of the source logical port is not performed. For example, a network administrator of the logical network may not desire the overlay feature that comes with the encapsulation but may still wish for microsegmentation of the workloads. That is, another benefit of embedding the security agent directly into the virtual machines of the logical network is microsegmentation across the virtual machines— microsegmentation allows the logical network to provide each virtual machine with its own perimeter defense, thereby eliminating unauthorized access between adjacent workloads. Thus, even without encapsulation, logical network 100 still provides the benefit of microsegmentation. [0053] At block 580, after creating the encapsulated packet of Packet C, local control agent 163 instructs managed forwarding element 173 to transmit the encapsulation packet to virtual machine 154. Similarly, at block 571, if encapsulation was not performed, local control agent 163 instructs managed forwarding element 173 to transmit Packet C to virtual machine 154.

[0054] At block 590, managed forwarding element 173 forwards the packet (non- encapsulated Packet C or the encapsulated packet including Packet C) to a network interface 193 of the virtual machine, which subsequently forwards the packet (non-encapsulated Packet C or encapsulated Packet C) to the destination virtual machine (or destination container).

The use of logical ports to manage packet forwarding over virtual switches is discussed in greater detail in cross-referenced application U.S. Application No. 15/406,249.

[0055] As discussed, with encapsulation, when a packet is received at a destination virtual machine (or a destination container), a policy can be re-enforced at the destination (based on the source logical port, destination logical port pair). In some embodiments, upon receiving encapsulated Packet C, the destination virtual machine (or destination container) determines (e.g., via a local control agent of the destination virtual machine), based on the encapsulated header containing the source logical port of the packet, whether Packet C is permitted under unified Firewall Rule A to be transmitted from the source virtual machine (or the source container) to the destination virtual machine (or the destination container). In accordance with a determination that Packet C is not permitted under unified Firewall Rule A to be transmitted from the source virtual machine to the destination virtual machine, Packet C is dropped by the destination virtual machine. As mentioned, this second level of

enforcement at the destination virtual machine (or at the destination container) protects against the source virtual machine (or the source container) being compromised.

[0056] The included descriptions and figures depict specific implementations to teach those skilled in the art how to make and use the best mode. For the purpose of 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.