Introduction. Technology background

(1)

Wh W hi i t t e e p pa ap pe e r: r : R Re ed d un u nd da an nt t I IP P- -V VP PN N n ne et tw wo or rk ks s

Introduction

IP VPN solutions based on the IPsec protocol are already available since a number of years. The main driver for these kinds of solutions is of course to save costs! If we can use the Internet to build secure tunnels between different locations it is definitely more affordable than to use a dedicated network such as a leased-line or a frame relay connection.

Internet connections also have typically a fixed monthly cost, more and more Internet broadband connections are available for a relatively low cost such as basic ADSL or cable modem connections.

The goal of this white paper is to describe the different options in order to make these IP VPN networks a viable alternative for existing networks.

We will describe some migration scenarios as well as some redundant configurations.

Technology background

The VPNs that we will discuss in this white paper are VPNs based on the IPsec suite of protocols. Traffic is tunneled, encrypted and authenticated before it is send over a public IP network which is in most cases the Internet.

All traffic will be encrypted via either a DES, 3DES or AES algorithm which makes it quite impossible to decode because the effective encryption keys will be renewed every hour via the IKE protocol. Authentication is performed via an authenticated hash which is added to every packet in order to be 100% sure that traffic is send from the party that you expect and that it is not altered in transit.

IPsec has one big drawback, due to the tunneling mechanism it adds at least

36 byte to every IP packet that is send to the remote site. As IP packets can

vary in length, typically between 64 and 1500 byte, the overhead caused by

IPsec can be quite significant, especially when a lot of small packets are used

such as in terminal emulation applications.

(2)

On the other hand IPsec is a very flexible technology which has been adopted by most vendors in this industry. It works over Internet connections with dynamic IP address assignment and you can use IPsec for both LAN-to-LAN connections as well as for mobile users.

Requirements for building business class VPNs

When, especially Internet based VPNs, are compared to more traditional solutions such as leased-lines, frame relay, ISDN, etc., there are two important issues which need to be taken into account: reliability and

performance. Before you can start comparing costs you need to be sure that the parameters regarding reliability and performance are comparable.

The Internet connection itself can never be treated as a reliable connection, however depending on the actual Internet connection points we will have more chance that the connection will be available or not. As we look at the Internet itself, it consists of several networks of different providers which are coupled together mainly via so-called Internet Exchanges. In most cases there are no bottlenecks in the provider network itself. Bottlenecks and as a result packet loss is in most cases only seen in the interconnections between different providers. This means that when you have 2 locations that are connected to the same ISP the chance is rather small that you do not have the full bandwidth available. This can be verified when you ask for a

topological drawing of the ISP network.

(3)

Internet ISP 1

Internet ISP 2

Router Router

Router

Router Router

Router

Concerning reliability, the solution that we propose is to use two independent connections, either one VPN connection and an ISDN connection as backup or two VPN connections via different Internet providers.

In the upcoming chapters we will clearly define how we can configure this via dynamic routing protocols on the NetScreen firewall/VPN appliances.

NetScreen firewall and VPN appliances

NetScreen is a supplier of hardware based firewall/VPN appliances which have a number of very interesting features which allows us to build highly redundant and scalable VPN networks.

In this white paper we will only highlight some features of these devices.

For a more general overview of these products we refer to their website http://www.netscreen.com The NetScreen device that is typically used in remote offices is the NetScreen 5GT or 5XT, both have 5 10/100 ports and a modem port. These devices support a so-called dual untrust mode which means that two Internet connections can be connected. What is also

supported is a dial-backup configuration whereby the NetScreen can initiate a PPP connection via for example an ISDN terminal adapter.

All NetScreen appliances support IPsec VPN tunnels. NetScreen has introduced a concept of tunnel interfaces and route based VPNs.

What NetScreen has achieved is that the VPN tunnels are seen as separate

connections with separate interfaces. All forwarding decisions for sending

traffic through tunnels is taken via the routing table.

(4)

As the tunnel interfaces have a status up or down as the tunnel is up or down we can use the routing table to create redundancy by defining different

routes to the same destination.

As dynamic routing protocols (RIP, OSPF, BGP) are supported in these devices we can dynamically re-route the traffic via other paths to the

destination, whether the destination can be reached via another VPN tunnel or via another router with for example an ISDN connection. In the next chapter we will describe some scenario’s which will show you the flexibility of these devices.

People with frame relay knowledge will automatically see the equivalent

between frame relay connections and IP VPN tunnels. Almost exactly the same behavior applies now to IP VPN tunnels as with frame relay connections.

In a NetScreen you can also define unnumbered tunnels as well as numbered tunnels whereby you configure IP addresses on the tunnel interfaces.

The IP VPN tunnels are seen as separate connections such as frame relay connections or dedicated connections via for example a leased-line.

Redundant VPN scenarios

Scenario 1: Migration from an existing ISDN dial network

In this first scenario we will see how a customer can implement an IP-VPN network over the Internet in combination with his existing ISDN dial network.

We will describe how we can configure the new VPN network as the primary network and how we can use the existing network as a backup. The goal is to change the existing ISDN network as minimal as possible so that the current situation is always available.

Current situation:

