Novell is now a part of Micro Focus

AppNote: VPN Policies in Novell BorderManager 3.8

Novell Cool Solutions: AppNote
By Felix Xavier, Sridhara Jagannath, Umasankar Mukkara

Digg This - Slashdot This

Posted: 12 Nov 2003

Umasankar Mukkara Felix Xavier Sridhara Jagannath
Software Consultant Software Consultant Senior Software Engineer

This AppNote provides details on the new Novell BorderManager (NBM) 3.8 Virtual Private Network (VPN) policies feature. It also provides troubleshooting guidelines to achieve the desired functionality of VPN policies. In NBM 3.8 the VPN component is significantly revised and is different from all earlier versions of BorderManager. This AppNote assumes that the reader has gone though the new documentation available with NBM 3.8 product and has understood what is new in NBM 3.8 VPN.

Table of Contents

1.0 Introduction
2.0 Representation of VPN Policies
3.0 Enforcement of Traffic and Authentication Rules
4.0 Automatic migration of Client-to-Site Protected Network list during Upgradation
5.0 Troubleshooting VPN Rules
6.0 Authentication and Traffic Rules for 3rd Party VPN Connections
7.0 Conclusion
8.0 Glossary

1.0 Introduction

NBM 3.8 Virtual Private Network (VPN) services provide support for VPN access policies and integration with eDirectory for identity enforcement. NBM 3.8 provides two types of access: First, the ability to allow VPN connections based on various identities such as eDirectory user, x.509 certificate user, eDirectory usergroup and eDirectory container; Second, VPN allows limited access to the resources (behind the gateway) based on the above mentioned identities.

VPN uses authentication and traffic rules to allow or deny VPN connections. User authentication allows an administrator to grant or reject access to specific users from specific IP addresses, based on their user credentials. Authentication rules and policies are defined and stored in eDirectory and are globally managed through the iManager-based VPN services. Traffic Rules are policies that govern accessibility for a user through a VPN connection.

The administrator can effectively combine the authentication and traffic rules to control the VPN services. For example, it is possible to configure a rule to allow a particular user to access an application running on a particular TCP port and deny access to everything else. In addition to this, the administrator can even specify the type of authentication credentials for a particular user.

2.0 Representation of VPN Policies

VPN policies can be configured for Client-to-Site VPN service and Site-to-Site VPN Service. Client- to-Site VPN service can have both Authentication as well as Traffic Rules. Site-to-Site VPN Service can have only Traffic rules as there is no user authentication involved in the Site-to-Site VPN Service.

A hierarchical diagram of VPN rules is depicted in the following picture.

Figure 1 Authentication and Traffic Rules

Site-to-site traffic rules do not have a destination condition. This gap is filled by the protected network list for each site-to-site VPN member as part of the member information configured in iManager.

3.0 Enforcement of Traffic and Authentication Rules

Authentication rules come into picture only after the primary authentication is successful. For example, if the user is trying to authenticate using the NMAS eDirectory or NDS method, authentication rules for this user are applied only after successful eDirectory authentication. The prioritized list of authentication rules is scanned and the first matching authentication rule is selected and enforced. If enforcement is to allow, the VPN connection is allowed to proceed. The prioritized list of traffic rules is scanned and all the matching traffic rules for this user are selected. The selected list is a prioritized list which will be sent to the VPN client as well as to the VPN server IP Sec. If the matching policy's action is to drop the packet, the packet is dropped at the initiator side, that is in the VPN client or at the gateway.

The diagram below depicts the typical sequence in which a client-to-site connection happens between NBM 3.8 VPN client and NBM 3.8 VPN server.

Figure 2 Typical client-to-site connection

Stage 1: VPN connection starts when NMAS mode is used. User credentials are sent to VPN server and they are verified on the VPN server. If the authentication is successful, the connection will proceed.

Stage 2: If the VPN connection is made using certificates, the connection begins here.

IKE Phase1 will be started. If successful, the VPN server will scan through the authentication rules and find the first matching rule for this user (user can be of type Certificate Subject Name, NDS User, NDS Group, LDAP Username, etc). If there is no matching policy, the connection is terminated. If the matching policy blocks this particular user from using this particular mode of authentication, the connection is terminated. If the authentication rule allows the connection to proceed, the VPN server will scan through the traffic rules and find all the matching rules for this particular user. This list is prioritized. In the above diagram, TR2 and TR8 are the matching rules for this user and priority of TR2 is greater than that of TR8.

Stage 3: If IKE Phase1 goes through and the authentication is allowed, IKE Phase 2 will be negotiated based on the selected list of traffic rules. At the end of successful IKE Phase 2, this list of matched traffic rules is transferred to the VPN client and the connection is established.

