Novell Home

AppNote: VPN behind NAT

Novell Cool Solutions: AppNote
By Aruna Kumari, Felix Xavier, R Anupkumar

Digg This - Slashdot This

Posted: 29 Apr 2004
 

Cool Solutions AppNote: Deploying the NBM 3.8 VPN Server behind NAT

Anupkumar R, Senior Software Engineer
ranupkumar@novell.com

Felix Javier, Software Consultant
xfelix@novell.com

Aruna Kumari, Senior Software Engineer
akumari@novell.com

Abstract: The Novell BorderManager 3.8 (NBM 3.8) VPN server can be placed behind a static NAT. NAT translates IP address and enables access to a VPN server on a different network. Placing a VPN server behind NAT enhances the security of the server and makes it less vulnerable to outside attacks. This paper discusses the deployment of a NBM 3.8 VPN server behind a NetWare NAT.

INTRODUCTION

This AppNote helps you

  • Configure a NetWare server as a NAT server
  • Establish Client-to-Site and Site-to-Site connections using the NBM 3.8 VPN server across the NAT server

In a large corporate network, it's not practical to place the VPN server in a vulnerable position. By adding firewall exceptions for VPN server ports we might open new security vulnerabilities. Placing the VPN server behind NAT is the ideal solution in such an environment. NBM 3.8 is able to provide this feature without requiring additional bandwidth.

NBM 3.8 is designed to work across NAT. Because NBM 3.8 VPN Server is based on standard NAT implementation, it can work with any NAT device that supports static mapping of a public IP address to the internal NBM 3.8 VPN server IP address.

Intended users

This AppNote is intended for administrators who plan to have, or already have NBM 3.8 for their VPN servers and require connectivity across a NAT device.

About NAT

Network Address Translation (NAT) plays a major role in enhancing the level of security within a network. It helps in hiding internal information, primarily the IP addresses. NAT is typically used to allow users or servers from a public network to establish connection with a private network.