- at the central location: ISDN router with an ISDN primary rate connection - at the remote sites: ISDN routers with an ISDN basic rate connection As the communication is used more and more and as such the monthly ISDN bill, the customer wants to implement a new network with a fixed cost per month regardless of the amount of communication. However, the customer needs the same availability as with the existing, stable ISDN connection.

Our proposal:

- at the central location: NetScreen 204 appliance, leased line to the Internet

(5)

- at the remote sites: NS5XT connected to the Internet via ADSL There will be VPNs configured between the NetScreen 5XT and the central NetScreen 204. OSPF will be used as a dynamic routing protocol in order to establish the VPN tunnels and to exchange the routing information.

When a VPN tunnel is down, the corresponding tunnel interface will also be down. In the NetScreen 5XT we will configure a static route with a higher cost to the existing ISDN router, so that packets are send to the ISDN router instead of via the VPN tunnel. The ISDN router will then make an ISDN call to the central location.

E the rnet

Remote site

Et hernet

S D

CI S CO Y ST EM SS Cisco

1700 PWR O K W IC 0 AC T/C H 0 AC T/CH1 WI C0 ACT /C H0 A CT/ CH 1 ET H ACT CO L SE RI ES RO U TER

NetScreen 204

Internal database

IPsec VPN tunnel Internet

Central site

SD CISCO YSTEMSS

Cisco 3600SERIES

ISDN

SD

C IS C O Y S TE MSS Cisco

1700 PWR OK W IC0 ACT/ C H0 AC T/ CH 1 WIC 0 AC T/ CH0 A CT /C H1 E TH A CT C OL SE RIES R O UTER

ADSL modem

NetScreen 5XT

Via this mechanism it is not necessary to make any changes on the existing ISDN router, the only thing that we need to change on the remote site is the default gateway of all the systems that need connectivity with the central site. On the central NetScreen 204 we will configure inbound network address translation in order to avoid that we need to change the default gateway of the central systems.

Via the mechanism that we have described we can build up the new network site per site without affecting the other sites whether they are working via ISDN or via the VPN tunnel.

The ADSL connections on the remote site can be very basic Internet

connections with dynamic IP address assignment. The NetScreen devices can handle dynamic IP addresses on the remote site without any problem.

In this case the VPN will always be established from the remote site to the

central site. As soon as the VPN is established it will be possible to initiate

sessions from the central site to the remote location.

(6)

Scenario 2: Building a new redundant VPN network

In this second scenario we assume a customer that needs to build a highly redundant network between one central site and multiple remote sites.

The proposal that we would make in this case is to build a redundant IP VPN network based on VPN connections via two different and independent

Internet providers.

What we will propose:

- at the central location: two NetScreen 204 appliances, two leased-lines or SDSL connections

- at the remote sites: NS5XT connected to the Internet via ADSL and cable modem

The key issue in this network topology is the fact that we create two tunnels from every remote site to the central site via two completely independent providers. At the central site we foresee two leased-line connections to the two different providers, each connected to a separate NetScreen 204.

At the remote site we will connect both the ADSL as well as the cable connection to the NetScreen 5XT. The NetScreen 5XT will establish two tunnels to the two NetScreen 204 appliances at the central site.

E the rnet

Remote site

Et hernet

S D

NetScreen 204

Internal mail server

Internal database

IPsec VPN tunnels

NetScreen 204

S D

Internet

Central site

Modem NetScreen 5XT

When the primary tunnel is down, all traffic will be re-routed via the other VPN tunnel. This can happen when there is a problem with the provider, the access line or when there is a problem on the central site with either the router, leased-line or NetScreen.

If the NetScreen 5XT is connected to both the ADSL network as well as the

cable network the redundancy is even added on a physical level. As the ADSL

network is using the telephone copper pair and the cable network is using the

coax cable of the television distribution this is a much higher redundancy

(7)

than using for example ISDN as a backup because ISDN is typically using exactly the same copper pair as your ADSL connection. If there is a physical problem with the cable neither of these will work!

An extension to the above described network is to use two different NetScreen 5XT devices in every remote office. This adds a device level redundancy for the NetScreen 5XT. Although these boxes are very reliable you can install both of these boxes in order to make the network even more redundant. The routing over the VPN tunnels will also be done via a dynamic routing protocol such as OSPF as described above.

Conclusion

As you have read in this white paper we can create highly redundant IP-VPN networks with the NetScreen appliances. Due to the implementation of tunnel interfaces and route based VPNs in combination with dynamic routing

protocols very intelligent networks can be configured to overcome the limits of IP-VPNs over the public Internet.

Several scenarios can be implemented to migrate existing networks towards these topologies. The migration scenarios are very important because these give you the opportunity to test the new network before you actually touch or change the existing network. This way even the most skeptic people towards this technology can be convinced of its value especially if they compare the monthly costs with expensive private networks!

As our proposal is completely provider independent it offers a way to constantly looking for new opportunities. If for example a new wireless Internet provider is available at some locations you could do some testing with this provider. If costs and performance are better than the existing one you can quite easily change without adapting the configuration of the

network. From an end-to-end point of view the network does not change, the only thing that changes is the configuration of the NetScreen devices which can be done remotely.

About the author

Frank Staut is a senior consultant and co-founder of the company SecureLink. Frank has more than 10 years of experience in the