Communication Between Virtual Systems

There are two typical scenarios where communication between virtual systems (inter- vsys traffic) is desirable. In a multi-tenancy environment, communication between virtual systems can occur by having traffic leave the firewall, go through the Internet, and re-enter the firewall. In a single organization environment, communication between virtual systems can remain within the firewall. This section discusses both scenarios.

Inter-VSYS Traffic That Must Leave the Firewall

An ISP that has multiple customers on a firewall (known as multi-tenancy ) can use a virtual system for each customer, and thereby give each customer control over its virtual system configuration. The ISP grants vsysadmin permission to customers. Each customer’s traffic and management are isolated from the others. Each virtual system must be configured with its own IP address and one or more virtual routers in order to manage traffic and its own connection to the Internet.

If the virtual systems need to communicate with each other in a multi-tenancy setup managed by the ISP, that traffic typically goes out the firewall to another Layer 3 routing device (like the Internet) and back to the firewall, even though the virtual systems exist on the same physical firewall, as shown in the following figure.

Diagram illustrating inter-VSYS traffic leaving the firewall (via Internet/External Router) and re-entering for communication between two VSYS in a multi-tenancy scenario.

Mermaid Diagram: Multi-Tenancy Inter-VSYS Traffic Flow

Simplified flow showing traffic leaving the firewall to communicate between VSYS A and VSYS B in a multi-tenancy setup.

Inter-VSYS Traffic That Remains Within the Firewall

Unlike the preceding multi-tenancy scenario, virtual systems on a firewall can be under the control of a single organization. The organization wants to both isolate traffic between virtual systems and allow communications between virtual systems. This common use case arises when the organization wants to provide departmental separation and still have the departments be able to communicate with each other or connect to the same network(s). In this scenario, the inter- vsys traffic remains within the firewall, as described in the following topics:

• External Zone
• External Zones and Security Policies For Traffic Within a Firewall
• Inter-VSYS Communication Uses Two Sessions

This scenario is common in enterprise deployments where internal segmentation is needed using VSYS, but communication between segments is also required without exiting the physical firewall.

External Zone

The communication desired in the single-organization use case is achieved by configuring security policies that point to or from an external zone. An external zone is a security object that is associated with a specific virtual system that it can reach; the zone is external to the virtual system. A virtual system can have only one external zone, regardless of how many security zones the virtual system has within it. External zones are required to allow traffic between zones in different virtual systems, without the traffic leaving the firewall.

The virtual system administrator configures the security policies needed to allow traffic between two virtual systems. Unlike security zones, an external zone is not associated with an interface; it is associated with a virtual system. The security policy allows or denies traffic between the security (internal) zone and the external zone.

Because external zones do not have interfaces or IP addresses associated with them, some zone protection profiles are not supported on external zones.

Remember that each virtual system is a separate instance of a firewall, which means that each packet moving between virtual systems is inspected for security policy and App-ID evaluation.

Mermaid Diagram: External Zone Concept

Illustrating the concept of an External Zone as a representation of reachability to another VSYS, rather than an interface.

External Zones and Security Policies For Traffic Within a Firewall

In the following example, an enterprise has two separate administrative groups: the departmentA and departmentB virtual systems. The following figure shows the external zone associated with each virtual system, and traffic flowing from one trust zone, out an external zone, into an external zone of another virtual system, and into its trust zone.

Diagram illustrating inter-VSYS traffic staying within the firewall using external zones for communication between two VSYS in a single-organization scenario.

To create external zones, the firewall administrator must configure the virtual systems so that they are visible to each other. External zones do not have security policies between them because their virtual systems are visible to each other.

To communicate between virtual systems, the ingress and egress interfaces on the firewall are either assigned to a single virtual router or else they are connected using inter-virtual router static routes. The simpler of these two approaches is to assign all virtual systems that must communicate with each other to a single virtual router .

There might be a reason that the virtual systems need to have their own virtual router, for example, if the virtual systems use overlapping IP address ranges . Traffic can be routed between the virtual systems, but each virtual router must have static routes that point to the other virtual router(s) as the next hop.

