Methods and Systems for Efficient Virtualization of Inline Transparent Computer Networking Devices

Abstract

Network devices that are inserted inline into network links and process in-transit packets may significantly improve their packet-throughput performance by not assigning L3 IP addresses and L2 MAC addresses to their network interfaces and thereby process packets through a logical fast path that bypasses the slow path through the operating system kernel. When virtualizing such Bump-In-The-Wire (BITW) devices for deployment into clouds, the network interfaces must have L3 IP and L2 MAC addresses assigned to them. Thus, packets are processed through the slow path of a virtual BITW device, significantly reducing the performance. By adding new logic to the virtual BITW device and/or configuring proxies, addresses, subnets, and/or routing tables, a virtual BITW device can process packets through the fast path and potentially improve performance accordingly. For example, the virtual BITW device may be configured to enforce a virtual path (comprising the fast path) through the virtual BITW device.

Claims

1. A cloud computing network configured to send packets between a network address translation (NAT) gateway and a second virtual device, via a virtual bump-in-the-wire (BITW) device, the cloud computing network comprising: one or more processors; the NAT gateway, wherein the NAT gateway is configured to interface between a public network and the cloud computing network; the virtual BITW device, comprising: a first interface having a private Internet Protocol (IP) address in a first subnet; a second interface having a private IP address in a second subnet; and a fast path between the first interface and the second interface and configured to apply packet-filtering logic to traffic received by the virtual BITW device; and the second virtual device, wherein the NAT gateway is configured to: receive packets indicating a public IP address of the second virtual device as a destination IP address; modify the destination IP address of the packets to be the private IP address of the first interface of the virtual BITW device; and send the packets to the first interface of the virtual BITW device, and wherein the virtual BITW device is configured to: receive, via the first interface, the packets from the NAT gateway; modify the destination IP address of the packets to be a private IP address of the second virtual device; and apply, using the fast path, the packet-filtering logic to the packets received via the first interface; and send, based on the packet-filtering logic and via the second interface, at least a portion of the packets.

2. The cloud computing network of claim 1, wherein the packets indicate a media access control (MAC) address of the NAT gateway as a source MAC address, and indicate a MAC address of the first interface of the virtual BITW device as a destination MAC address, and wherein the virtual BITW device is further configured to: modify the source MAC address of the at least a portion of the packets to be a MAC address of the second interface of the virtual BITW device; and modify the destination MAC address of the at least a portion of the packets to be a MAC address of the second virtual device.

3. The cloud computing network of claim 1, wherein a cloud routing table of the cloud computing network is configured to cause second packets, sent by the second virtual device and destined for a host outside the cloud computing network, to be received by the second interface of the virtual BITW device.

4. The cloud computing network of claim 3, wherein: the second virtual device is configured to send the second packets, wherein the second packets indicate the private IP address of the second virtual device as a source IP address and indicate a public IP address of the host as a destination IP address; and the virtual BITW device is configured to: receive, via the second interface, the second packets; modify the source IP address of the second packets to be the private IP address of the first interface of the virtual BITW device; apply, using the fast path, the packet-filtering logic to the second packets; and send, based on the packet-filtering logic and via the first interface, at least a portion of the second packets to the NAT gateway.

5. The cloud computing network of claim 3, wherein: the second packets sent by the second virtual device indicate a media access control (MAC) MAC address of the second virtual device as a source MAC address and indicate a MAC address of the second interface of the virtual BITW device as a destination MAC address.

6. The cloud computing network of claim 5, wherein the virtual BITW device is configured to: modify the source MAC address of the at least a portion of the second packets to be the MAC address of the first interface of the virtual BITW device; and modify the destination MAC address of the at least a portion of the second packets to be a MAC address of the NAT gateway.

7. The cloud computing network of claim 1, wherein the virtual BITW device is configured to cache 5-tuple values for each of a plurality of packets received by the second interface.

8. The cloud computing network of claim 1, wherein the first subnet and the second subnet are non-overlapping.

9. The cloud computing network of claim 1, wherein a virtual path terminal of the NAT gateway and the first interface of the virtual BITW device are exclusively associated with the first subnet, and wherein a virtual path terminal of the second virtual device and the second interface of the virtual BITW device are exclusively associated with the second subnet.

10. The cloud computing network of claim 1, wherein the packet-filtering logic corresponds to packet-filtering rules.

11. The cloud computing network of claim 1, wherein the packet-filtering logic corresponds to policy enforcement logic.

12. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a cloud computing network, cause the cloud computing network to send packets between a network address translation (NAT) gateway and a second virtual device, via a virtual bump-in-the-wire (BITW) device, by: receiving, by the NAT gateway, packets indicating a public IP address of the second virtual device as a destination IP address, wherein the NAT gateway is configured to interface between a public network and the cloud computing network; modifying, by the NAT gateway, the destination IP address of the packets to be a private IP address of a first interface of the virtual BITW device, wherein the private IP address of the first interface is in a first subnet; sending, by the NAT gateway, the packets to the first interface of the virtual BITW device; receiving, via the first interface, the packets from the NAT gateway; applying, using a fast path of the virtual BITW device, packet-filtering logic to the packets received via the first interface; modifying the destination IP address of the packets to be a private IP address of the second virtual device; and sending, by the virtual BITW, based on the packet-filtering logic, and via a second interface having a private IP address in a second subnet, at least a portion of the packets.