Stage 4: For the rest of the life time of the VPN connection, the traffic rules will be enforced both on the VPN client and the VPN server against the ordered list of selected traffic rules for (TR2 and TR8).

NOTE: Any change to authentication rules and traffic rules will not affect the existing VPN client-to-site Connection. The changes will affect only new VPN connections.

3.1 Difference b/w client-to-site rules and site-to-site rules

Client-to-Site Site-to-Site
Authentication rules are enforced No authentication rules
Traffic rules configured on the basis of user identities are also selected on the basis of the authenticated user identity All traffic rules are applicable to the master and all slave members
No specific third party rules need to be configured. Specific traffic rules have to be configured to communicate with third party site-to-site server

3.2 Default Values for VPN Rules

3.2.1 Client- to-Site Authentication Rules

When a client-to-site service is created, a set of default policies are set. The default authentication rule action is to DENY connections to all users. Add the required 'allow' authentication rules in order to allow the establishment of VPN connection by specific users.

Scenario Authentication Action
Default rule is to DENY all users DENY all users under any authentication mechanism
One rule is configured to allow an eDirectory user "x" with only NMAS method "eDirectory" Only eDirectory user "x" is allowed if he is authenticated using NMAS "eDirectory" method. All other users with any authentication mechanism will be denied the access

Below is a screen shot displaying a default authentication rule in a client-to-site profile:

Figure 3 Default authentication rule

3.2.2 Client-to-Site Traffic Rules

When a client-to-site service is created, a default traffic rule will be set for all users. This rule will drop packets of a protocol originating from any host (VPN client). This means that when a client-to-site service is created, the client-to-site connection goes through but all packets are dropped at the VPN client. Configure the required traffic rules for different users accordingly. In addition to the specific traffic rules, the administrator can also modify the default rule to A or B. This default rule will be hit when none of the other specific rules match the traffic.

A. Any user/any host/any kind of traffic/encrypt with the 3DES/HMAC-MD5 combination.
B. Any user/any host/any kind of traffic bypass the IPSEC encryption (Split Tunnel mode).

3.2.3 VPN Rules when using Backward Compatibility Mode

There are two scenarios in which the NBM 3.8 VPN server and the BMEE 3.6 or NBM 3.7 VPN server will communicate with NBM 3.8 VPN clients.

Case 1: If the VPN client is NBM 3.7 or BMEE 3.6 or NBM 3.8 in Backward Compatibility Mode and the VPN server is NBM 3.8 (new or upgraded).

In the first case, the VPN server will enforce both authentication and traffic rules. Authentication rules configured for this eDirectory or NDS user is enforced. This means that even if the users are using an older client, the administrator can control their access by upgrading the server to NBM 3.8. In this case old ACL rules (rules in BMEE 3.6 or NBM 3.7) will not be effective and will not be migrated. So, an NMAS user based authentication rule has to be created for a user to connect to a NBM 3.8 server in the backward compatibility mode.

Case 2: If the VPN client is a NBM 3.8 client in the Backward Compatibility Mode and the VPN server is either NBM 3.7 or BMEE 3.6.

In this case the NBM 3.8 client will behave exactly the same as a NBM 3.7 or BMEE 3.6 client.

3.3 Site-to-Site Traffic Rules

When the site-to-site service is created, the default traffic rule for any kind of traffic will be set to encrypt the traffic using 3DES/HMAC-MD5 algorithm combination. Add specific rules based on service ports and provide varying levels of security for multiple services. The default traffic rule can also be modified to drop all packets. The default rule will be enforced if none of the other rules match the traffic.

Enforcement of site-to-site traffic rules:
Unlike client-to-site traffic rules, these rules are enforced immediately after they are received on the VPN server. This is required because a site-to-site connection between two peers is continuously up and requires the policy changes to take effect on the fly. Whenever there is change to the traffic rule list, the complete list of traffic rules are sent to all the slaves and the existing IP Sec connections are renegotiated according to the new list of traffic rules.

4.0 Automatic migration of Client-to-Site Protected Network list during Upgradation

When either a BMEE 3.6 or a NBM 3.7 server is upgraded to NBM 3.8, VPN services are automatically upgraded.

This upgrade automatically creates new client-to-site and site-to-site services in the eDirectory. The list of protected networks for a client-to-site service in NBM 3.7 will be converted to client-to-site traffic rules in eDirectory. This will happen with any user or network configured in NWAdmn or encrypted with an algorithm configured in NWAdmn. Once upgraded, the modification and deletion of protected networks in NWAdmn will not affect the client-to-site connections. Any changes to this can be done using iManager.

