1. Home
    2. /
  2. Manuals
    3. /
  3. NETGEAR
    4. /
  4. DG834GSP
    5. /
  5. 47
Page 231 / 268 Scroll up to view Page 226 - 230
Reference Manual for the Model Wireless ADSL Firewall Router DG834G
Virtual Private Networking
E-9
202-10006-05, June 2005
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
A
B
VPN Tunnel
DG834G VPN Firewall
DG834G VPN Firewall
PCs
PCs
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 232 / 268
Reference Manual for the Model Wireless ADSL Firewall Router DG834G
E-10
Virtual Private Networking
202-10006-05, June 2005
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.
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 TechNote 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"
Page 233 / 268
Reference Manual for the Model Wireless ADSL Firewall Router DG834G
Virtual Private Networking
E-11
202-10006-05, June 2005
•
SA lifetime of 28800 seconds (eight hours)
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
Page 234 / 268
Reference Manual for the Model Wireless ADSL Firewall Router DG834G
E-12
Virtual Private Networking
202-10006-05, June 2005
•
[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:
•
[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 235 / 268
NETGEAR VPN Configuration
F-1
202-10006-05, June 2005
Appendix F
NETGEAR VPN Configuration
DG834G to FVL328
This appendix is a case study on how to configure a secure IPSec VPN tunnel from a NETGEAR
DG834G to a FVL328. This case study follows the VPN Consortium interoperability profile
guidelines (found at
).
Configuration Profile
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.
Profile 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:
June 2004
Model/Firmware Tested:
NETGEAR-Gateway A
DG834G firmware version V2.10.17
NETGEAR-Gateway B
FVL328 with firmware version V2.0_07
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