Virtual Firewall elements store the configuration information related to the Virtual Firewalls. Selecting a Virtual Resource for the Virtual Firewall automatically adds the Virtual Firewall to the
Task 5: Configure Virtual Firewall Interfaces
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 the following types of IP addresses for Virtual Firewall interfaces:
•A Physical Interface can have one or more static IP addresses.
•A Tunnel Interface can have one or more static IP addresses.
You can optionally add loopback IP addresses to allow the Virtual Firewall to communicate with itself. 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. If
necessary, you can change the mapping between Virtual Firewall interface numbers and Master Engine interfaces in the properties of the Virtual Resource that is associated with the Virtual Firewall and the Master Engine.
Task 6: Install a Firewall Policy
After you have modified Physical Interfaces, VLAN Interfaces, or interface mapping for Virtual Firewalls 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.
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.
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 Security Engine 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 Security Engine already has a license that includes the Virtual Firewall feature.
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.
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 Description
0 Physical Interface for the Master Engine’s own traffic. 1 Physical Interface for hosted Virtual Firewall traffic.
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
CHA PT E R 8
ROUTING
AND ANTISPOOFING
Routing is the process of defining through which network interface the Firewall 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 70)
Configuration of Routing and Antispoofing (page 70)
Using Routing and Antispoofing (page 74)
Overview to Routing and Antispoofing
In addition to examining packets, a firewall has to 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.
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 firewalls when the firewall 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 firewall 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 firewall’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 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 firewall. 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 firewall reads routing definitions, it selects the most specific route and antispoofing definition it finds for each packet. The firewall 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 of a Single Firewall and Firewall Cluster element. 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 firewall 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 element for 192.168.0.202 under Interface 2, so that the definitions are equally specific (both interfaces contain the Host element) and therefore both definitions are valid at the same time.
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 for Single and Clustered Firewalls
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 223) 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 on the Firewall element 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 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 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 Stonesoft
Administrator’s Guide.