13. The non-transitory computer-readable medium of claim 12, wherein the packets indicate a media access control (MAC) address of the NAT gateway as a source MAC address, and indicate a MAC address of the first interface of the virtual BITW device as a destination MAC address, and wherein the instructions, when executed by the one or more processors, cause the virtual BITW device to further: modify the source MAC address of the at least a portion of the packets to be a MAC address of the second interface of the virtual BITW device; and modify the destination MAC address of the at least a portion of the packets to be a MAC address of the second virtual device.

14. The non-transitory computer-readable medium of claim 12, wherein a cloud routing table of the cloud computing network is configured to cause second packets, sent by the second virtual device and destined for a host outside the cloud computing network, to be received by the second interface of the virtual BITW device.

15. The non-transitory computer-readable medium of claim 14, wherein: the instructions, when executed by the one or more processors, cause the second virtual device to send the second packets, wherein the second packets indicate the private IP address of the second virtual device as a source IP address and indicate a public IP address of the host as a destination IP address; and the instructions, when executed by the one or more processors, cause the virtual BITW device to: receive, via the second interface, the second packets; modify the source IP address of the second packets to be the private IP address of the first interface of the virtual BITW device; apply, using the fast path, the packet-filtering logic to the second packets; and send, based on the packet-filtering logic and via the first interface, at least a portion of the second packets to the NAT gateway.

16. The non-transitory computer-readable medium of claim 14, wherein: the second packets sent by the second virtual device indicate a media access control (MAC) MAC address of the second virtual device as a source MAC address and indicate a MAC address of the second interface of the virtual BITW device as a destination MAC address.

17. The non-transitory computer-readable medium of claim 16, wherein the instructions, when executed by the one or more processors, cause the virtual BITW device to: modify the source MAC address of the at least a portion of the second packets to be the MAC address of the first interface of the virtual BITW device; and modify the destination MAC address of the at least a portion of the second packets to be a MAC address of the NAT gateway.

18. The non-transitory computer-readable medium of claim 12, wherein the instructions, when executed by the one or more processors, cause the virtual BITW device to cache 5-tuple values for each of a plurality of packets received by the second interface.

19. The non-transitory computer-readable medium of claim 12, wherein the first subnet and the second subnet are non-overlapping.

20. The non-transitory computer-readable medium of claim 12, wherein a virtual path terminal of the NAT gateway and the first interface of the virtual BITW device are exclusively associated with the first subnet, and wherein a virtual path terminal of the second virtual device and the second interface of the virtual BITW device are exclusively associated with the second subnet.

21. The non-transitory computer-readable medium of claim 12, wherein the packet-filtering logic corresponds to packet-filtering rules.

22. The non-transitory computer-readable medium of claim 12, wherein the packet-filtering logic corresponds to policy enforcement logic.

23. A method for sending packets in a virtual private cloud network between a network address translation (NAT) gateway and a second virtual device, via a virtual bump-in-the-wire (BITW) device, the method comprising: receiving, by the NAT gateway, packets indicating a public IP address of the second virtual device as a destination IP address, wherein the NAT gateway is configured to interface between a public network and the virtual private cloud; modifying, by the NAT gateway, the destination IP address of the packets to be a first private IP address of a first interface of the virtual BITW device, wherein the private IP address of the first interface is in a first subnet; sending, by the NAT gateway, the packets to the first interface of the virtual BITW device; receiving, via the first interface, the packets from the NAT gateway; applying, using a fast path of the virtual BITW device, packet-filtering logic to the packets received via the first interface; modifying the destination IP address of the packets to be a private IP address of the second virtual device; and sending, by the virtual BITW, based on the packet-filtering logic, and via a second interface having a private IP address in a second subnet, at least a portion of the packets.

24. The method of claim 23, wherein the packets indicate a media access control (MAC) address of the NAT gateway as a source MAC address, and indicate a MAC address of the first interface of the virtual BITW device as a destination MAC address, and wherein the method further comprises: modifying, by the virtual BITW device, the source MAC address of the at least a portion of the packets to be a MAC address of the second interface of the virtual BITW device; and modifying, by the virtual BITW device, the destination MAC address of the at least a portion of the packets to be a MAC address of the second virtual device.

25. The method of claim 23, wherein a cloud routing table of the cloud computing network is configured to cause second packets, sent by the second virtual device and destined for a host outside the cloud computing network, to be received by the second interface of the virtual BITW device.

26. The method of claim 25, further comprising: sending, by the second virtual device, the second packets, wherein the second packets indicate the private IP address of the second virtual device as a source IP address and indicate a public IP address of the host as a destination IP address; receiving, via the second interface of the virtual BITW device, the second packets; modifying, by the virtual BITW device, the source IP address of the second packets to be the private IP address of the first interface of the virtual BITW device; applying, using the fast path, the packet-filtering logic to the second packets; and sending, via the first interface of the virtual BITW device, at least a portion of the second packets to the NAT gateway.

27. A method comprising: deploying a virtual bump-in-the wire (BITW) device in a virtual private cloud network, wherein the virtual BITW device comprises: a first interface having a private Internet Protocol (IP) address in a first subnet; a second interface having a private IP address in a second subnet; and a fast path between the first interface and the second interface and configured to apply packet-filtering logic to traffic received by the virtual BITW device; configuring a network address translation (NAT) gateway, that interfaces between a public network and the virtual private cloud network, to modify a destination IP address of packets destined for a second virtual device by configuring the NAT gateway to translate a public IP address of the second virtual device to the private IP address of the first interface of the virtual BITW device; and configuring the virtual BITW device to send, via the fast path and based on the packet-filtering logic, at least a portion of the packets received via the first interface, to the second virtual device by configuring the virtual BITW device to modify destination IP addresses of packets received by the first interface to be the private IP address of the second virtual device.

28. The method of claim 27, wherein the packets indicate a media access control (MAC) address of the NAT gateway as a source MAC address, and indicate a MAC address of the first interface of the virtual BITW device as a destination MAC address, and wherein the configuring the virtual BITW device to send at least a portion of the packets received via the first interface further comprises configuring the virtual BITW device to: modify the source MAC address of the at least a portion of the packets to be a MAC address of the second interface of the virtual BITW device; and modify the destination MAC address of the at least a portion of the packets to be a MAC address of the second virtual device.

29. The method of claim 27, further comprising configuring a cloud routing table of the cloud computing network to cause second packets, sent by the second virtual device and destined for a host outside the cloud computing network, to be received by the second interface of the virtual BITW device.

30. The method of claim 29, wherein the second packets indicate the private IP address of the second virtual device as a source IP address and indicate a public IP address of the host as a destination IP address, the method further comprising configuring the virtual BITW device to send at least a portion of the second packets received via the second interface by configuring the virtual BITW device to: modify the source IP address of the second packets to be the private IP address of the first interface of the virtual BITW device; apply, using the fast path, the packet-filtering logic to the second packets; and send, via the first interface of the virtual BITW device, at least a portion of the second packets to the NAT gateway.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Some features herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements, and wherein:

[0027] FIGS. 1A and 1B depict illustrative network environments for physical private networks including physical inline BITW devices;

[0028] FIGS. 2A and 2B depict illustrative network environments for virtual private clouds including virtual BITW devices;

[0029] FIG. 3 shows an example block diagram of a process of provisioning, configuring, and operating a virtual BITW device in a private cloud;

[0030] FIG. 4 shows an example architecture of a virtual BITW device;

[0031] FIG. 5 shows an example ladder diagram of packet communications between an Internet host and a private cloud-connected virtual host computer that passes through a virtual BITW device.

[0032] FIG. 6 shows an example computing device that may be used to implement any of the devices, systems, and method described herein.

DETAILED DESCRIPTION

[0033] In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which aspects of the disclosure may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of the disclosure. In addition, reference is made to particular applications, protocols, and embodiments in which aspects of the disclosure may be practiced. It is to be understood that other applications, protocols, and embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of the disclosure. It is to be understood that although the descriptions, figures, and examples reference the IPv4 protocol, the IPv6 protocol and other protocols may be similarly referenced.

[0034] Various connections between elements are discussed in the following description. These connections are general and, unless specified otherwise, may be direct or indirect, wired or wireless, physical or logical (e.g., virtual or software-defined), in any combination. In this respect, the specification is not intended to be limiting.

[0035] As shown in FIG. 2B, when a subscribing enterprise, or other entity such as a private cloud operator, inserts a virtualized version of a physical BITW device C 240 (a virtual BITW) in the virtual path 208 in order to process in-transit packets, device C’s network interfaces C1 241 and C2 242 may have (L3) IP addresses assigned to them so that the underlying private cloud platform not only recognizes the device but also can potentially route packets through the device. However, if the enterprise defines a policy that, for example, requires that all packets comprising communications between computer 260 and any Internet hosts pass through device C 240, the enterprise may not be able to directly enforce the policy because it may not control the routing. For example, the routing protocol may decide that the best path (not shown in FIG. 2B) between NAT-G/W 220 and computer 260 does not pass through device C 240. The enterprise may take measures to possibly guide the routing protocol to route particular packets through device C 240; for example, the enterprise may require that interface C1’s and interface C2’s respective IP addresses be associated with different, non-overlapping subnets to increase the likelihood of the desired routing. For example, in FIG. 2B, interface C1 may be assigned 10.0.1.6 in subnet 10.0.1.0/24, whereas interface C2 may be assigned 10.0.2.7 in subnet 10.0.2.0/24, which does not overlap with interface C1’s associated subnet. Such actions, however, do not guarantee the desired routing, because there may be, for example, a path (not shown in FIG. 2B) between subnet 10.0.1.0/24 and subnet 10.0.2.0/24 that bypasses device C or, for example, the routing may cause packets to route in the wrong direction through device C. Furthermore, even when the routing through device C 240 appears to be working as desired/required, any further changes to the network, e.g. adding, removing, and/or modifying servers, subnets, IP addresses, etc., may cause a reconfiguration of the routing such that the routing of packets through device C 240 no longer meets the enterprise’s desired requirements.

[0036] One approach to supporting IP address and MAC address assignment to network interfaces of (transparent physical) BITW network devices -- so that the devices may be virtualized and provisioned into IaaS providers’ virtual private clouds and may participate in L3 routing and L2 forwarding -- is to revert to using the device OS’s (slow path) TCP/IP network stack logic to process in-transit packets and to configure/determine routing and forwarding information. Thus, the packet-throughput performance gains enabled by transparency and associated fast path packet processing logic in a physical BITW device may be sacrificed to support virtualization of the device. Using the OS’s TCP/IP network stack logic, however, may cause local routing and forwarding information to be automatically configured by the cloud platform’s routing and switching protocols; but, as noted above, this does not necessarily enforce any packet routing policies/requirements for the cloud and may cause further performance reductions.

[0037] As will be described below, the following correlated components may be provided in support of a virtual BITW: (1) a cloud configuration component that may coordinate addressing (e.g., IP and MAC addressing), address translation, proxying, subnetting, and/or routing; and (2) a Network Address Mapper (NAM) logic component that may be inserted (e.g., shimmed) in the Virtual BITW device system such as between the FPPP’s network interface controller (NIC) drivers and the FPPP’s core packet processing logic that may efficiently map L3/IP addresses and L2/MAC addresses of ingressing and/or egressing L3/L2 packets/frames to values that may cause them to be routed/forwarded to intended destinations along a virtual path.

[0038] Referring to FIG. 3, consider first an example cloud configuration component that may be comprised of any of the following interrelated subcomponents: [0039] Configuring the virtual BITW device and associated subnets into a virtual path; [0040] Configuring the NAT gateway and associated proxying; and [0041] Configuring cloud route tables.

[0042] Note that the configuration of the subcomponents may be performed in the context of and in coordination with the private cloud provider’s infrastructure, which may automatically and/or transparently perform functions such as routing and route table generation, MAC address generation and assignment, etc., the operations of which are not shown or described. Note also that the described examples/scenarios are for the simple case of an inline virtual BITW device 240 intermediating between a single virtual host computer (e.g., computer 260), a single Internet gateway (e.g. NAT-G/W 220), and a single Internet host (e.g., HOST-0 110). The methods and systems of the disclosure described herein are readily extended by skilled artisans to more complex scenarios with multiple virtual hosts, Internet hosts, gateways, and virtual BITW devices.

[0043] In FIG. 2A, which represents an example environment before a virtual BITW device has been deployed, the NAT-G/W 220 may be configured to translate between public IP addresses associated with public network 102 (e.g., the public Internet) and private IP addresses associated with a virtual private cloud 204. For example, virtual computer 260 may be associated with the public IP address 174.129.20.63 and with the private IP address 10.0.2.157. Thus, in FIG. 2A, NAT-G/W 220 is depicted as translating 174.129.20.63 to/from 10.0.2.157. The cloud platform provider’s (e.g., IaaS provider’s) routing system may determine a (bi-directional) path 208 through the virtual private cloud 104 between network interface N2 222 (with IP address 10.0.1.1) of the NAT-G/W 220 and Computer 260 (with IP address 10.0.2.157). The IP addresses 10.0.1.1 and 10.0.2.157 and associated network interfaces represent the terminals of path 208.

[0044] Referring to FIG. 3, in Step 3-1, the virtual BITW device may be provisioned, configured, and deployed into a virtual path. Each terminal of the virtual path may be exclusively associated with a subnet and with a network interface of the virtual BITW device. Each such network interface of the virtual BITW device may be assigned an IP address that is in the same subnet as its associated path terminal. The virtual BITW device’s NAM logic may be configured with IP addresses and MAC addresses of the virtual path’s terminals and of the device’s network interfaces. The NAM logic may be configured with information to map packets received by the virtual BITW device’s proxy interface to the virtual host computer(s), or virtual path terminal(s), that are being proxied.