NOTE: When a NBM 3.7 or BMEE 3.6 VPN server, which has a client-to-site service configured, is upgraded to NBM 3.8 the default authentication rule in the client-to-site service is added to DENY all users. Add new authentication rules to allow the VPN Connection to required users.

5.0 Troubleshooting VPN Rules

VPN Rules are stored in many places and can be viewed through the new iManager snap-ins. However, when the VPN loads, these rules are read into the memory of the vpmaster.nlm or the vpslave.nlm. Any modification to the rules in eDirectory is monitored and is constantly updated in the memory of vpmaster.nlm/vpslave.nlm. Use the VPN console to view if the rules are being read or modified correctly. Audit logs can be used to monitor modifications to rules. The new VPN console can be used to verify if the in VPN memory synchronized with what is configured through iManager.

5.1 Opening and Closing of VPN Console:

_vpn command at the server console will open a new VPN CONSOLE screen.
_vpn command at the server console will close the VPN CONSOLE.

Figure 4 VPN Debug Console

The VPN debug console has options that display the contents related to VPN rules:

Option 5: Displays client-to-site authentication rules – displays the list of all client-to-site authentication rules on the console screen.

Option 6: Displays client-to-site traffic rules – displays the list of all client-to-site traffic rules on the console screen.

Option 7: Displays site-to-site traffic rules – displays the list of all site-to-site traffic rules on the console screen.

Option 8: Displays site-to-site IP Sec policies – site-to-site traffic rules are stored in vpmaster.nlm or vpslave.nlm and also in IP Sec memory (only the rules that are enabled). These options can be used to make sure the site-to-site traffic rules are properly entered or modified in IP Sec.

If there is a mismatch in the rules visible in iManager and the VPN Console, the rules can be reloaded using the Synchronize button provided in the Server Configuration Screen of iManager. For more details, refer to the NBM 3.8 VPN Documentation.

Here is the synchronize button screen:

Figure 5 Server Configuration Screen

6.0 Authentication and Traffic Rules for 3rd-Party VPN Connections

6.1 Client-to-Site

There is no separate set of authentication or traffic rules when a client-to-site connection is made using a 3rd-Party VPN client, such as SSH Sentinel. Client-to-site VPN connections to NBM 3.8 is possible using X.509 certificates. The first authentication rule matching the corresponding Certificate Subject Name is enforced. Traffic rules are selected based on this Certificate Subject Name.

6.2 Site-to-Site

In case of site-to-site VPN connections, a separate set of traffic rules is configured for each 3rd-Party VPN member. These rules are transferred to all the slaves. So, once a 3rd-Party member is configured on a master, VPN tunnels can be established from that specific 3rd-Party VPN gateway to all the NBM 3.8 VPN members of the VPN network (master + all NBM 3.8 slaves).

An example configuration of policies while configuring a site-to-site connection with CheckPoint VPN-1 Gateway.

Figure 6 Example configuration of policies

In the above network, we have one site-to-site VPN tunnel between the master and Checkpoint (12 network and 11 network) and another between a slave and Checkpoint (13 network and 11 network). Checkpoint configuration is added in master as a non-BorderManager VPN member with 11 network as protected network. This will automatically create a traffic rule with the source as Any and the destination as Any. The action will be encrypt. We have to add two more traffic rules to enable the IP Sec communication between the private networks to work. Add a traffic rule with source as 11 network and destination as 13 network. Similarly add another rule for 11 and 12 networks. This will enable both IP Sec peers to communicate between private networks using separate security associations. Similar or matching traffic rules (or policies) should be configured on the CheckPoint VPN gateway. The example configuration shows a reference traffic rule between 11 and 13 networks.

Figure 7 Third party traffic rules

7.0 Conclusion

Novell BorderManager 3.8 provides complete control to the administrator of VPN services. The administrator can handle different users, decide what resources they can access, decide what method authentication they can use (certificate or LDAP), enable the algorithms to use while communicating with a specific host or network. All this can be done by using the web-based iManager.

8.0 Glossary

Resources: The systems behind the VPN Gateway like mail server, storage devices, personal computers and so on.

User: VPN clients who need to access the VPN services provided by VPN gateway . Users come with various identities like eDirectory user, x.509 certificate user, LDAP user and so on.

VPN Gateway: VPN gateway is used alternatively for NBM master server or NBM slave server.

NBM Master/Slave: NBM VPN setup typically consists of master servers, slave servers and VPN clients. Master server acts as the centralized policy server where the administrator configures policies and master server distributes the policies to slave servers and VPN clients.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates