1. Home
    2. /
  2. Manuals
    3. /
  3. NETGEAR
    4. /
  4. FVS328
    5. /
  5. 35
Page 171 / 224 Scroll up to view Page 166 - 170
Model FVS328 ProSafe VPN Firewall with Dial Back-up Reference Manual
Virtual Private Networking
E-9
December 2003, M-10041-01
Figure 9-8:
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 9-9:
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 172 / 224
Model FVS328 ProSafe VPN Firewall with Dial Back-up Reference Manual
E-10
Virtual Private Networking
December 2003, M-10041-01
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
•
pre-shared secret of "hr5xb84l6aa9r6"
•
SA lifetime of 28800 seconds (eight hours)
Page 173 / 224
Model FVS328 ProSafe VPN Firewall with Dial Back-up Reference Manual
Virtual Private Networking
E-11
December 2003, M-10041-01
VPNC IKE Phase II Parameters
The IKE Phase 2 parameters used in Scenario 1 are:
•
TripleDES
•
SHA-1
•
ESP tunnel mode
•
MODP group 1
•
Perfect forward secrecy for rekeying
•
SA lifetime of 28800 seconds (one hour)
Testing and Troubleshooting
Once you have completed the VPN configuration steps you can use PCs, located behind each of
the gateways, to ping various addresses on the LAN-side of the other gateway.
You can troubleshoot connections using the VPN status and log details on the NETGEAR gateway
to determine if IKE negotiation is working. Common problems encountered in setting up VPNs
include:
•
Parameters may be configured differently on Gateway A vs. Gateway B.
•
Two LANs set up with similar or overlapping addressing schemes.
•
So many required configuration parameters mean errors such as mistyped information or
mismatched parameter selections on either side are more likely to happen.
Additional Reading
•
Building and Managing Virtual Private Networks
, Dave Kosiur, Wiley & Sons; ISBN:
0471295264
•
Firewalls and Internet Security: Repelling the Wily Hacker
, William R. Cheswick and Steven
M. Bellovin, Addison-Wesley; ISBN: 0201633574
•
VPNs A Beginners Guide
, John Mains, McGraw Hill; ISBN: 0072191813
•
[FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End Congestion Control in the
Internet. IEEE/ACM Transactions on Networking, August 1999.
Relevant RFCs listed numerically:
Page 174 / 224
Model FVS328 ProSafe VPN Firewall with Dial Back-up Reference Manual
E-12
Virtual Private Networking
December 2003, M-10041-01
•
[RFC 791]
Internet Protocol DARPA Internet Program Protocol Specification
, Information
Sciences Institute, USC, September 1981.
•
[RFC 1058]
Routing Information Protocol
, C Hedrick, Rutgers University, June 1988.
•
[RFC 1483]
Multiprotocol Encapsulation over ATM Adaptation Layer 5
, Juha Heinanen,
Telecom Finland, July 1993.
•
[RFC 2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol
, RFC 2401,
November 1998.
•
[RFC 2407] D. Piper, The Internet IP Security Domain of Interpretation for ISAKMP
,
November 1998.
•
[RFC 2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers
, December 1998.
•
[RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An
Architecture for Differentiated Services
, December 1998.
•
[RFC 2481] K. Ramakrishnan, S. Floyd, A Proposal to Add Explicit Congestion Notification
(ECN) to IP
, January 1999.
•
[RFC 2408] D. Maughan, M. Schertler, M. Schneider, J. Turner, Internet Security Association
and Key Management Protocol (ISAKMP)
.
•
[RFC 2409] D. Harkins, D.Carrel, Internet Key Exchange
(IKE) protocol.
•
[RFC 2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol
.
Page 175 / 224
NETGEAR VPN Configuration FVS318 or FVM318 to FVS328
F-1
December 2003, M-10041-01
Appendix F
NETGEAR VPN Configuration
FVS318 or FVM318 to FVS328
This appendix provides a case study on how to configure a secure IPSec VPN tunnel between a
NETGEAR FVS318 or FVM318 to a FVS328. The configuration options and screens for the
FVS318 and FVM318 are the same.
Configuration Template
The configuration in this document follows the addressing and configuration mechanics defined
by the VPN Consortium. Gather all the necessary information before you begin the configuration
process. Verify 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. Check that there are no firewall restrictions.
Table F-1.
Summary
VPN Consortium Scenario:
Scenario 1
Type of VPN
LAN-to-LAN or Gateway-to-Gateway (not PC/Client-to-Gateway)
Security Scheme:
IKE with Preshared Secret/Key (not Certificate-based)
Date Tested:
December 2003
Model/Firmware Tested:
NETGEAR-Gateway A
FVS318 firmware version A1.4 or 2.0; FVM318 firmware version 1.1
NETGEAR-Gateway B
FVS328 with firmware version 1.0 Release 00
IP Addressing:
NETGEAR-Gateway A
Static IP address
NETGEAR-Gateway B
Static IP address

Rate

3.5 / 5 based on 2 votes.

Popular NETGEAR Models

Famous Router IPs
Famous Router Companies
Bookmark Our Site

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

Share
Top