[0045] For example, referring to FIG. 2B, when deploying a virtual BITW device C 240 inline into path 208, the network interface C1 241 may be configured with an IP address, for example 10.0.1.6, that is in the same subnet, for example a /24 subnet, as NAT-G/W 220’s network interface N2 222, which has an IP address 10.0.1.1, and which is one terminal of path 208. C1 241 may be designated as the proxy interface, i.e., C1 241 with IP address 10.0.1.6 may serve as the IP address proxy for virtual computer 260 (with IP address 10.0.2.157). As a matter of convenience, virtual host computer(s) that are being proxied by a virtual BITW device’s network interface may be referred to as “target(s)”. The NAM logic may be configured with this proxy information, which may be used by the NAM logic to map/modify in-transit L3 packets’ IP address field values of 10.0.1.6 to 10.0.2.157. Concurrently, the network interface C2 242 may be configured with an IP address, for example 10.0.2.7, that is in the same subnet, for example a /24 subnet, as target virtual computer 260 (with IP address 10.0.2.157, the other terminal of path 208), but where the subnet containing C2 is different than and non-overlapping with the subnet containing C1. After the network interfaces have been assigned IP addresses, the cloud platform may generate and assign MAC addresses to the interfaces, and update the cloud’s routing tables (using, for example, OSPF and ARP) to incorporate/integrate the newly deployed virtual BITW device 240 into the cloud’s routing configuration. The cloud platform may create and maintain routing tables associated with each network interface in the cloud, which may determine routes between the network interfaces. After the routing tables have been updated, the NAM logic may extract from the routing tables and networking stack any of the following information: the IP and MAC address of the target virtual computer 260; the IP and MAC address of the C1 241 interface (e.g., the proxy for the target virtual computer 260); and/or the MAC address of the NAT-G/W 220 gateway’s network interface that is in the same subnet as C1 241. As described further below, this information may be used by the NAM logic to help ensure that certain (or all) packets comprising communications between Internet hosts and target virtual computer 260 pass through the virtual BITW device 240. This information also may be used to efficiently access routing and forwarding information in accordance with fast-path packet processing, which otherwise may be accessed via the slow-path (i.e., the OS’s TCP/IP networking stack).

[0046] Referring to FIG. 3, in Step 3-2, the NAT gateway that interfaces the private cloud 204 with the public network 102 by translating between the public (e.g., Internet) IP addresses and private (e.g., cloud) IP addresses of virtual host computers may be re-configured to translate the target virtual host computers’ public IP addresses to the private IP address of the proxy interface of the virtual BITW device.

[0047] For example, referring to FIG. 2B, the NAT-G/W 220 may be configured to translate 174.129.20.63, the public IP address of computer 260, to 10.0.1.6, the private IP address of C1 241 instead of 10.0.2.157, the private IP address of target computer 260. In effect, the NAT-G/W 220 has designated network interface C1 as the proxy for target computer 260 (and, as explained above, the virtual BITW’s NAM logic may be configured similarly).

[0048] Referring to FIG. 3, in Step 3-3, the cloud platform’s route tables may be modified/configured/augmented such that outbound packets traversing the virtual path between the path’s terminals, for example, packets sourced/originated by a terminal virtual computer and destined for an Internet host (or other public network host) via the NAT gateway, may be routed from a terminal virtual computer to the non-proxy network interface of the virtual BITW device, and then from the proxy network interface of the virtual BITW device to the NAT gateway that interfaces the private cloud with the public network. Specifically, the route tables may be modified such that: (1) outbound packets leaving the subnet associated with both the terminal virtual computer and the non-proxy interface of the virtual BITW device are directed/forwarded towards the non-proxy interface; and/or (2) outbound packets leaving the subnet associated with both the proxy interface of the virtual BITW and the NAT gateway interface are directed/forwarded towards the NAT gateway interface.

[0049] For example, referring to FIG. 2B, the augmentations to the cloud’s route tables may include (1) an entry that identifies the NAT-G/W 220’s N2 222 interface, which has IP address 10.0.1.1, as the Internet gateway for all outbound packets exiting the subnet 10.0.1.0/24. Note that (1a) this subnet 10.0.1.0/24 includes the C1 241 proxy interface of the virtual BITW device 240, and that (1b) N2 222 is a terminal of virtual path 208. Thus, this entry may help enforce the requirements associated with traversal of virtual path 208. The augmentations to the cloud’s route tables may further include (2) an entry in the route table for the C2 242 interface that identifies the C2 242 interface, which has IP address 10.0.2.7, as the egress point for all outbound packets exiting the subnet 10.0.2.0/24. Note that (2a) this subnet 10.0.2.0/24 includes the target virtual computer 260 (which has IP address 10.0.2.157) and that (2b) virtual computer 260 is a terminal of virtual path 208. Thus, this entry may also help enforce the requirements associated with traversal of virtual path 208.

[0050] Upon completion of Steps 3-1, 3-2, and 3-3, the virtual BITW device may be ready for operation in its virtual path; thus in Step 3-4, the virtual BITW may be transitioned into operation.

[0051] Note that the ordering of Steps 3-1, 3-2, and 3-3 and associated substeps is exemplary and may be different in practice. Moreover, any of these steps may be combined and/or further subdivided.

