1. Home
    2. /
  2. Manuals
    3. /
  3. NETGEAR
    4. /
  4. FWG114P
    5. /
  5. 52
Page 256 / 296 Scroll up to view Page 251 - 255
Reference Manual for the ProSafe Wireless 802.11g
Firewall/Print Server Model FWG114P v2
F-8
Virtual Private Networking
201-10301-02, May 2005
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 5-3.
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 5-4.
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 257 / 296
Reference Manual for the ProSafe Wireless 802.11g
Firewall/Print Server Model FWG114P v2
Virtual Private Networking
F-9
201-10301-02, May 2005
Figure F-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 F-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 258 / 296
Reference Manual for the ProSafe Wireless 802.11g
Firewall/Print Server Model FWG114P v2
F-10
Virtual Private Networking
201-10301-02, May 2005
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)
Page 259 / 296
Reference Manual for the ProSafe Wireless 802.11g
Firewall/Print Server Model FWG114P v2
Virtual Private Networking
F-11
201-10301-02, May 2005
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 260 / 296
Reference Manual for the ProSafe Wireless 802.11g
Firewall/Print Server Model FWG114P v2
F-12
Virtual Private Networking
201-10301-02, May 2005
•
[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
.

Rate

4 / 5 based on 1 vote.

Popular NETGEAR Models

Famous Router IPs
Famous Router Companies
Bookmark Our Site

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

Share
Top