Page 176 / 234 Scroll up to view Page 171 - 175
Model FVL328 ProSafe High-Speed VPN Firewall Reference Manual Revision 2
E-6
Virtual Private Networking
May 2004, 202-10030-02
Key Management
IPSec uses the Internet Key Exchange (IKE) protocol to facilitate and automate the SA setup and
the exchange of keys between parties transferring data. Using keys ensures that only the sender
and receiver of a message can access it.
IPSec requires that keys be re-created, or refreshed, frequently, so that the parties can
communicate securely with each other. IKE manages the process of refreshing keys; however, a
user can control the key strength and the refresh frequency. Refreshing keys on a regular basis
ensures data confidentiality between sender and receiver.
Understand the Process Before You Begin
This document provides case studies on how to configure secure IPSec VPN tunnels. This
document assumes the reader has a working knowledge of NETGEAR management systems.
NETGEAR is a member of the VPN Consortium, a group formed to facilitate IPSec VPN vendor
interoperability. The VPN Consortium has developed specific scenarios to aid system
administrators in the often confusing process of connecting two different vendor implementations
of the IPSec standard. The case studies in this appendix follow the addressing and configuration
mechanics defined by the VPN Consortium. Additional information regarding inter-vendor
interoperability may be found at
.
It is a good idea to gather all the necessary information required to establish a VPN before you
begin the configuration process. You should understand whether the firmware is up to date, all of
the addresses that will be necessary, and all of the parameters that need to be set on both sides. Try
to understand any incompatibilities before you begin, so that you minimize any potential
complications which may arise from normal firewall or WAN processes.
If you are not a full-time system administrator, it is a good idea to familiarize yourself with the
mechanics of a VPN. The brief description in this appendix will help. Other good sources include:
The NETGEAR VPN Tutorial –
The VPN Consortium –
The VPN bibliography in
“Additional Reading“ on page E-11
.
Page 177 / 234
Model FVL328 ProSafe High-Speed VPN Firewall Reference Manual Revision 2
Virtual Private Networking
E-7
May 2004, 202-10030-02
VPN Process Overview
Even though IPSec is standards-based, each vendor has its own set of terms and procedures for
implementing the standard. Because of these differences, it may be a good idea to review some of
the terms and the generic processes for connecting two gateways before diving into the specifics.
Network Interfaces and Addresses
The VPN gateway is aptly named because it functions as a “gatekeeper” for each of the computers
connected on the Local Area Network behind it.
In most cases, each Gateway will have a “public” facing address (WAN side) and a “private”
facing address (LAN side). These addresses are referred to as the “network interface” in
documentation regarding the construction of VPN communication. Please note that the addresses
used in the example do not use full TCP/IP notation.
Interface Addressing
This TechNote uses example addresses provided the VPN Consortium. It is important to
understand that you will be using addresses specific to the devices that you are attempting to
connect via IPSec VPN.
Figure E-4:
VPNC Example Network Interface Addressing
It is also important to make sure the addresses do not overlap or conflict. That is, each set of
addresses should be separate and distinct.
Gateway A
22.23.24.25
14.15.16.17
10.5.6.0/24
172.23.9.0/24
172.23.9.1
10.5.6.1
WAN IP
WAN IP
LAN IP
LAN IP
Gateway B
VPNC Example
Network Interface Addressing
Page 178 / 234
Model FVL328 ProSafe High-Speed VPN Firewall Reference Manual Revision 2
E-8
Virtual Private Networking
May 2004, 202-10030-02
It will also be important to know the subnet mask of both gateway LAN Connections.
Firewalls
It is important to understand that many gateways are also firewalls. VPN tunnels cannot function
properly if firewall settings disallow all incoming traffic. Please refer to the firewall instructions
for both gateways to understand how to open specific protocols, ports, and addresses that you
intend to allow.
Setting Up a VPN Tunnel Between Gateways
An SA, frequently called a tunnel, is the set of information that allows two entities (networks, PCs,
routers, firewalls, gateways) to “trust each other” and communicate securely as they pass
information over the Internet.
Table 8-1.
WAN (Internet/Public) and LAN (Internal/Private) Addressing
Gateway
LAN or WAN
VPNC Example Address
Gateway A
LAN (Private)
10.5.6.1
Gateway A
WAN (Public)
14.15.16.17
Gateway B
LAN (Private)
22.23.24.25
Gateway B
WAN (Public)
172.23.9.1
Table 8-2.
Subnet Addressing
Gateway
LAN or WAN
Interface Name
Example Subnet Mask
Gateway A
LAN (Private)
Subnet Mask A
255.255.255.0
Gateway B
LAN (Private)
Subnet Mask B
255.255.255.0
Page 179 / 234
Model FVL328 ProSafe High-Speed VPN Firewall Reference Manual Revision 2
Virtual Private Networking
E-9
May 2004, 202-10030-02
Figure E-5:
VPN Tunnel SA
The SA contains all the information necessary for gateway A to negotiate a secure and encrypted
communication stream with gateway B. This communication is often referred to as a “tunnel.” The
gateways contain this information so that it does not have to be loaded onto every computer
connected to the gateways.
Each gateway must negotiate its Security Association with another gateway using the parameters
and processes established by IPSec. As illustrated below, the most common method of
accomplishing this process is via the Internet Key Exchange (IKE) protocol which automates some
of the negotiation procedures. Alternatively, you can configure your gateways using manual key
exchange, which involves manually configuring each paramter on both gateways.
Figure E-6:
IPSec SA negotiation
1.
The IPSec software on Host A initiates the IPSec process in an attempt to communicate
with Host B.
The two computers then begin the Internet Key Exchange (IKE) process.
A
B
VPN Gateway
VPN Gateway
1) Communication
request sent to VPN Gateway
2) IKE Phase I authentication
3) IKE Phase II negotiation
4) Secure data transfer
5) IPSec tunnel termination
IPSec Security Association IKE
VPN Tunnel Negotiation Steps
Page 180 / 234
Model FVL328 ProSafe High-Speed VPN Firewall Reference Manual Revision 2
E-10
Virtual Private Networking
May 2004, 202-10030-02
2.
IKE Phase I.
a.
The two parties negotiate the encryption and authentication algorithms to use in the IKE
SAs.
b.
The two parties authenticate each other using a predetermined mechanism, such as
preshared keys or digital certificates.
c.
A shared master key is generated by the Diffie-Hellman Public key algorithm within the
IKE framework for the two parties. The master key is also used in the second phase to
derive IPSec keys for the SAs.
3.
IKE Phase II.
a.
The two parties negotiate the encryption and authentication algorithms to use in the IPSec
SAs.
b.
The master key is used to derive the IPSec keys for the SAs. Once the SA keys are created
and exchanged, the IPSec SAs are ready to protect user data between the two VPN
gateways.
4.
Data transfer.
Data is transferred between IPSec peers based on the IPSec parameters and
keys stored in the SA database.
5.
IPSec tunnel termination.
IPSec SAs terminate through deletion or by timing out.
VPNC IKE Security Parameters
It is important to remember that both gateways must have the identical parameters set for the
process to work correctly. The settings in these examples follow the examples given for Scenario 1
of the VPN Consortium.
VPNC IKE Phase I Parameters
The IKE Phase 1 parameters used:
Main mode
TripleDES
SHA-1
MODP group 1
Ppre-shared secret of "hr5xb84l6aa9r6"
SA lifetime of 28800 seconds (eight hours)

Rate

4 / 5 based on 1 vote.

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top