[0052] Referring to FIG. 4, which represents an example of the virtual BITW device’s logic architecture as a pipeline, consider next the NAM logic component. The NAM may be inserted between the FPPP’s network interface controller (NIC) drivers and the fast path packet processing (FPPP) application logic, where the application may be, for example, network firewalling, network access control, web proxy, TLS proxy, packet security gateway, threat intelligence gateway, IPsec gateway, and/or the like. A purpose of the NAM may be explained in terms of why it may be used in a virtual BITW device but not by a physical BITW device. For example, a version of FIG. 4 for a physical BITW device may differ from FIG. 4 (for the virtual BITW) at least by the NAM logic component.

[0053] The NAM component may provide one or more functions. Examples of these functions may include: [0054] NAM Function 1: For the proxy network interface, maps between the proxy IP address and the target virtual computer’s IP addresses; [0055] NAM Function 2: Configures the IP and MAC addresses of in-transit L3 packets and L2 frames to enforce virtual path traversal policies/requirements; and/or [0056] NAM Function 3: Maintains an efficient data structure, which may be indexed by packets’ flow characteristics, containing information associated with recently observed in-transit frames/packets in order to recover and quickly access routing and forwarding information associated with packets in the same flow that may have been lost during proxying.

[0057] All three (3) NAM functions listed above result from a desire to assign IP addresses and MAC addresses to the virtual BITW device’s network interfaces (C1 and C2 in FIG. 4); whereas by definition, a physical BITW device’s network interfaces are L3- and L2-transparent, and thus there is no need for a NAM.

[0058] Regarding NAM Function 1: Recall from above, for example Step 3-2 of FIG. 3, that the Internet-Cloud NAT gateway may be configured to translate the target virtual computer(s)’s public IP address(es) to the IP address of the proxy interface of the virtual BITW device. Accordingly, for example in Step 3-1 of FIG. 3, the NAM logic may be configured to translate the proxy interface’s IP address to the private IP address(es) of the target virtual computer(s).

[0059] For example, referring also to FIG. 2B, because the interface C1 241 may proxy for target virtual computer 260, when C1 receives a packet with the L3 destination IP address set to C1’s IP address 10.0.1.6, the NAM logic may be configured to change the packet’s destination IP address to target computer 260’s IP address 10.0.2.157, and then forward the packet towards interface C2 via the fast path through the FPPP application logic. Conversely, when C2 receives a packet with the L3 source IP address set to target Computer 260’s IP address 10.0.2.157, the packet may be forwarded via the fast path to the NAM, which may be configured to change the packet’s source IP address to C1’s IP address 10.0.1.6. C1 may then forward the packet towards its destination. If the packet’s destination IP address is an Internet (or other public network) address, then the packet may pass through the NAT-G/W 220, which may translate the packet’s L3 source IP address from C1’s IP address 10.0.1.6 to computer 260’s public IP address 174.129.20.63.

[0060] Regarding NAM Function 2: The network interfaces of the virtual BITW device may be responsible for forwarding packets towards their destinations. The forwarding function may be responsible for causing the MAC addresses of the L2 frames containing the L3 packets to be set to the proper values, for example, the MAC addresses of the terminals of the virtual path. These MAC address values may be obtained from the cloud’s routing tables via the slow path, i.e., via calls to the OS kernel’s TCP/IP networking stack logic; however, for performance reasons, the virtual BITW device may not use the slow path when processing in-transit packets. By configuring the NAM logic with the proper MAC addresses information when configuring the virtual BITW device for operations, for example as in Step 3-1 of FIG. 3, then the forwarding function may obtain MAC address information from the (fast path) NAM instead of the (slow path) OS kernel’s TCP/IP networking stack.

[0061] Regarding NAM Function 3: This function may be used for some cloud configurations where there are, for example, multiple virtual computers that may be proxied by another target virtual computer, e.g., a load balancer, web proxy, etc., with the associated communications passing through the virtual BITW device. For example, suppose there is no NAM Function 3; then, a request packet that is originated by one of multiple virtual computers behind a proxying target virtual computer (e.g., a load balancer) and destined for an Internet host may cause the Internet (or other public network) host to create and transmit a response packet that has the proxying load balancer’s IP address as the destination. Upon receiving the response packet, the load balancer may not know which proxied virtual computer sourced/originated the corresponding request; thus, the load balancer may choose any one of the proxied virtual computers to forward the response packet towards; thus, it may be the case that the chosen proxied virtual computer may not be the originator/source of the corresponding request packet.

[0062] To handle the above example scenario and others, the NAM may include an efficient data structure that stores/caches information on recently observed L3 packets and associated L2 frames, including the packet’s 5-tuple values (L3 source and destination IP addresses, L4 source and destination ports, L3 protocol type), the associated frame’s MAC addresses, and/or the direction. This way, the NAM may be able to handle the example scenario above (and similar scenarios) by recovering the IP address and MAC address of the virtual computer that originated the corresponding request packet and modifying the response packet and associated frame accordingly such that the response packet is ultimately received by the proper virtual computer. Note that in keeping with fast-path performance requirements that may be in place, the efficient data structure, for example an LRU cache, may support efficient insertions, searches, and/or deletions.