On Netware, NAT can be configured to operate in one of these three modes:

  • Dynamic only
  • Static only
  • A combination of Static and Dynamic
  • Dynamic mode is used to allow hosts on the private network or intranet to access a public network, such as the Internet. Dynamic NAT would be used if:
    • The available Public IP addresses are limited.
    • The intent is to use a small number of IP addresses.
    • More machines should be connected to the Public Network.
  • Static mode enables hosts on the public network to access selected hosts on a private network. If servers behind the firewall in the Private Network are to be made available outside the private network, then Static NAT can be used to expose them.
  • In this AppNote we will concentrate on the use of static NAT, where the VPN Master server is in a private network.
  • Pre-requisites for Configuration

    It is assumed you are familiar with NAT and can configure a NBM 3.8 VPN server.

    For more information regarding setting up NAT on NetWare refer to the Network Address Translation documentation in the following link: http://www.novell.com/documentation/lg/nbm38/inst_admin/data/aned0m4.html

    For more information regarding NBM 3.8 VPN server configuration, see: http://www.novell.com/documentation/lg/nbm38/inst_admin/data/ajfs310.html

    Before configuring the setup, make sure the following requirements are met:

    • The server behind NAT is an NBM 3.8 server.
    • VPN clients 3.8 or later are being used. VPN clients 3.7 or earlier are not supported for client-to-site connections with NBM 3.8 VPN server behind NAT.
    • The NBM 3.7 slave cannot make site-to-site connections with an NBM 3.8 Master that is behind NAT.
    • To avoid NAT/VPN conflicts or problems, the NAT and VPN services should be on separate machines.
    • If a VPN server is behind a firewall, configure the firewall with the proper packet forwarding filters, as determined by the security policy. The firewall could also be running on the NAT device.

    Advantages of VPN Behind NAT

    The major advantages of placing VPN server behind NAT are:

    • It enhances the network security.
    • It allows the VPN server to be placed at a strategic location that suits the business requirement and meets all security considerations. This can be either a private network or in the required subnet.
    • Changing the VPN server address will not affect the VPN configuration. VPN configuration need not be touched when the server is moved from one subnet to another. A VPN server in a public network can easily be moved to a private network behind the NAT device without changing the VPN server configuration. The same is true when an NBM 3.7 server is upgraded to NBM 3.8 and moved behind the NAT device.
    • The "VPN server behind NAT" concept can be extended for load sharing and fault tolerance to ensure high availability of the server.

    DEPLOYMENT SCENARIO

    Consider the following deployment example for VPN server behind static NAT:

    As shown in the diagram below, a company's main office is on the public network (150.2.0.0/16) and the branch office is on a private network (172.16.1.0/24). For the main office to communicate securely with the branch office:

    • The addresses of the private network must be hidden from the public network.
    • Users from protected networks must be able to communicate with each other in a secure manner.
    • Data transfer between servers across the networks must be secure.
    Figure 1: NBM 3.8 VPN server behind static NAT

    This scenario covers the following situations:

    • VPN master server behind a static NAT device
    • VPN client in a public network
    • VPN client behind a dynamic NAT device
    • VPN slave in a public Network
    • VPN slave and VPN master servers behind static NAT
    • Third Party VPN slave server in a public network
    • More than two NAT devices between the VPN master server and the VPN client/VPN slave. The Internet may contain a router and NAT devices.
    • VPN client dialing into an ISP and then connecting to a master VPN server

    Keeping these scenarios in mind, the following sections explain the implementation.

    CONFIGURING THE NETWARE SERVER AS A NAT DEVICE/ROUTER

    In static mode, the NAT device replaces the public IP address in the packet header destination IP field with the corresponding private IP address from the mapping (translation) table. Then the packet is placed onto the private network.

    When you configure a server as a NAT router,

    • Configure NAT on a separate machine from the VPN master or slave.
    • Include two interfaces on the NAT server: one bound for Public interface (150.2.3.72) and the other for Private Interface (172.16.1.72).
    • Add a secondary IP address to the public interface, because NAT is always configured on the public interface. Secondary IP address should be in the same public network (in this case 150.2.0.0).

    Additional Information: Systems configured behind a NAT router (in an intended private network) appear to have a single IP address. On a resource in a public network it appears as if the IP address belongs to one machine, whereas in fact there may be many machines attached to the same IP address. The systems in this network are configured with private IP addresses but appear to have public IP addresses on the Internet. This is how NAT security is enhanced in a dynamic mode.

    Configuring a secondary IPADDRESS on a Netware server

    To configure a secondary IP address at the server console, enter ADD SECONDARY IPADDRESS 150.2.3.99 at the console.

    To have the command take effect after restarting or resetting the server, you need to edit autoexec.ncf. After the line that executes INITSYS.NCF add a secondary IP address as follows: ADD SECONDARY IPADDRESS 150.2.3.99.

    To verify the secondary IP address' registry, enter DISPLAY SECONDARY IPADDRESS at the console.

    Figure 2: NAT server adding secondary IP address

    Configuring a Secondary IPAddress in NetWare 6.5 Server

    To configure the secondary IP address through INETCFG (NetWare 6.5 only), follow these steps:

    1. Load INETCFG.
    2. Select Bindings.
    3. Select the TCP/IP option for the PUBLIC interface on which the NAT needs to be configured.
    4. Select the Secondary IP Address Status option.
    5. Enable the status.
    6. Select the Secondary IP Address List on this interface and enter the secondary IP address. This is a public IP address (150.2.3.99) that will be mapped to the IP address of the private server.
    7. Press Esc and select Yes to Update the TCP/IP configuration.

    Figure 3: Configuring secondary IP address on a NetWare 6.5 server

    Setting Up NAT

    This section deals with enabling NAT, configuring NAT, handling RIP, and adding a route on the VPN server.

    Enabling NAT

    To enable NAT,

    1. Load INETCFG.
    2. Select Protocols > Bindings > Public interface. The interface should have a registered IP address bound to it.
    3. Select Configure TCP/IP Bind Options > Network Address Translation.
    4. Select the NAT status as Static Only.

    The static only option will enables users or servers from the outside to establish connection with the server in the private network only. If the VPN client is in the private network and the VPN server is in the public network, use the Dynamic-only mode for clients to establish the VPN connection with the public server.

    If slaves/clients from public network want to access the private VPN server and private clients want to access the public VPN server, use both Static and Dynamic modes.

    Figure 4: Configuring NAT server enabling the status as Static

    Configuring NAT

    To configure NAT,

    1. Select the Network Address Translation Table.
    2. Press Insert to open the Network Address Translation Entry window.
    3. Map the secondary public IP address (150.2.3.99) to the private VPN server IP address (172.16.1.99) that needs to be accessed from the public network. Now the private machine can be accessed from the public network with the mapped secondary IP address.
    4. Press Esc until prompted to save changes, then select Yes.
    5. Press Esc to return to the Internetworking Configuration menu.
    Figure 5: NAT server being configured with a Network Address Translation Entry

    Handling RIP

    If RIP is enabled, the NAT server and the VPN server behind it may cause a routing loop. In that case you should disable RIP on the VPN server or NAT server.

    If RIP is required on both VPN server and NAT server, then configure the static NAT interface as RIP-receive only, so the router cannot advertise private routes to the public network. To do this,

    1. Load INETCFG and select Bindings for the public IP interface.
    2. Select RIP Bind Options > RIP Mode.

    Then disable RIP and enable IP Routing in INETCFG as follows:

    1. Launch INETCFG.
    2. Select Protocols > TCP/IP Protocol Configuration > Enabled (Router) IP Packet Forwarding and Disabled RIP.
    Figure 6: NAT server in which RIP is disabled

    Adding a Route on the VPN Server

    To add a route on the VPN server,

    1. Create a static route on the VPN server for the private network to reach public network.
    2. Add a default route with private IP address of the NAT (172.16.1.72) server as gateway on the VPN server, which is in private (172.16.1.0) network.
    3. Verify that the VPN server is able to access the public machine (in this case the NAT router's public primary IP address).
    4. Add the respective NAT interface as a default gateway in the VPN server or client. This enables the servers and clients to reach the machines on the other end of the NAT device.

    Verifying the NAT Configuration

    Before configuring the VPN server, ensure that the traffic from the NAT to the VPN server is flowing properly without the VPN services running.

    To verify connectivity across the network, do the following:

    1. From any machine in the public network, ping the NAT'ed interface (with the secondary IP address of the NAT machine as 150.2.3.99). Replies should be received by machines in the public network.
    2. To verify that the NAT'ed interface (secondary IP address) does not reply to requests when the VPN server is down, bring down the VPN server machine. Remember, during down time the public machine generating the ping request should not get reply packets.
    3. Bring up the VPN server and verify that the ping replies are received. All the packets from public network to private network go through the NAT and to the VPN server (mapped machine 172.16.1.99). The VPN server replies back to the request.

    VPN Server Configurations

    Basic VPN server configurations can be done by referring to the following link: http://www.novell.com/documentation/lg/nbm38/inst_admin/data/ajfs310.html

    Configure VPN server with public secondary IP address of the NAT server on which the VPN service has to run.

    The figure below shows the VPN server configured with a public secondary IP address.

    Figure 7: NBM 3.8 VPN server configured with a Public IP Address

    VPN Client-to-Site Service Configuration

    To configure VPN Client-to-Site service,

    1. Use a traffic rule (for example, for Any User, Any Host, Any Protocol, Encrypt) and an authentication rule (for example, for Any User, Allow, NMAS, Authentication Login).
    2. You can add a traffic rule for a particular destination IP address or a list of IP address or network, or for different users to Allow Unencrypted packets. This enables the user to access the Internet directly without reaching the VPN server or without encrypting the packets. In this case, the tunnel bypasses the packets that match this traffic rule. You can configure traffic rules based on user or destination, or service or action, and the action can be Encrypt, Deny or Allow Unencrypted.
    3. Configure the authentication rule based on the user/authentication condition (NMAS or Certification Authentication) or the Allow/Deny action. Traffic and authentication rules play a major role in encrypting the data securely in the Internet, as per the requirements.
    4. Enable the Client-to-Site role.
    5. Attach the Client-to-Site service to the VPN server.

    VPN Site-to-Site Configuration

    To configure VPN Site-to-Site service,

    1. For this scenario, configure the VPN server behind the NAT router as the master server.
    2. Configure the slave server and make its information available to the master server as a slave member.
    3. If the slave server is a third party or non-BorderManager VPN server, configure it for non-BorderManager VPN. The traffic rules configured on NBM 3.8 server and non-BorderManager VPN server should be identical.
    4. Add the Protected IP Network of the slave server. This is the list of networks or hosts that would be protected by this Site-to-Site member.
    5. Configure traffic rules as required. The default traffic rule is to encrypt traffic with the 3DES/HMAC-MD5 combination. Specific traffic rules must be used while configuring communication with the third party site-to-site server.

    CONNECTING WITH THE VPN SERVER BEHIND NAT

    Once the configuration of the VPN server is done, you can use it to establish connections with either the clients or servers across the NAT router. There can be more than two NAT devices in the network between the VPN client and VPN server, and the client/slave-server can be behind the NAT device. Both Client-to-Site and Site-to-Site connections use only NAT'ed IP addresses to establish connections with the private VPN server.

    Client-to-Site Connection

    To connect with the VPN server that is behind the NAT router, the VPN client uses the NAT'ed IP address (150.2.3.99) with which the VPN server is configured. When the IP packet is received on this public interface of NAT server, NAT forwards the request to the private IP address (172.16.1.99) where the VPN server is running. No port changes occur in static mode.

    To proceed with the connection,

    1. Verify that IP packet filtering is not blocking incoming or outgoing TCP/UDP packets on the NAT router. If it is, you need to add exceptions to allow VPN traffic and other traffic as required.
    2. Establish a Client-to-Site connection from the VPN client (150.2.3.68) to the VPN server using the public IP address of the NAT (150.2.3.99) instead of the VPN server's IP address (172.16.1.99). This prevents the VPN server from being exposed to public networks.

    Figure 8: Establishing Client-to-Site connections from the VPN Client

    To verify Client-to-Site connection, generate ping traffic to the VPN server and check whether the packets are getting encrypted. In the following figure, it can be seen that the packets generated to the server are being encrypted.

    Figure 9: Traffic generated to the VPN server is being encrypted

    For example, if a traffic rule is configured to allow encrypted packets to go to the VPN server, it will allow unencrypted packets to all other destinations. After establishing the VPN connection the configured traffic rules can be viewed under Polices on the VPN Statistics page.

    To verify the traffic rules, the following traffic is generated:

    1. When CMP traffic is generated to the VPN server, the packets should be encrypted.
    2. When CMP traffic is generated to any other machine on the Internet, the packets should not be encrypted.

    Figure 10: VPN traffic rules configured in a Client-to-Site service

    Site-to-Site Connection

    In our scenario, the VPN master server is behind the NAT router. A slave server in the public network (150.2.0.0) establishes a connection with the master server behind NAT.

    To verify the Site-to-Site connection,

    1. Generate ping traffic from the VPN slave server to the VPN master server's tunnel IP address. Similarly, generate ping traffic from the master server to the VPN slave server's tunnel IP address. The ping traffic should pass through by establishing a Site-to-Site connection.
    2. Generate ping traffic from the protected client (C1; internal network of slave server) to the tunnel IP address of the master server.
    3. Generate ping traffic from the protected client (C2) of the master server ping to the tunnel IP address of the slave server.

    Steps 2 and 3 check for the connectivity of the Site-to-Site connection across protected networks of the server.

    In Site-to Site service you can define specific traffic rules with different combinations of encryption and authentication algorithms as required.

    TROUBLESHOOTING

    Here are some tips on troubleshooting. If you find more situations that need to be covered here, please contact the authors: Aruna Kumari () and Felix Xavier ().

    • It is recommended to disable RIP on the VPN server or NAT server. If RIP is enabled on the NAT router and on the VPN server behind NAT it causes a routing loop. To access the private address of the VPN server behind NAT, add the private network address as the protected network of the VPN server. This is the list of networks or hosts that would be protected by this site-to-site member. The VPN Server will advertise the protected network to other VPN members through the encrypted VPN tunnel. In case a private address connection is required, add the address as a protected network of the VPN server.
    • To avoid NAT/VPN problems, keep the NAT and VPN on separate machines. NAT changes the Layer 3 network address of a packet. In contrast, the tunneling used by an IPsec VPN gateway, encapsulates/encrypts the layer 3 network address of a packet with another layer 3 network address, stripping it off on the other side.
    • If packet filtering is configured on the NAT server, exceptions need to be defined on the NAT server to allow all VPN packets.
    • If the Automatic Certificate Retrieval (certificate retrieval feature) for VPN login causes any problem in getting a user certificate for the public client from VPN server behind NAT, copy the user certificate onto the client machine (in C:\Novell\VPNC\Certificates\Users) and establish the Client-to-Site connection.
    • If it is not possible to monitor a slave server in the member list behind NAT, then establish a NetWare Remote Manager connection directly with the slave.
    • If Site-to-Site doesn't come up after configuring Site-to-Site for the first time, synchronize the Master and Slave server using the synchronize button provided in the iManager Server Configuration Screen.
    • Ensure that all the NBM 3.8 Server and Clients are in time sync.
    • The traffic rules configured on the NBM 3.8 server and non-BorderManager VPN gateway should be identical, in order to establish Site-to-Site connection.

    LIMITATIONS

    Here are some of the limitations of the NBM 3.8 VPN server behind NAT:

    • VPN Clients earlier than NBM 3.8 are not supported for Client-to-Site connection with NBM 3.8 VPN server behind NAT.
    • NBM 3.7 slave cannot make Site-to-Site connection with the NBM 3.8 Master behind NAT.
    • NBM 3.8 server works only when configured with static NAT.
    • On a Windows XP desktop: After establishing a Client-to-Site connection with the VPN server, the VPN client GUI will display the internal VPN (private) server IP address. This can be observed when ping traffic is generated on the NAT'ed IP address after the Client-to-Site connection is established. This is not seen in other Windows platforms.

    CONCLUSION

    This AppNote discusses the benefits in deploying the Novell BorderManager 3.8 VPN master server behind NAT in a private network and various scenarios where it can be used. It provides information on how to configure NetWare server as a NAT device and deploy Novell BorderManager 3.8 VPN server behind the static NAT device. It also helps the user to successfully establish Client-to-Site and Site-to-Site VPN connections with the VPN master server and verify the connectivity.

    The results depicted in this AppNote are derived strictly from test scenarios. In real user scenarios, you may experience differences from these results. Novell does not recommend deploying untested configuration changes directly in a production network. You should always verify configuration changes on a simulated test network before you deploy into a production environment.


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

    © 2014 Novell