Physical Interfaces in the properties of a Virtual Firewall represent interfaces allocated to the Virtual Firewall in the Master Engine. All communication between Virtual Firewalls and the SMC is proxied by the Master Engine.
Physical Interfaces for the Virtual Firewall are automatically created based on the interface configuration in the Master Engine properties. The number of Physical Interfaces depends on the number of interfaces allocated to the Virtual Firewall in the Master Engine. You can optionally modify the automatically-created Physical Interfaces.
In addition to the automatically-created Physical Interfaces, you can add the following types of interfaces to Virtual Firewalls:
•You can add VLAN Interfaces if the creation of VLAN Interfaces for Virtual Firewalls is enabled in the Master Engine Properties.
•You can optionally add Tunnel Interfaces for the Route-Based VPN.
Both IPv4 and IPv6 addresses are supported on Virtual Firewalls. You can define one or more static IP addresses for Virtual Firewall interfaces.
You can optionally add loopback IP addresses to the Virtual Firewall. Loopback IP addresses allow you to assign IP addresses that do not belong to any directly-connected networks to the Virtual Firewall. Loopback IP addresses are not connected to any physical interface and they do not create connectivity to any network. Any IP address that is not already used on another Physical or VLAN interface in the same Virtual Firewall can be used as a loopback IP address.
The same IP address can be used as a loopback IP address and as the IP address of a Tunnel Interface. Loopback IP addresses can be used as the Identity for Authentication Requests, the Source for Authentication Requests, and the Default IP Address for Outgoing Traffic.
By default, the interface definitions for the Virtual Firewall are mapped to interfaces on the Master Engine in the order in which the interfaces are created on the Master Engine.
Task 6: Install a Firewall Policy
After you have modified Physical Interfaces or VLAN Interfaces in the Master Engine properties, you must install or refresh the policy on the Master Engine to transfer changes. After you have modified Physical Interfaces or VLAN Interfaces in the Virtual Firewall properties, you must install or refresh the policy on the Virtual Firewall to transfer the changes.
There is no separate type of policy for Master Engines and Virtual Firewalls. Master Engines and Virtual Firewalls use Firewall Policies. You can install different Firewall Policies on the Master Engine and on the Virtual Firewalls. You can also install a different Firewall Policy on each Virtual Firewall.
Using Master Engines and Virtual Firewalls
The main points of Master Engine and Virtual Firewall configuration are explained in the preceding sections of this chapter. This section illustrates some additional concepts for working with Master Engines and Virtual Firewalls:
•Moving a Virtual Firewall to a Different Master Engine
•Using Master Engines and Virtual Firewalls With Domains
Moving a Virtual Firewall to a Different Master Engine
The Virtual Resource selected in the properties of a Virtual Firewall element determines the Master Engine to which the Virtual Firewall belongs. To move a Virtual Firewall to a different Master Engine, you select a Virtual Resource that is associate with a different Master Engine in the Virtual Firewall properties. The move becomes effective when you refresh the policy on the Master Engine.
Using Master Engines and Virtual Firewalls With Domains
If there are multiple administrative Domains, Virtual Firewalls associated with the same Master Engine can belong to different Domains. However, the Master Engine must either belong to the Shared Domain or to the same Domain as the associated Virtual Firewalls. For example, the Master Engine can belong to the Shared Domain, while each associated Virtual Firewall belongs to a different Domain.
70 Chapter 7 Master Engine and Virtual Firewall Configuration
Example of Master Engine and Virtual Firewall Deployment
The example in this section illustrates the configuration of Master Engines and Virtual Firewalls with general steps on how the scenario is configured.
Deploying Virtual Firewalls for MSSP Customers
Company A is an MSSP (Managed Security Services Provider). Customer 1 and Customer 2 are customers of Company A. The customers each want one Virtual Firewall with two Physical Interfaces. The administrators at Company A decide to use their existing NGFW appliance as a Master Engine to host Virtual Firewalls for Customer 1 and Customer 2. Separate administrative Domains have already been configured for each customer. The engine already has a license that allows the creation of Virtual Resources.
The administrators at Company A:
1. Create a Master Engine element in the Shared Domain.
2. Create one Virtual Resource element for each customer’s Virtual Firewall and select the appropriate Domain for each Virtual Resource:
3. Create the following Physical Interfaces on the Master Engine:
4. Add an IPv4 address for each Master Engine node to Physical Interface 0.
Virtual Resource Name Domain Customer 1 Virtual Resource Customer 1 Domain Customer 2 Virtual Resource Customer 2 Domain
Interface ID Description
0 Physical Interface for the Master Engine’s own traffic.
1 Physical Interface for hosted Virtual Firewall traffic.
5. Add the following VLAN Interfaces to Physical Interface 1 and select the appropriate Virtual Resource for each VLAN Interface:
6. Create a Virtual Firewall element for each customer and select the appropriate Virtual Resource for each Virtual Firewall:
7. Add IP addresses to the Physical Interfaces on the Virtual Firewalls.
8. Refresh the policy on the Master Engine.
9. Refresh the policy on the Virtual Firewalls.
Interface ID Virtual Resource Description VLAN 1.1 Customer 1 Virtual
Resource
VLAN Interface for the first Physical Interface on the Virtual Firewall for Customer 1.
VLAN 1.2 Customer 1 Virtual Resource
VLAN Interface for the second Physical Interface on the Virtual Firewall for Customer 1.
VLAN 1.3 Customer 2 Virtual Resource
VLAN Interface for the first Physical Interface on the Virtual Firewall for Customer 2.
VLAN 1.4 Customer 2 Virtual Resource
VLAN Interface for the second Physical Interface on the Virtual Firewall for Customer 2.
Virtual Firewall Virtual Resource Customer 1 Virtual Firewall Customer 1 Virtual Resource Customer 2 Virtual Firewall Customer 2 Virtual Resource
72 Chapter 7 Master Engine and Virtual Firewall Configuration
C H A P T E R 8
R OUTING AND A NTISPOOFING
Routing is the process of defining through which network interface the engine forwards traffic from a source address to a destination address. Antispoofing is the process of defining which addresses are considered valid source addresses for the network(s) connected to each interface.
The following sections are included:
Overview to Routing and Antispoofing (page 74)
Configuration of Routing and Antispoofing (page 74)
Using Routing and Antispoofing (page 78)
Examples of Routing (page 79)
74 Chapter 8 Routing and Antispoofing
Overview to Routing and Antispoofing
In addition to examining packets, Firewalls, Master Engines, and Virtual Firewalls must determine how to route packets. For the most part, the SMC automates the routing and antispoofing configuration. Much of the configuration is generated automatically based on the IP addresses of the network interfaces. Routing and antispoofing for Master Engines are
configured in the same way as routing and antispoofing for Firewall Clusters. Routing and antispoofing for Virtual Firewalls are configured in the same way as routing and antispoofing for Single Firewalls.
Configuration of Routing and Antispoofing
The routing and antispoofing information is displayed and configured graphically in interface-based trees in the Routing view and Antispoofing view. The routing information is stored on the Management Server. The information is transferred to the engines when the policies are installed or refreshed.
In addition to the routing information that is automatically generated based on the interface definitions, you must manually add any networks that are not directly connected to the engine to the routing tree. Similarly, you must also add a default route for packets whose destination IP address is not included anywhere else in the routing tree.
IP address spoofing is an attack where the source IP address in a packet is modified to gain unauthorized access or to cause a denial-of-service (DoS). Such attacks can be prevented with antispoofing rules. The antispoofing configuration is generated automatically based on the routing tree. Antispoofing is always enforced on all interfaces. You can change the antispoofing configuration, but in most environments, there is no need to do so.
New Networks are automatically added to routing when you change the engine’s interface properties. However, none of the Networks are automatically removed, so you must check your Routing view for obsolete entries and clear them manually. This is to prevent the system from removing currently unused route definitions that you may want to reuse or keep for easy rollback to previous definitions. All additions and deletions in the Routing view are automatically reflected in the Antispoofing view. Manual definitions in the Antispoofing view are preserved regardless of routing changes.
Reading the Routing and Antispoofing Trees
The Routing view automatically displays the interfaces and a Network element for each network that is directly connected to the engine. The Network is created based on the IP address(es) that you define for each interface. Interfaces that belong to an aggregated link always share the same routing information. Only the first interface that belongs to the aggregated link is
displayed in the Routing and Antispoofing views.
When the engine reads routing definitions, it selects the most specific route and antispoofing definition it finds for each packet. The engine first checks if there is a route defined for the specific destination IP address of the packet (a Host element), then checks routes to the defined networks (a Network element), and finally uses the default route (the Any Network element) if none of the other routes match the packet’s destination address. If there are overlapping definitions, the more specific one is considered first.
Example Interface 1 has a Host element for 192.168.0.202 and Interface 2 has a Network element for 192.168.0.0/24, a packet to 192.168.0.202 is routed through Interface 1, and the Interface 2 definition is not considered for those packets at all.
Illustration 8.1 Example: The More Specific Destination is Considered First in Routing
Interface 1 is always used for a destination of 192.168.0.202 because it has a Host element with the most specific address under it.
The Antispoofing view defines the source addresses of traffic that are considered valid (not spoofed) for each interface. If an interface receives a packet with a source address that is not a valid address for the network(s) connected to that interface, the packet is discarded. This is the case, for example, when an external interface receives a packet with an internal source. The engine selects the most specific antispoofing definition it finds for each packet.
Example In the Antispoofing tree automatically generated based on the routing example above, antispoofing discards any traffic with the address 192.168.0.202 if it originates from Interface 2, because it has the less specific definition for that address (the Network 192.168.0.0/24).
Illustration 8.2 Only The Most Specific Destination is Considered Valid in Antispoofing
Packets from Example Host (192.168.0.202) are only considered valid if they originate from Interface 1, because it has the most specific route to the host’s address.
Example To allow the traffic to originate from both interfaces, you would also have to add the Host
76 Chapter 8 Routing and Antispoofing
Illustration 8.3 Both Interfaces are Considered Valid
Both Interface 1 and Interface 2 are considered valid routes to Example Host (192.168.0.202) because the Host element is included under both interfaces.
Multi-Link Routing
Multi-Link uses multiple network links (NetLinks) to balance the load of outbound traffic and ensure high availability of Internet connectivity. With each new outbound connection, the system selects the fastest route for the connection from the available NetLinks. Multi-Link routing can be used for both IPv4 and IPv6 traffic. See Outbound Traffic Management (page 225) for more information on Multi-Link for outbound connections.
Illustration 8.4 NetLinks in Routing View
In the illustration above, a Multi-Link configuration is used to define a default route to the Internet (to “Any network”) through the ISP A and ISP B NetLinks. Separate network interfaces can be used for each NetLink, which is recommended for the Multi-Link configuration. It is also possible to configure multiple NetLinks for a single network interface. However, this is not recommended, as configuring multiple networks on the same interface introduces a single point of failure.
For each NetLink, a range of IP addresses is defined for NATing the source IP address of an outbound connection that goes through the NetLink. A NAT rule in the Firewall Policy defines the Outbound Multi-Link element that is used for Multi-Link outbound connections.
Default Elements
Networks that correspond to the IP addresses of each interface are automatically added to the routing and antispoofing configurations of Firewall, Master Engine, and Virtual Firewall
elements.
The system includes a default network element called Any network, which is needed to define the default route. The system also includes a Host element for Bootp/DHCP clients in the Antispoofing view for Firewall, Master Engine, and Virtual Firewall elements.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the McAfee SMC Administrator’s Guide.