[0063] FIG. 5 illustrates an example of a communication between the Internet host HOST-0 110 and the virtual computer 260 in the private cloud that may pass through the virtual BITW device 240 in the virtual path 208. The example network elements represented in FIG. 5 correspond to the example elements and associated configurations represented in FIG. 2B, however the elements in FIG. 5 may correspond to other configurations described herein. Also assume, for example purposes, that the virtual BITW device 240 has been deployed and configured as per Steps 3-1, 3-2, and 3-3 of FIG. 3 and is in an operational mode represented by Step 3-4 of FIG. 3.

[0064] As an example, virtual computer 260 may execute a web server application with a DNS-registered domain name www.example-web-server.net, and HOST-0 110 (addressed by, for example, public IP address 74.65.150.95) may execute a web client/web browser application. A user operating the web browser on HOST-0 110 may point the browser to the URL https://www.example-web-server.net. In Step 5-0 (not shown in FIG. 5), the browser may issue a query to the (Internet) DNS to resolve www.example-web-server.net, and the DNS may respond with the IP address 174.129.20.63.

[0065] In Step 5-1, HOST-0 110 may initiate the establishment of a TCP connection with port 443 (HTTPS) of 174.129.20.63 (i.e., virtual computer 260) by sending an TCP SYN handshake packet P0.0 with L3 source IP address 74.65.150.95 and L3 destination IP address 174.129.20.63 through the Internet towards virtual computer 260.

[0066] In Step 5-2, NAT-G/W 220 may receive packet P0.0. The NAT function may translate computer 260’s public IP address 174.129.20.63 to 10.0.1.6, which may be the (private) IP address of network interface C1 241 of virtual BITW device 240, and which may be the proxy IP address for target virtual computer 260. NAT-G/W 220 may transform packet P0.0 to P0.1 as follows: (1) L3 destination IP address changed to 10.0.1.6 (the IP address of proxy network interface C1 241); (2) L2 source MAC address changed to 12:f7:4c:ac:de:7f (the MAC address of NAT-G/W 220’s network interface N2 222); and (3) L2 destination MAC address changed to 12:3d:f8:07:f0:19 (the MAC address of virtual BITW device 240’s network interface C1 241). Network interface N2 222 may send packet P0.1 towards virtual BITW device 240’s network interface C1 241 on virtual path 208.

[0067] In Step 5-3, virtual BITW device 240 may receive packet P0.1 through its network interface C1 241. As per NAM Function 3 described above, the NAM may insert information associated with packet P0.1 into its efficient data structure for storing information associated with recently observed packets, in case the origin computer information is needed later to recover information that may be lost during the proxy transformations (not illustrated in this example). The NAM may transform packet P0.1 to P0.2 as follows: (1) L3 destination IP address changed to 10.0.2.157 (the IP address of virtual Computer 260); (2) L2 source MAC address changed to 12:a8:84:40:b6:39 (the MAC address of network interface C2 242); and (3) L2 destination MAC address changed to 12:43:9d:b6:7b:f3 (the MAC address of virtual computer 260’s network interface). The NAM may forward/pipeline packet P0.2 towards C2 242. The (fast path) packet processing application processes packet P0.2. Assuming that the application does not drop/block packet P0.2, network interface C2 242 may send packet P0.2 towards virtual computer 260 on virtual path 208.

[0068] In Step 5-4, target virtual computer 260 may receive packet P0.2. Computer 260 may respond to the TCP SYN handshake signal by creating a packet P1.0 containing a TCP SYN-ACK handshake signal and with: (1) L3 source IP address set to 10.0.2.157 (the private IP address of virtual computer 260); (2) L3 destination IP address set to 74.65.150.95 (the IP address of HOST-0 110); (3) L2 source MAC address set to 12:43:9d:b6:7b:f3 (the MAC address of computer 260); and (4) L2 destination MAC address set to 12:a8:84:40:b6:39 (the MAC address of network interface C2 242 of the virtual BITW device 240). Setting packet P1.0’s destination MAC address to C2 242’s MAC address may help ensure that packet P1.0 traverses virtual path 208 through the virtual BITW device 240, even though P1.0’s L3 destination IP address is not the IP address of C2 242. Computer 260 may send/forward packet P1.0 towards HOST-0 110 on virtual path 208.