Referring to the scenario in the figure above, we have an enterprise with two administrative groups: departmentA and departmentB . The departmentA group manages the local network and the DMZ resources. The departmentB group manages traffic in and out of the sales segment of the network. All traffic is on a local network, so a single virtual router is used. There are two external zones configured for communication between the two virtual systems. The departmentA virtual system has three zones used in security policies: deptA -DMZ, deptA -trust, and deptA -External. The departmentB virtual system also has three zones: deptB -DMZ, deptB -trust, and deptB -External. Both groups can control the traffic passing through their virtual systems.

In order to allow traffic from deptA -trust to deptB -trust, two security policies are required. In the following figure, the two vertical arrows indicate where the security policies (described below the figure) are controlling traffic.

Diagram showing traffic flow requiring two security policies for communication between VSYS A and VSYS B within the same firewall.

• Security Policy 1 : In the preceding figure, traffic is destined for the deptB -trust zone. Traffic leaves the deptA -trust zone and goes to the deptA -External zone. A security policy must allow traffic from the source zone ( deptA -trust) to the destination zone ( deptA -External). A virtual system allows any policy type to be used for this traffic, including NAT.
  • No policy is needed between external zones because traffic sent to an external zone appears in and has automatic access to the other external zones that are visible to the original external zone.
• Security Policy 2 : In the preceding figure, the traffic from deptB -External is still destined to the deptB -trust zone, and a security policy must be configured to allow it. The policy must allow traffic from the source zone ( deptB -External) to the destination zone ( deptB -trust).

The departmentB virtual system could be configured to block traffic from the departmentA virtual system, and vice versa. Like traffic from any other zone, traffic from external zones must be explicitly allowed by policy to reach other zones in a virtual system.

In addition to external zones being required for inter-virtual system traffic that does not leave the firewall, external zones are also required if you configure a Shared Gateway , in which case the traffic is intended to leave the firewall.

Mermaid Diagram: Policies for Internal Inter-VSYS Traffic

Flow illustrating the two security policies required for communication between deptA-trust (VSYS A) and deptB-trust (VSYS B) using external zones.

Inter-VSYS Communication Uses Two Sessions

It is helpful to understand that communication between two virtual systems uses two sessions, unlike the one session used for a single virtual system. Let’s compare the scenarios.

Scenario 1 (Intra-VSYS) —Vsys1 has two zones: trust1 and untrust1. A host in the trust1 zone initiates traffic when it needs to communicate with a device in the untrust1 zone. The host sends traffic to the firewall, and the firewall creates a new session for source zone trust1 to destination zone untrust1. Only one session is needed for this traffic.

Scenario 2 (Inter-VSYS) —A host from vsys1 needs to access a server on vsys2. A host in the trust1 zone initiates traffic to the firewall, and the firewall creates the first session: source zone trust1 to destination zone untrust1. Traffic is routed to vsys2, either internally or externally. Then the firewall creates a second session: source zone untrust2 to destination zone trust2. Two sessions are needed for this inter-vsys traffic.

Mermaid Diagram: Session Comparison

Sequence diagram comparing session creation for traffic within a VSYS (1 session) versus traffic between VSYS (2 sessions).

Configure Inter-Virtual System Communication within the Firewall

Perform this task if you have a use case, perhaps within a single enterprise, where you want the virtual systems to be able to communicate with each other within the firewall. Such a scenario is described in Inter-VSYS Traffic That Remains Within the Firewall . This task presumes:

• You completed the task, Configure Virtual Systems .
• When configuring the virtual systems, in the Visible Virtual System field, you checked the boxes of all virtual systems that must communicate with each other to be visible to each other.

1. Configure an external zone for each virtual system.
   1. Select Network>Zones and Add a new zone by Name .
   2. For Location , select the virtual system for which you are creating an external zone.
   3. For Type , select External .
   4. For Virtual Systems , click Add and enter the virtual system that the external zone can reach.
   5. ( Optional ) Select a Zone Protection Profile (or configure one later) that provides flood, reconnaissance, or packet-based attack protection.
   6. ( Optional ) In Log Setting , select a log forwarding profile for forwarding zone protection logs to an external system.
   7. ( Optional ) Select Enable User Identification to enable User-ID for the external zone.
   8. Click OK .
2. Configure the Security policy rules to allow or deny traffic from the internal zones to the external zone of the virtual system, and vice versa.
   • See Create a Security Policy Rule .
   • See Inter-VSYS Traffic That Remains Within the Firewall .
3. Commit your changes.

   Click Commit .

Interactive Quiz: Virtual Systems Communication

Test your knowledge on communication between virtual systems.