• No results found

USE CASE 2: REMOTE CLIENT-TO-SITE VPN

In document McAfee Next Generation Firewall (Page 24-33)

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.)

Once you drag and drop the desired gateways, this will create a VPN tunnel between the two gateways.

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.

Figure 16. VPN policies on the firewall.

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.

Figure 17. Use case 2: user authentication.

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.

Figure 19. Use case 2, test case 1: viewing VPN tunnel negotiations in a log.

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.

Figure 20. Enforcing policies on remote user sessions.

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.

Figure 21. Use case 2, test case 2: viewing rule correlation in McAfee Security Management Center.

In document McAfee Next Generation Firewall (Page 24-33)

Related documents