[0069] In Step 5-5, virtual BITW device 240 may receive packet P1.0 through its network interface C2 242. As per NAM Function 3 described above, the NAM may insert information associated with packet P1.0 into its efficient data structure for storing information associated with recently observed packets, in case the origin computer information is needed later to recover information that may be lost during the proxy transformations (not illustrated in this example). The NAM may transform packet P1.0 to P1.1 as follows: (1) L3 source IP address changed to 10.0.1.6 (the IP address of network interface C1 241, which proxies for computer 260); (2) L2 source MAC address changed to 12:3d:f8:07:f0:19 (the MAC address of network interface C1 241); and (3) L2 destination MAC address changed to 12:f7:4c:ac:de:7f (the MAC address of NAT-G/W 220’s network interface N2 222). Setting packet P1.1’s destination MAC address to N2 222’s MAC address may help ensure that packet P1.1 traverses virtual path 208 to the NAT-G/W 220, even though P1.1’s L3 destination IP address is not the IP address of N2 222. The NAM may forward/pipeline packet P1.1 towards C1 241. The (fast path) packet processing application processes packet P1.1. Assuming that the application does not drop/block packet P1.1, network interface C1 241 may send/forward packet P1.1 towards HOST-0 110 on virtual path 208.

[0070] In Step 5-6, NAT-G/W 220 may receive packet P1.1 through its network interface N2 222, which is a terminal of virtual path 208. The NAT-G/W 220 may transform packet P1.1 to P1.2 as follows: (1) L3 source IP address changed to 174.129.20.63 (the public IP address of virtual computer 260). Network interface N1 221 sends/forwards packet P.1.2 towards HOST-0 110 via the Internet.

[0071] In Step 5-7, a TCP connection and TLS tunnel between HOST-0 110 and virtual Computer 260 (which hosts web site www.example-web-site.net) may be established, and a (TLS-secured) HTTP session (e.g. HTTPS) may be conducted. Upon completion of the HTTP session, the TLS tunnel and the TCP connection may be torn down. All packets composing the communications may traverse the virtual path 208 and transit through the virtual BITW device 240 in both directions.

[0072] Any of the elements described herein or illustrated in any of the figures may be partially or fully implemented using one or more computing devices. Hardware elements of an example computing device 600, which may be used to implement any of the other elements described herein, are shown in FIG. 6. Any of these hardware elements, and/or the computing device 600 itself, may be emulated in a virtual version of computing device 600. Computing device 600 may include one or more processors 601 that may execute computer-readable instructions of a computer program to perform any of the functions or other operations described herein. The instructions, along with other data, may be stored in storage 602, which may include, for example, memory such as read-only memory (ROM) and/or random access memory (RAM), a hard drive, a magnetic or optical disk, a Universal Serial Bus (USB) drive, and/or any other type of computer-readable media. Computing device 600 may also include a user interface 604 for interfacing with one or more input devices 605 such as a keyboard, mouse, voice input, etc., and for interfacing with one or more output device 606 such as a display, speaker, printer, etc. Computing device 600 may also include a network interface 603 for interfacing with one or more external devices that may be part of a network external to computing device 600. Although FIG. 6 shows an example hardware configuration, one or more of the elements of computing device 600 may be implemented as software or a combination of hardware and software. Modifications may be made to add, remove, combine, divide, etc. components of computing device 600. Additionally, the elements shown in FIG. 6 may be implemented using basic computing devices and components that have been configured to perform operations such as are described herein. Processor(s) 601 and/or storage 602 may also or alternatively be implemented through one or more Integrated Circuits (ICs). An IC may be, for example, a microprocessor that accesses programming instructions or other data stored in a ROM and/or hardwired into the IC. For example, an IC may comprise an Application Specific Integrated Circuit (ASIC) having gates and/or other logic dedicated to the calculations and other operations described herein. An IC may perform some operations based on execution of programming instructions read from ROM or RAM, with other operations hardwired into gates or other logic.

[0073] The functions and steps described herein may be embodied in computer-usable data or computer-executable instructions, such as in one or more program modules, executed by one or more computing devices (e.g., computers or other data-processing devices) to perform one or more functions described herein. Generally, program modules may include routines, programs, objects, components, data structures, and/or other elements that perform particular tasks or implement particular abstract data types when executed by one or more processors of one or more computing devices. The computer-executable instructions may be stored on a computer-readable medium such as a hard disk, optical disk, removable storage media, solid-state memory, RAM, etc. As will be appreciated, the functionality of the program modules may be combined or distributed as desired. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the disclosure, and such data structures are contemplated to be within the scope of computer-executable instructions and computer-usable data described herein.

[0074] Although not required, one of ordinary skill in the art will appreciate that various aspects described herein may be embodied as a method, system, apparatus, or one or more computer-readable media storing computer-executable instructions that, when executed by one or more processors of a computing device, cause the computing device to perform steps as disclosed herein. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, an entirely firmware embodiment, an entirely virtual embodiment, or an embodiment combining software, hardware, virtualized, and/or firmware aspects in any combination.

[0075] As described herein, the various methods and acts may be operative across one or more physically separate or integrated computing devices (which together may form a computing device) and networks. The functionality may be distributed in any manner or may be located in a single physical computing device or virtual version of a computing device (e.g., a server, client computer, a user device, a virtual environment, or the like).

[0076] Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications, and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the illustrative figures may be performed in other than the recited order and that one or more illustrated steps may be optional.