Next Generation Network
Design Guide
McAfee Next Generation Firewall
Design and Implementation Guide
INTRODUCTION 4
Purpose of This Document ...4
Audience ...4
Resources ...4
SOLUTION OVERVIEW 5 Enterprise Requirements ...5
Managed Service Provider Requirements ...6
Use Cases ...7
SOLUTION DESIGN 8 Architecture ...8
Equipment ...9
Network ... 10
McAfee Security Management Center ... 10
USE CASE 1: USER-BASED APPLICATION CONTROL 12 Design ... 12
Additional Resource: Video ... 12
Configuration ... 13
Validation ... 15
Test Case 1: Allow Individual Access to Services ... 15
Test Case 2: Prohibit Individual Access to Services ... 18
Test Case 3: Allow Group Access to Services ... 20
Test Case 4: Prohibit Group Access to Services ... 22
USE CASE 2: REMOTE CLIENT-TO-SITE VPN 24 Design ... 24
Additional Resource: Video ... 25
Configuration ... 25
VPN Gateway and VPN Client Configuration in McAfee Security Management Center ... 25
VPN Policy on Firewall... 26
Validation ... 28
Test Case 1: User Authentication ... 28
Test Case 2: Remote User Policy ... 31
USE CASE 3: SITE-TO-SITE VPN 33 Design ... 33
Configuration ... 34
Design ... 38 Configuration ... 41 Validation ... 46
USE CASE 5: HIGH AVAILABILITY—McAFEE MULTI-LINK 47
Design ... 47 Configuration ... 50 Validation ... 53
GETTING SUPPORT 54
Evaluating McAfee Next Generation Firewall ... 54 McAfee Next Generation Firewall Customers ... 54
INTRODUCTION
Purpose of This Document
The McAfee® Next Generation Firewall Design and Implementation Guide provides best practice designs and configuration steps for some of the most common use cases that enterprises will encounter.
The recommendations and examples have been validated on a live network within our lab at McAfee. Our lab is designed to simulate a typical customer network environment. Our customers may use these recommendations to implement similar configurations in their environments. These examples may also be used by our own McAfee system engineers, architects, and professional services teams to create customer proof-of-concepts (POCs). Each use case will provide an overview of the management requirements, best practice design, configuration steps, and validation examples. Some use cases also include an optional technical video that describes the use case. After familiarizing yourself with the Solution Design section, you may choose to skip to the use case you are interested in. You are not required to review the use cases sequentially.
Audience
This guide is intended for technical personnel who need to deploy and/or manage a McAfee Next Generation Firewall in a live network, test environment, or for a product evaluation.
Resources
To learn more about the McAfee Next Generation Firewall, find additional documentation, download a product evaluation, or to get product support, please visit our website at www.mcafee.com/ngfw.
Product documentation
Product evaluation
Evader test tool
McAfee Security Management Center Architecture and Configuration video
In May 2013, Stonesoft became part of McAfee, which is a wholly owned subsidiary of Intel Corporation and part of the Intel Security Group. Throughout this document, you may see pictures of software with the name “Stonesoft” shown, but the products will be referred to as a McAfee product. Regardless of whether you are buying a new solution or if you already own Stonesoft-branded products, the guidance provided in this document applies.
SOLUTION OVERVIEW
This section provides a brief overview of McAfee Next Generation Firewall, the business problems it can solve, and the environments the use cases presented in this guide are best suited to address.
Enterprise Requirements
Conditions continually change with time. Enterprise networks that are still protected by traditional firewalls or early next-generation firewalls are seeing new attack patterns, like advanced evasion techniques (AETs), successfully pass through the security controls and policies they have implemented.
To test your organization’s network security against AETs, McAfee offers a free software-based testing environment called “Evader.” Visit evader.mcafee.com for more details on AETs and the Evader tool.
Most enterprises cannot afford to have downtime due to a firewall failure. Today, there is an urgent need for a next-generation firewall that offers more than just deep traffic inspection. Enterprises are looking for next-next-generation firewalls that include protection against AETs with anti-evasion technology, offer high availability for zero downtime, and provide granular application control.
As a result of extensive research into the latest attacks, McAfee Next Generation Firewall was developed as a means of identifying and stopping advanced evasion techniques beyond any competitor’s capability. It enables enterprises to do business securely and cost effectively. It offers continuous protection against advanced threats, powerful management tools that enable operational efficiency, full situational awareness, and high availability to support business continuity. McAfee Next Generation Firewall has been built from the ground up to deliver application control, intrusion prevention system (IPS), and virtual private network (VPN) functionality—as well as innovative evasion prevention capabilities in an extensible, highly scalable design. Offering more than just deep packet inspection, McAfee Next Generation Firewall includes powerful anti-evasion technologies that decode and normalize network traffic for inspection on all protocol layers, making traffic evasion-free and exploits more easily detectable. Vulnerability-based fingerprints block exploits in the normalized data stream.
As part of the Security Connected framework, McAfee Next Generation Firewall offers a holistic network security solution combining network and endpoint intelligence. For maximum return on investment and an extended lifecycle, McAfee Next Generation Firewall is based on a unified software core, which is available in multiple, adaptive hardware, software, and virtual appliances, and is transformable into different network security roles.
McAfee Next Generation Firewall offers your organization the security and control you need:
Granular application control.
Unified software design.
Advanced evasion prevention.
High availability.
Centralized management.
Flexible delivery.
This guide and its use cases are focused on real-world deployments of McAfee Next Generation Firewall and typical management activities such as configuring VPN services, using application control, and designing for high availability. For more information about McAfee Next Generation Firewall and its protection against AETs, unified software design, management platform, supported configurations, and form factors for scale, virtualization, and multitenancy, visit our product website at www.mcafee.com/ngfw.
McAfee Firewall Enterprise and the McAfee Next Generation Firewall both have features and benefits that meet the needs of different customer environments. McAfee Firewall Enterprise meets the hardened, high-assurance requirements typical of national and other government entities. McAfee Next Generation Firewall offers enterprises, service providers, and data center teams adaptive, advanced security in a cost-effective solution.
Managed Service Provider Requirements
The continually evolving threat landscape and its technologies have also resulted in a short supply of specialists possessing the needed skill sets to address it; concerns about ongoing investments in new solutions like the next-generation firewall to keep pace with it; and an overall business need in shifting the corresponding IT budgets from a capital expenditures (CapEx) to an operational expenditures (OpEx) model.
MSPs are stepping in to answer this need by offering a variety of services that provide enterprises with the ability to both keep pace and contain costs. For example:
Managed security services where the enterprise may own their equipment, but a provider manages it.
Managed on-premises services where the MSP may both own and manage the equipment at their customers’ sites.
Dedicated or hosted multitenant services where the security device is located with, owned, and often
managed by the provider offering remote, dedicated, or cloud-based delivery of services (Security-as-a-Service).
Firewall-as-a-Service (FWaaS) as part of a larger Infrastructure-as-a-Service (IaaS) solution for private-hosted or hybrid cloud environments.
Securing Software-as-a-Service (SaaS) where a provider is actually securing its own data center that delivers applications in a cloud-based delivery model.
Whether you are a service provider using McAfee Next Generation Firewall to deliver services or to secure other services you may deliver, or whether you are an enterprise that is considering working with a provider, your requirements are likely to be the same as general enterprise requirements (previous section), with an added focus on:
Multitenancy.
Domain, role, web-based, automated and API-accessible management.
Scalable, high-performance, and high-availability platforms.
McAfee Next Generation Firewall is an ideal solution for MSPs interested in offering managed services, and the enterprises that are interested in working with them. It offers both platform and management console multitenancy. An individual appliance can support up to 250 virtual contexts, while the centralized console can separate administrative domains with customized web portal access. This allows MSPs to manage each customer separately and provides enterprises the visibility and option to maintain shared responsibility with their providers or across their own IT organizations. Automated plug-and-play deployment and policy management and a wide range of both physical and virtual appliances offer MSPs and enterprises the ability to select the right platform and configuration to meet their requirements and service models.
The use cases in this guide apply best to services that MSPs offer on premises or for remote management of appliances that are located physically at the enterprise site. Essentially, the same configuration steps apply whether an MSP deploys on premises and manages the solution onsite or remotely or an enterprise customer purchases and manages the solution on its own. The main difference is in the ability of the MSP to use an offsite, multitenant McAfee Security Management Center to provide remote management for multiple customers and provide each customer with the option to view and/or maintain management of their security services.
For more information:
Enterprises interested in working with an MSP, please visit our Partner Directory at http://www.mcafee.com/us/partners/mssp/msp-partner-dir.aspx.
MSPs interested in offering McAfee Next Generation Firewall as a managed service, please visit our website at www.mcafee.com/msp.
Use Cases
The overall solution and design example offered in this guide is illustrated through five use cases: 1. User-Based Application Control.
2. Client-to-Site VPN. 3. Site-to-Site VPN.
4. High Availability–Clustering. 5. High Availability–McAfee Multi-Link.
Each use case describes the basic management requirement it addresses, how the solution is designed, and how it is configured and implemented and offers examples or recommendations on how to validate that your configuration works as intended. Some use cases also offer a supplemental video for additional reference. After reviewing the Solution Design section, you may want to skip directly to the use case and sections you are interested in.
SOLUTION DESIGN
This section provides a brief overview of how we have created our lab network, which is used for the configuration and validation examples provided for the use cases in this guide. This design is intended for instructional purposes only, and it is assumed the technical personnel using this guide will adjust the recommendations provided to meet their own requirements and work within each unique environment.
Architecture
In Figure 1, we have an internal, private network and branch office protected by McAfee Next Generation Firewall. Remote users can connect to the main, private network through a VPN gateway, which is built into McAfee Next Generation Firewall.
Equipment
The table below represents the products used within our simulated lab environment, depicted in Figure 1, and the versions of software installed. Always refer to the product documentation for specifics on supported platforms, configurations, and operating systems.
Table 1: Design Example Equipment Configuration
Product Hardware or Operating System Units Software Version
McAfee Next Generation Firewall
1302 2 5.4.4
McAfee Security Management Center
Windows Server 2008 R2 1 5.6.1
Microsoft Active Directory Server
Windows Server 2008 R2 1
Stonesoft User Agent Installed on Active Directory Server
1 1.1.5.44
Cisco Routers 3750 3 15.0 (2) SE1
Network
Figure 2 below depicts how our simulated lab is configured. Table 2 provides a legend for some of the abbreviations used.
Figure 2. Lab network design.
Table 2: Lab Network Design Abbreviations
Abbreviation Description
AD Active Directory
SMC McAfee Security Management Center
MEG McAfee Email Gateway
MWG McAfee Web Gateway
OTP McAfee One Time Password
ESM McAfee Enterprise Security Manager
Vmnic Virtual Machine Network Interface Card
McAfee Security Management Center
All the configuration steps performed in these use cases used McAfee Security Management Center. To learn more about how to use McAfee Security Management Center to deploy a similar solution in your environment, view the
McAfee Security Management Center Architecture and Configuration video: McAfee Security Management Center Architecture and Configuration video.
To bind McAfee Security Management Center to Active Directory in Microsoft Windows 2008 R2, use caps lock for CN. Example:
CN=admin, CN=Users, dc=inside, dc=com
McAfee Security Management Center version 5.6 does not generate a user agent certificate. Use version 5.6.1 or higher.
USE CASE 1: USER-BASED APPLICATION CONTROL
Administrators want to be able to control, limit, provision and de-provision user access to applications while also having high visibility and correlation between user activity and security policy.
McAfee Security Management Center allows you to more flexibly identify and control traffic beyond specifying a network protocol and ports for TCP and UDP traffic. There are several predefined application elements available that define the criteria for matching commonly used applications. You can also create custom application elements. Applications are matched against the payload in the packets, so applications are also detected from non-standard ports.
And within McAfee Security Management Center logs, statistics, and reports, you can easily see which applications are used the most or which applications are in use and by which user.
Access control by user allows you to designate user and user group elements as the source or destination of a rule to create user-specific rules without requiring user authentication. You can employ user-specific rules with user authentication rules to allow some user groups to access a service, while, at the same time, generally requiring authentication for the same service.
However, user-specific rules do not replace user authentication. They are tools to simplify the configuration of access control and improve the user experience by allowing transparent access to services. They should be used for trusted users in a trusted environment where strong authentication is not required.
McAfee AppPrism technology has been added in McAfee Next Generation Firewall v. 5.7. With the introduction of McAfee AppPrism in McAfee Next Generation Firewall, the number of application categories will increase tremendously.
Design
User- and group-based policies are assigned to provide transparent and uninterrupted services to users. For our use case, we have assigned various policies to both individual users and to groups. Some of these users are part of the finance and marketing groups in the example. The configured order of the policies is very important for the rules to be correctly applied to users or groups.
Each user is associated with one IP address from a client computer. McAfee Next Generation Firewall lets you associate a user with an IP address by utilizing a software component called the “user agent.” The user agent can be installed on a Windows system in an Active Directory domain that communicates with the Active Directory domain controller to associate users with IP addresses. We have an Active Directory set up to query the users and the installed user agent in the same Active Directory system, and we also have an authentication server to authenticate the users based on username/password.
McAfee Security Management Center v. 5.6 does not generate a user agent certificate. To generate a user agent certificate, you need v. 5.6.1 or higher.
Review the diagram in Figure 3 to see the users we have created in our lab and which users are a part of the marketing, finance, and branch groups in the example.
Additional Resource: Video
For an overview of this section, view a video about McAfee Next Generation Firewall application control implementation: http://youtu.be/H0W2veDia8Q.
Configuration
The configuration shown in Figure 3 is used in all the test cases for the user- and group-based policies use case. The policies are uploaded on the edge firewall of the main office.
Figure 3 shows a screen capture from our McAfee Security Management Center that manages the two McAfee Next Generation Firewalls in our design. The policies are configured in the McAfee Security Management Center console, after which they are uploaded to the respective firewall.
Let’s look at an example of a user “lmajors.” As seen below, user “lmajors” belongs to the finance group. We have created a separate policy for user “lmajors,” and we also have a policy for the group “finance.”
While you configure rules for your policy, keep in mind that the order in which you define your rules is very important. Incorrect order of rules will lead to inaccurate results.
Figure 4 shows an example of a user, “mkay,” who belongs to the marketing group. We have configured a policy for user “mkay” and we have a separate policy for the marketing users group. You can see that the rule for user “mkay” is configured above the marketing users’ rules, which means user “mkay” will always follow the rule 15.7 since it is defined above the marketing group’s rule. Again, if the rules are not configured in the correct order, you will not achieve the expected results.
Validation
Test Case 1: Allow Individual Access to Services
User “lmajors,” who is located on the internal, private main office network, tries to access www.dropbox.com through a web browser. We would like to allow this user to access this service.
Procedure
As shown in Figure 5, based on the policy 15.5 for user “lmajors,” the firewall queries the sub-policy 15.5.1 to see if
www.dropbox.com is being discarded. Since it is not discarded, it goes to the next sub-policy, which is allowing everything that is not specifically discarded in the previous sub-policy.
Figure 5. Use case 1, test case 1: allowing individual user access to services. Results
Based on the policy 15.5.2, user “lmajors” should be able to access www.dropbox.com. We look at the log server data example in Figure 6 to understand the results.
User “lmajors” has been associated with local IP address 90.100.3.102. The source address is 90.100.3.102, and the application it is trying to access is Dropbox, as shown in the application tab. The log also shows which firewall node is allowing or discarding the connection. In this test case, we see McAfee Next Generation Firewall 1, node 1, which is the edge firewall in the company’s main office.
The tab “Situation” shows whether a connection will be allowed or discarded based on the policy. In this test case, the connection to Dropbox is allowed based on the policy 15.5.2, as we saw earlier.
Figure 6. Use case 1, test case 1: log server data.
McAfee Security Management Center also allows you to check which rule is allowing this connection. This is a great feature for troubleshooting. As shown in Figure 7, right click on the connection and view the rule.
In this test case, clicking on “View Rule” takes us to sub-policy “Individual Users,” which is policy 15.5. We proved that the Dropbox connection is allowed by policy 15.5.2.
Test Case 2: Prohibit Individual Access to Services
User “lmajors,” who is located on the private/company main office network, tries to access www.amazon.com through a web browser. We would like to prevent this user from accessing this service.
Procedure
As shown in Figure 8, based on the policy 15.5 for user “lmajors,” the firewall queries the sub-policy 15.5.1 to see if
www.amazon.com is being discarded. Policy 15.5.1 is discarding all Amazon-based applications. The user “lmajors”
sees the message “Page Not Found” displayed on his/her browser window.
Figure 8. Use case 1, test case 1: prohibit individual user access to services. Results
As shown in Figure 9, the log server shows that the connection to www.amazon.com is discarded. The connection is being attempted by IP address 90.100.3.102. In the previous section, we have learned that IP address 90.100.3.102 has been associated with user “lmajors.”
To prove which policy is discarding the connection, we right-click on the connection that is discarded and click “View Rule.” This test case takes us to the rule below, which is 15.5.1. This proves that the connection to www.amazon.com
Test Case 3: Allow Group Access to Services
User “bsmith,” who is a part of the finance group and is located on the private/company main office network, wants to access www.box.net through a web browser. Based on his membership in the finance group, we would like to allow him/her to access this service.
Procedure
As shown in Figure 10, based on the policy 15.6.1 for finance group users, all users will be allowed access to box.net application. As user “bsmith” is a part of the finance group, “bsmith” will be able to connect to any box.net application.
Figure 10: Use case 1, test case 3: allowing group access to services.
Results
In Figure 11, user “bsmith” has been associated with a local IP address 90.100.3.105. In the log server we can see that the connection to box.net for IP address 90.100.3.105 was allowed.
Right-clicking on the connection will take you to the rule that is allowing this connection. Based on the results, we prove that the box.net connection was allowed by the correct policy.
Test Case 4: Prohibit Group Access to Services
User “bsmith” is a part of the finance group and is located on the internal, private company main office network. The user wants to access www.dropbox.com through a web browser, but, based on his/her group membership, access should be prohibited.
Procedure
Based on policy 15.6.1 for finance group users, all users will be prevented from accessing the box.net application, as depicted in Figure 12.
Since the user “bsmith” is trying to access www.dropbox.com and Dropbox falls under the “File Sharing” category, the connection will be discarded based on policy 15.6.2.
Results
User “bsmith” has been associated with a local IP address 90.100.3.105. From the log server data as shown in Figure 13, we can see that the connection to Dropbox for IP address 90.100.3.105 was discarded.
Right-click on the connection, and click on “View Rule” to see which rule is discarding the connection. Based on the results, we prove that the rule 15.6.2 is correctly discarding this connection.
USE CASE 2: REMOTE CLIENT-TO-SITE VPN
When mobile users need direct, secured access to your organization's network or if remotely used applications do not feature web client functionality, the McAfee Next Generation Firewall IP security (IPsec) VPN client offers a secure solution with transparent network access for roaming users.
This remote client-to-site use case shows how the McAfee Next Generation Firewall IPsec VPN client provides a secure VPN connection to a McAfee Next Generation Firewall/VPN gateway for individual user computers running on Windows platforms. The IPsec VPN client protects private information while it is transferred over the Internet and allows verification of the user’s identity.
The McAfee Next Generation Firewall IPsec VPN client supports Windows platforms.
Design
In this use case, remote users have installed McAfee Next Generation Firewall (Stonesoft) IPsec VPN client on their Microsoft Windows systems and have established secure connections through the built-in internal gateway, which is configured on the McAfee Next Generation Firewall at the company’s network edge (Figure 14).
To establish a VPN connection, the McAfee Next Generation Firewall IPsec VPN client prompts a user to authenticate to the McAfee Next Generation Firewall built-in VPN gateway. After successful authentication, the IPsec VPN client downloads a configuration file from the firewall to set the correct options for establishing a client-to-gateway VPN with that client-to-gateway (for encryption, authentication, endpoints to contact, and the IP addresses that are accessible through the VPN.) When changes are made on the gateway, each IPsec VPN client updates its configuration the next time the IPsec VPN client starts a new VPN connection. Due to the centralized configuration method, the McAfee Next Generation Firewall IPsec VPN client can connect to McAfee Next Generation Firewall or McAfee Next Generation Firewall/VPN gateways only. If you wish to use a third-party VPN gateway, you will configure through the third-party solution graphical user interface (GUI) or command-line interface (CLI).
Once the user establishes a secure VPN connection, the application control policies are set for users and groups on the firewall, such as those reviewed in Use Case 1.
Figure 14. Use case 2: remote client-to-site VPN.
Additional Resource: Video
For a technical overview and demonstration of this remote client-to-site use case, you may also view our video at:
http://youtu.be/zpRScIyMPJM
Configuration
VPN Gateway and VPN Client Configuration in McAfee Security Management Center
As shown in Figure 15, drag and drop the gateways you want to include in this VPN into either of the two panels to define which gateways can create a VPN with one another.
In our scenario, the IPsec client is the satellite gateway and Santa Clara Internal SGW is the central gateway. Let’s define different types of gateways before we proceed further:
If you add a gateway under Central Gateways, the gateway can establish VPN with any other gateway in this VPN (both central and satellite).
If you add a gateway under Satellite Gateways, the gateway can establish VPN only with gateways defined as central in this VPN.
Add two or more gateways in this view to create a VPN. You must add at least one of the gateways under Central Gateways. You do not have to add any gateways under Satellite Gateways. (All gateways can be central.)
Figure 15. McAfee Next Generation Firewall built-in, internal VPN gateway and IPsec client configuration.
VPN Policy on the Firewall
Figure 16 shows the VPN policies on the firewall, with policy 15.11 as a mandatory policy for the VPN.
Policy 15.12 allows remote users to authenticate and connect to the private/internal network. In the action tab, select “Enforce VPN” and the client-to-gateway VPN that we configured earlier.
Validation
Test Case 1: User Authentication
A remote user “lmajors” needs to get secured VPN access from a remote location.
Procedure
In this example (Figure 17), remote user “lmajors” will connect to the McAfee Next Generation Firewall internal VPN gateway by providing a username and password. Active Directory will query the username and password to authenticate the user if the credentials are accurate. Once the user authenticates successfully, based on the policy 15.12, the user will be provided with a VPN virtual IP address via the dynamic host configuration protocol (DHCP) server.
All remote users will successfully authenticate if their credentials are accurate. User- and group-based policies created for users and groups will be applied.
Results
Figure 18 shows the McAfee Next Generation Firewall IPsec VPN client installed on a user’s desktop, interacting with the McAfee Next Generation Firewall’s internal VPN gateway, and providing the credentials. If the authentication server successfully authenticates the user, a virtual IP address is assigned to the remote user. In this case, the virtual IP address assigned to user “lmajors” is 90.100.3.152.
Figure 18. Use case 2, test case 1: client on user desktop authenticating to VPN.
Figure 19 shows the log view of the VPN tunnel negotiations between the client’s machine and McAfee Next Generation Firewall.
If there is a problem establishing a VPN tunnel, you should start troubleshooting by looking at this log view. The “Information Message” field that is highlighted will give you details on each negotiation step.
Test Case 2: Remote User Policy
User “lmajors” wants to access www.amazon.com through a web browser. The user is already authenticated and has established a secure tunnel to the private network. Any Internet-based activity from the user “lmajors” should go through the tunnel to the private network and pushed out through the firewall and its configured policies.
Procedure
Based on policy 15.5.1 (Figure 20), user “lmajors” is not allowed to go to any amazon.com applications. As all access policies for this user should be implemented through the remote connection, the request goes to the firewall, and the firewall should discard this connection. This proves that the traffic from the remote user is following the correct path.
If you don’t see any log activity from user “lmajors” in the log server, that means the VPN connection is not established accurately and the user is not going to the Internet via the private network.
Results
Figure 21 below shows the output on the log server. We can see that the request for amazon.com was discarded. The right corner of the log tab also shows the same information, and you can see that the source address for “lmajors” is 90.100.3.152, which is the virtual IP address assigned by the DHCP server.
To see the policy that caused the connection to be discarded, right-click on the connection and click “View Rule.” The information shown in the figure indicates that the connection was correctly discarded by the policy 15.5.1.
USE CASE 3: SITE-TO-SITE VPN
Just as remote users connecting to their corporate sites require secured connections to make certain that neither their endpoint device nor their main company network is compromised, it is important to provide full security between branch offices and their connected corporate sites. This use case shows how a branch network can connect to an internal, private network through a VPN tunnel using a McAfee Next Generation Firewall on each network edge.
Design
In this use case, we have established a secure connection between the internal VPN gateways of two McAfee Next Generation Firewalls in order to create a secure VPN tunnel over the Internet (Figure 22). Any information exchanged between the main office and its branch office will be securely transferred through the VPN tunnel.
Configuration
In Figure 23, drag and drop Santa Clara Internal SGW to Central Gateways and, similarly, the Branch Internal SGW goes to Satellite Gateways. To learn more about these two types of gateways, refer to use case 2. This creates a site-to-site VPN tunnel between the main office and branch office.
Figure 23. Configuring a secure VPN tunnel between two McAfee Next Generation Firewall internal VPN gateways. The VPN policy on both the firewalls making a VPN tunnel should be the same. Figure 24 shows the site-to-site VPN tunnel policy on the main office edge firewall.
Figure 24. Policy on the main office edge firewall.
Validation
A user “binside” at the branch office wants to securely transfer a file to Server A, which is located at the company’s main office.
Procedure
As shown in Figure 26, we will attempt to successfully transfer files from user “binside” desktop, located at the branch office, to Server A, located in main office over our established VPN tunnel.
Figure 26. Securely transferring files from a branch office to a main office over a VPN tunnel. Results
Once we’ve successfully moved the file, which will be evident by completion of file copying, we’ll look at the log server to see this transfer.
Figure 27 shows that source 30.100.3.110 (associated to user “binside”) is allowed to transfer a file to destination Server A (90.100.3.103). We also see that the first red box (sender tab) shows both the firewalls NGFW1 and NGFW2 are allowing this connection.
Now, let’s right-click on the connection in “View Rule” to see which policy on the firewall is allowing this connection. In our test, the VPN tunnel policy is allowing the connection; this is accurate, proving that the file transfer was done securely through the established VPN tunnel.
USE CASE 4: HIGH AVAILABILITY—CLUSTERING
A single firewall can be a single point of failure. This can affect the availability of business-critical applications and complicate the maintenance of firewall equipment. Clustering firewall nodes together can significantly reduce the risk of these problems while also supporting higher performance. Firewall clustering allows uninterrupted operations during system maintenance and updates and is transparent to users.
McAfee Next Generation Firewall offers high availability by natively “clustering” as many as 16 firewall cluster nodes without using extra load-balancing products. If any individual nodes fail, others will keep going. And you can perform maintenance or add nodes to scale performance and availability without compromising service. For the administrator, the cluster is managed as a single firewall entity.
Design
A McAfee Next Generation Firewall cluster is a single virtual entity that can include from two to as many as 16 physical devices (Figure 28). Each physical device that makes up the firewall cluster is called a firewall node (FW node).
McAfee offers two types of clustering: active-standby and active-active. In active-standby clustering, only one node at a time processes traffic, and the other nodes wait on standby, ready to take over when the currently active node goes offline. Nodes that should not take over automatically can be set offline as usual.
In active-active mode, the firewall engines dynamically load balance individual connections between the nodes, transparently transferring connections to available nodes in the event a node becomes overloaded or experiences a failure. Clustering in active-active mode improves performance when heavy packet processing functions are needed, such as deep inspection, VPNs, application identification, URL logging, or complex policies.
When you design a firewall cluster, ensure that, if one or more nodes goes offline, the remaining nodes have enough capacity to handle the increased load. For example, in a three-node cluster with a 50%-50%-50% load on each node, if one node goes down, then the remaining two nodes will be able to handle 75%-75% load. But if the three nodes are at 80%-80%-80% load each and one node goes offline, the remaining two nodes will become overloaded.
Figure 28. McAfee Next Generation Firewall native clustering of up to 16 firewall nodes.
McAfee Next Generation Firewall Node Interfaces There are two types of interfaces on a node:
Cluster virtual interface (CVI) is a logical interface shared by all nodes in a cluster and is used for traffic routed through the firewall for inspection.
Node-dedicated interface (NDI) handles communication between nodes, as well as between the nodes and the McAfee Security Management Center server.
The cluster’s firewall nodes exchange information constantly. The state tables that list open connections (state sync) and the operating state of the other nodes (heartbeat) are exchanged. This exchange of information ensures that all nodes have the same information about the connections and that if a node becomes unavailable, the other nodes of the cluster immediately detect this. The exchange of information between clustered firewall nodes is synchronized through selected interfaces via a heartbeat network using multicast transmissions.
One NDI on a node must be selected as the primary heartbeat interface. Another NDI should be configured as the backup heartbeat interface. A dedicated network is recommended for the primary heartbeat.
Figure 29. McAfee Next Generation Firewall node interfaces in a three-node cluster.
Because of their dual role as members of a common virtual entity and as separate physical devices, firewall engines in a cluster have two types of IP addresses:
Cluster virtual IP address (CVI)—An IP address that is used to handle traffic routed through the cluster for inspection. This is an IP address that is shared by all nodes in a cluster, in effect making the node appear as if it were a single entity for the outside network behind the IP address.
Node-dedicated IP address (NDI)—An IP address that is used to handle traffic from or to a single node in a cluster. These IP addresses are used for the heartbeat connections between the engines in a cluster, for control connections from the McAfee Security Management Center server.
You can configure several CVIs and/or NDIs on the same physical interface.
In the example in Figure 29, interface 1 is used as the CVI for protected network traffic and for the heartbeat backup. Interface 3 is used as the CVI for Internet traffic (for example, Internet traffic from clients in the protected network). It is also the primary control NDI for management server. Interface 2 is the backup control NDI for management server. Interface 0 on each node is the NDI used for heartbeat traffic between the nodes in a dedicated network. There is no CVI on Interface 0, since it handles only node-to-node traffic.
Configuration
Let’s configure a firewall cluster step by step: 1. Select the Monitoring | System Status tab.
2. Right-click on Firewall and select New | Firewall Cluster, as highlighted in red in Figure 30. 3. This will open the window in Figure 30.
4. Assign a name to the firewall cluster element (ESG_Test in our example in Figure 31), and select the log server for storing logs.
5. Add DNS IP addresses used to resolve server names (optional).
6. Two nodes are added by default. We have added an additional third node to the cluster.
You can add a node to the cluster with just one click. When you add a node, example node 4, as shown in Figure 31, an NDI is automatically generated for that node.
Figure 31. Creating the firewall cluster element.
7. Go to the interfaces tab and click on Add | New | Physical Interface, as shown in Figure 32.
A physical interface definition in the management client always represents a network interface definition on all nodes of the cluster. You must define at least two interfaces for the firewall cluster: one control interface for communications between the McAfee Security Management Center server and the engines and one “Heartbeat Interface” for communications between the cluster nodes.
You must also define a CVI that is shared by all the nodes in the cluster. In our example we have two CVI’s, one for the private network and the other for routed traffic sent to the firewall for inspection.
Figure 32. Configuring interfaces.
We configured four interfaces for our example. Int 0 is the heartbeat, Int 1 is the protected network, Int 2 is the primary control, and Int 3 is the control backup.
8. Right-click on Int 2, select New | IPv4 Address.
We entered CVI and NDI as required in our example (Figure 33). As we discussed earlier, CVI on Int 1 is used for the internal protected network, CVI on Int 2 is used for the routed traffic that is sent to the firewall for inspection.
NDI handles all communications for which the endpoint is the node itself, including node-to-node, McAfee Security Management Center server-to-node, and node-initiated connections.
You must define an NDI IP address for all nodes on each physical interface. If there is a shortage of IP addresses, it is possible to leave some physical interfaces without an NDI.
Figure 33. Node interface IP addresses.
Figure 34. Defining the role of the physical interface.
Figure 35 shows the end result of the configuration steps. We have created a firewall cluster named ESG_Test with three firewall nodes.
Validation
When considering deploying a clustered firewall environment to protect service-level agreements (SLAs) for performance and availability, it is also highly recommended that you work with a staging environment first.
Procedure
When testing your configuration, you may choose to disconnect—physically if necessary—each configured node to validate that the cluster, its function, and load-balancing are set up in your intended configuration.
Results
When a node goes down on the cluster, you can see on the McAfee Security Management Center that the McAfee Next Generation Firewall cluster remains online—only the node that is down is grayed out. If you have a traffic generator test tool, you can validate that there is no traffic/packet loss when a node goes down.
USE CASE 5: HIGH AVAILABILITY—McAFEE MULTI-LINK
A single connection to the Internet is also a single point of failure. If the connection becomes unavailable, all outbound traffic is blocked.
To prevent this, patented McAfee Multi-Link technology distributes outbound traffic between multiple network connections (Figure 36). McAfee Multi-Link ensures that Internet connectivity remains available even if one or more network connections fails. McAfee Next Generation Firewall can also load balance outbound traffic between multiple network connections (Netlinks) to use the available Internet connection capacity more efficiently.
Design
McAfee Multi-Link can integrate with any type of connection to ensure that inbound, outbound, and VPN traffic is delivered securely through the fastest connections without incident or disruptive downtime. McAfee Multi-Link can accommodate digital subscriber lines (DSL), leased lines, cable modems, satellite, mobile broadband, and even WAN links, such as point-to-point multiprotocol label switching (MPLS). Organizations gain the flexibility to deploy the type and number of connections that are best suited for their environments and their budgets.
Combined with McAfee active load balancing and Quality-of-Service (QoS) capabilities, McAfee Multi-Link also optimizes networks and supports technologies, such as Voice-over-IP (VoIP), and video conferencing. Organizations gain granular control of their networks and ensure the availability of applications that are mission-critical to their operations.
Which Netlink Is Selected?
One or more Netlinks makes up a McAfee Multi-Link. Netlinks are selected based on bandwidth and performance or how they are configured. There are two load-balancing methods: round-trip time (RTT) and the ratio method. Either will be selected based on bandwidth and performance. Netlinks can be configured in standby mode to avoid expensive links or based on quality-of-service (QoS) preferences.
Round-trip time (RTT)—Netlink performance is measured for each new TCP connection by sending the first SYN packet of the handshake to the destination through all available Netlinks. The Netlink that sees the SYN-ACK response first is used to set up the connection. The firewall cancels other attempts by sending a TCP RESET to the destination through other Netlinks. Information about the performance of each Netlink is cached, so no new measurement is made if a new connection is opened to the same destination within a short time period.
Ratio method—There are, however, times when a ratio method may be preferred. For example, if one ISP’s bandwidth far exceeds other connections being used and is supplemented by smaller ISPs, the smaller ISP may return a faster SYN-ACK. While this may seem like the “fastest” connection, it may not take into account the proportionate bandwidth available. McAfee Multi-Link can resolve this by using a ratio method.
When the ratio method is used, traffic is distributed among all of the available Netlinks according to the relative capacity of the links. The bandwidths of the other Netlinks are automatically compared to the Netlink with the most bandwidth to produce a ratio for distributing the traffic. When the volume of traffic is low, the ratio of actual traffic distribution is approximate. When the volume of traffic is high, the ratio of traffic handled by each Netlink is closer to the ratio calculated from the link capacity.
In Figure 37 below, using standard outbound load balancing could result in using the 2 Mbps link even though the 5 Mbps link may be more efficient. Using ratio-based load balancing allows McAfee Multi-Link to take the larger link(s) into consideration to allow for a more granular and efficient use of available links.
Quality-of-Service
Organizations can optionally assign a QoS class to each Netlink. Assigning a QoS class to a Netlink specifies that traffic with the selected QoS class is routed through the selected Netlink. The same QoS class can be assigned to more than one Netlink. When no QoS class is assigned to a particular Netlink, traffic is routed through that Netlink according to the load-balancing method selected. The actual QoS classes can be assigned to specific traffic in the firewall policy or in the QoS policy based on the differentiated services code point (DSCP) codes of the incoming traffic.
Standby Links for High Availability
Standby Netlinks allow organizations to define a Netlink as a backup that is only activated when all primary Netlinks are unavailable. This minimizes the use of Netlinks that are more expensive (where the cost is based on the amount of traffic used) or otherwise less preferable, while still ensuring high availability of Internet connectivity. You can define multiple active Netlinks and multiple standby Netlinks.
Augmented VPN
McAfee Augmented VPN uses McAfee Multi-Link technology to provide a simple and cost-effective way to create fast, secure, high-capacity connections between sites and ensure uninterrupted Internet connectivity. Designed for ease of use, the implementation requires no special equipment, software, or Internet Service Provider (ISP) peering agreements.
McAfee Multi-Link enables organizations to flexibly and simultaneously connect to multiple network providers, creating fault-tolerant and highly available connections without having to change existing network infrastructures. With McAfee Augmented VPN, the aggregation of all ISP links is now possible. Link aggregation is a unique feature that enables organizations to combine different ISP lines to obtain a single high-capacity tunnel.
McAfee Augmented VPN with McAfee Multi-Link technology enables the prioritization of network flows and the definition of bandwidth portions dedicated to different types of flows. Business applications can have priority on high-quality Internet connections, and the rest of the traffic can use more cost-effective Internet connections.
When compared to other ISP multi-homing solutions, McAfee increases performance by providing true ISP load balancing, provides greater flexibility for implementation, and significantly reduces administration costs, while adding security to the network with McAfee Next Generation Firewall. In addition, McAfee Multi-Link provides a significant increase in VPN reliability and performance. Failover for VPNs among multiple providers is unique to McAfee Multi-Link technology.
For more details on McAfee Augmented VPN, refer to this document: http://www.mcafee.com/us/resources/white-papers/wp-augmented-vpn.pdf.
Configuration
Let’s start by configuring a Netlink. We know that two or more Netlinks form a McAfee Multi-Link. A Netlink typically represents a connection to an ISP. It may be a leased-line or xDSL.
Netlinks provide the routing connectivity that can support more than one default route. A Netlink contains:
A router element that represents the router for that network connection.
A network element that represents the set of public IP addresses allocated by the provider of the network connection.
Step-by-step instructions to configure McAfee Multi-Link:
1. Browse to Security Engines | Network Elements| Traffic Handlers. 2. Right-click Traffic Handles| New | Static Netlink (Figure 38).
The Netlink window will open up. Configure “Name,” “Gateway,” “Probe IP Address” (the address that will communicate with the McAfee Security Management Center), and other aspects of your desired configuration.
Figure 38. Create static Netlink.
We know that Netlink contains a router element and a network element.
3. Drag and drop the configured Netlinks under the appropriate interfaces. In our example (Figure 39), Netlink RTRB_ISP is configured under Interface 2 and Netlink RTRA_ISP is configured under Interface 3.
Figure 39. Configure Netlink interface.
5. Group the configured Netlinks together to define an outbound McAfee Multi-Link element. 6. Browse back to Traffic Handlers, right-click and select New | Outbound Multi-Link (Figure 40).
7. The properties window will open where you choose the routing method. You can click on Add to add at least two Netlinks.
8. When you click on Add, the McAfee Multi-Link member window opens. Go ahead and add the Netlink configuration based on your preferences.
9. Once everything is configured, click OK.
Figure 40. Create outbound McAfee Multi-Link.
McAfee Multi-Link for outbound connections is implemented in the firewall policy with network address translation (NAT) rules that define which traffic uses the outbound McAfee Multi-Link element. It is not necessary for all traffic to be balanced through the outbound McAfee Multi-Link element. When a NAT rule that balances outbound connections matches the traffic, only the traffic that matches the rule is balanced through the outbound McAfee Multi-Link element specified in the rule. Other traffic does not use the outbound McAfee Multi-Link element.
Validation
As with clustering, it is always good to stage and test a new configuration like McAfee Multi-Link for high availability environments before deploying into a production environment.
Procedure
To test the successful function of McAfee Multi-Link, you could disconnect one of the Netlinks, view the changed status within McAfee Security Management Center, and then validate that Internet communication through an ISP is still functioning.
Results
Figure 42 shows the system status tab of McAfee Security Management Center. We can see the healthy McAfee Multi-Link on the left side, and the routers are online as well. The topology also shows the two Netlinks going outbound through the McAfee Next Generation Firewall cluster.
GETTING SUPPORT
Each section of this document provides some example and recommended test cases or steps you can take to validate whether or not you have followed the guidance correctly.
When those steps do not work, you may also want to refer back to the product documentation. If you still need assistance, McAfee is ready to help.
Evaluating McAfee Next Generation Firewall
Visit our product website at www.mcafee.com/ngfw and open a “Click-to-Chat” session to interact with a live member of our support team.
Let the expert know that you are evaluating our products and are attempting to do a proof-of-concept with this guide. He or she will be happy to assist.
McAfee Next Generation Firewall Customers
As a McAfee customer, you will receive a grant number for support. Using the grant number, you can register for an account on our support portal, Technical Support Service Portal. Once you have an account, you can log in 24/7 with your credentials and access support resources.
About McAfee
McAfee, part of Intel Security and a wholly owned subsidiary of Intel Corporation (NASDAQ:INTC), empowers businesses, the public sector, and home users to safely experience the benefits of the Internet. The company delivers proactive and proven security solutions and services for systems, networks, and mobile devices around the world. With its Security Connected strategy, innovative approach to hardware-enhanced security, and unique Global Threat Intelligence network, McAfee is relentlessly focused on keeping its customers safe. http://www.mcafee.com
McAfee and the McAfee logo are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other marks and brands may be claimed as the property of others. The product plans, specifications and
descriptions herein are provided for information only and subject to change without notice, and are provided without warranty of any kind, express or implied. Copyright © 2014 McAfee, Inc. 61072gde_ngfw-design_0414
