1. Home
    2. /
  2. Manuals
    3. /
  3. Zyxel
    4. /
  4. VMG8324-B10A
    5. /
  5. 47
Page 231 / 404 Scroll up to view Page 226 - 230
Chapter 20 VPN
VMG8324-B10A / VMG8324-B30A Series User’s Guide
231
Figure 141
Two Phases to Set Up the IPSec SA
In phase 1 you must:
•
Choose a negotiation mode.
•
Authenticate the connection by entering a pre-shared key.
•
Choose an encryption algorithm.
•
Choose an authentication algorithm.
•
Choose a Diffie-Hellman public-key cryptography key group
.
•
Set the IKE SA lifetime. This field allows you to determine how long an IKE SA should stay up
before it times out. An IKE SA times out when the IKE SA lifetime period expires. If an IKE SA
times out when an IPSec SA is already established, the IPSec SA stays connected.
In phase 2 you must:
•
Choose an encryption algorithm.
•
Choose an authentication algorithm
•
Choose a Diffie-Hellman public-key cryptography key group
.
•
Set the IPSec SA lifetime. This field allows you to determine how long the IPSec SA should stay
up before it times out. The Device automatically renegotiates the IPSec SA if there is traffic when
the IPSec SA lifetime period expires. If an IPSec SA times out, then the IPSec router must
renegotiate the SA the next time someone attempts to send traffic.
20.5.4
Negotiation Mode
The phase 1
Negotiation Mode
you select determines how the Security Association (SA) will be
established for each connection through IKE negotiations.
•
Main Mode
ensures the highest level of security when the communicating parties are
negotiating authentication (phase 1). It uses 6 messages in three round trips: SA negotiation,
Diffie-Hellman exchange and an exchange of nonces (a nonce is a random number). This mode
features identity protection (your identity is not revealed in the negotiation).
Page 232 / 404
Chapter 20 VPN
VMG8324-B10A / VMG8324-B30A Series User’s Guide
232
•
Aggressive Mode
is quicker than
Main Mode
because it eliminates several steps when the
communicating parties are negotiating authentication (phase 1). However the trade-off is that
faster speed limits its negotiating power and it also does not provide identity protection. It is
useful in remote access situations where the address of the initiator is not know by the responder
and both parties want to use pre-shared key authentication.
20.5.5
IPSec and NAT
Read this section if you are running IPSec on a host computer behind the Device.
NAT is incompatible with the
AH
protocol in both
Transport
and
Tunnel
mode. An IPSec VPN using
the
AH
protocol digitally signs the outbound packet, both data payload and headers, with a hash
value appended to the packet. When using
AH
protocol, packet contents (the data payload) are not
encrypted.
A NAT device in between the IPSec endpoints will rewrite either the source or destination address
with one of its own choosing. The VPN device at the receiving end will verify the integrity of the
incoming packet by computing its own hash value, and complain that the hash value appended to
the received packet doesn't match. The VPN device at the receiving end doesn't know about the
NAT in the middle, so it assumes that the data has been maliciously altered.
IPSec using
ESP
in
Tunnel
mode encapsulates the entire original packet (including headers) in a
new IP packet. The new IP packet's source address is the outbound address of the sending VPN
gateway, and its destination address is the inbound address of the VPN device at the receiving end.
When using
ESP
protocol with authentication, the packet contents (in this case, the entire original
packet) are encrypted. The encrypted contents, but not the new headers, are signed with a hash
value appended to the packet.
Tunnel
mode
ESP
with authentication is compatible with NAT because integrity checks are
performed over the combination of the "original header plus original payload," which is unchanged
by a NAT device.
Transport
mode
ESP
with authentication is not compatible with NAT.
20.5.6
VPN, NAT, and NAT Traversal
NAT is incompatible with the AH protocol in both transport
and tunnel
mode. An IPSec VPN using
the AH protocol digitally signs the outbound packet, both data payload and headers, with a hash
value appended to the packet, but a NAT device between the IPSec endpoints rewrites the source or
destination address. As a result, the VPN device at the receiving end finds a mismatch between the
hash value and the data and assumes that the data has been maliciously altered.
NAT is not normally compatible with ESP in transport mode either, but the Device’s
NAT Traversal
feature provides a way to handle this. NAT traversal allows you to set up an IKE SA when there are
NAT routers between the two IPSec routers.
Table 106
VPN and NAT
SECURITY PROTOCOL
MODE
NAT
AH
Transport
N
AH
Tunnel
N
ESP
Transport
N
ESP
Tunnel
Y
Page 233 / 404
Chapter 20 VPN
VMG8324-B10A / VMG8324-B30A Series User’s Guide
233
Figure 142
NAT Router Between IPSec Routers
Normally you cannot set up an IKE SA with a NAT router between the two IPSec routers because
the NAT router changes the header of the IPSec packet. NAT traversal solves the problem by adding
a UDP port 500 header to the IPSec packet. The NAT router forwards the IPSec packet with the UDP
port 500 header unchanged. In the above figure, when IPSec router
A
tries to establish an IKE SA,
IPSec router
B
checks the UDP port 500 header, and IPSec routers
A
and
B
build the IKE SA.
For NAT traversal to work, you must:
•
Use ESP security protocol (in either transport or tunnel mode).
•
Use IKE keying mode.
•
Enable NAT traversal on both IPSec endpoints.
•
Set the NAT router to forward UDP port 500 to IPSec router
A
.
Finally, NAT is compatible with ESP in tunnel mode because integrity checks are performed over the
combination of the "original header plus original payload," which is unchanged by a NAT device. The
compatibility of AH and ESP with NAT in tunnel and transport modes is summarized in the following
table.
Y* - This is supported in the Device if you enable NAT traversal.
20.5.7
ID Type and Content
With aggressive negotiation mode (see
Section 20.5.4 on page 231
), the Device identifies incoming
SAs by ID type and content since this identifying information is not encrypted. This enables the
Device to distinguish between multiple rules for SAs that connect from remote IPSec routers that
have dynamic WAN IP addresses.
Regardless of the ID type and content configuration, the Device does not allow you to save multiple
active rules with overlapping local and remote IP addresses.
With main mode (see
Section 20.5.4 on page 231
), the ID type and content are encrypted to
provide identity protection. In this case the Device can only distinguish between up to 12 different
incoming SAs that connect from remote IPSec routers that have dynamic WAN IP addresses. The
Device can distinguish up to 48 incoming SAs because you can select between three encryption
algorithms (DES, 3DES and AES), two authentication algorithms (MD5 and SHA1) and eight key
groups when you configure a VPN rule (see
Section 20.2 on page 221
). The ID type and content act
as an extra level of identification for incoming SAs.
Table 107
VPN and NAT
SECURITY PROTOCOL
MODE
NAT
AH
Transport
N
AH
Tunnel
N
ESP
Transport
Y*
ESP
Tunnel
Y
A
B
Page 234 / 404
Chapter 20 VPN
VMG8324-B10A / VMG8324-B30A Series User’s Guide
234
The type of ID can be a domain name, an IP address or an e-mail address. The content is the IP
address, domain name, or e-mail address.
20.5.7.1
ID Type and Content Examples
Two IPSec routers must have matching ID type and content configuration in order to set up a VPN
tunnel.
The two Devices in this example can complete negotiation and establish a VPN tunnel.
The two Devices in this example cannot complete their negotiation because Device B’s
Local ID
Type
is
IP
, but Device A’s
Remote ID Type
is set to
E-mail
. An “ID mismatched” message
displays in the IPSEC LOG.
20.5.8
Pre-Shared Key
A pre-shared key identifies a communicating party during a phase 1 IKE negotiation (see
Section
20.5.3 on page 230
for more on IKE phases). It is called “pre-shared” because you have to share it
with another party before you can communicate with them over a secure connection.
20.5.9
Diffie-Hellman (DH) Key Groups
Diffie-Hellman (DH) is a public-key cryptography protocol that allows two parties to establish a
shared secret over an unsecured communications channel. Diffie-Hellman is used within IKE SA
setup to establish session keys. Upon completion of the Diffie-Hellman exchange, the two peers
have a shared secret, but the IKE SA is not authenticated. For authentication, use pre-shared keys.
Table 108
Local ID Type and Content Fields
LOCAL ID TYPE=
CONTENT=
IP
Type the IP address of your computer.
DNS
Type a domain name (up to 31 characters) by which to identify this Device.
E-mail
Type an e-mail address (up to 31 characters) by which to identify this Device.
The domain name or e-mail address that you use in the
Local ID
Content
field is used
for identification purposes only and does not need to be a real domain name or e-mail
address.
Table 109
Matching ID Type and Content Configuration Example
Device A
Device B
Local ID type: E-mail
Local ID type: IP
Local ID content: [email protected]
Local ID content: 1.1.1.2
Remote ID type: IP
Remote ID type: E-mail
Remote ID content: 1.1.1.2
Remote ID content: [email protected]
Table 110
Mismatching ID Type and Content Configuration Example
DEVICE A
DEVICE B
Local ID type: IP
Local ID type: IP
Local ID content: 1.1.1.10
Local ID content: 1.1.1.2
Remote ID type: E-mail
Remote ID type: IP
Remote ID content: [email protected]
Remote ID content: 1.1.1.0
Page 235 / 404
VMG8324-B10A / VMG8324-B30A Series User’s Guide
235
C
HAPTER
21
Voice
21.1
Overview
Use this chapter to:
•
Connect an analog phone to the Device.
•
Make phone calls over the Internet, as well as the regular phone network.
•
Configure settings such as speed dial.
•
Configure network settings to optimize the voice quality of your phone calls.
21.1.1
What You Can Do in this Chapter
These screens allow you to configure your Device to make phone calls over the Internet and your
regular phone line, and to set up the phones you connect to the Device.
•
Use the
SIP Account
screen (
Section 21.3 on page 236
) to set up information about your SIP
account, control which SIP accounts the phones connected to the Device use and configure audio
settings such as volume levels for the phones connected to the Device.
•
Use the
SIP Service Provider
screen (
Section 21.4 on page 241
) to configure the SIP server
information, QoS for VoIP calls, the numbers for certain phone functions, and dialing plan.
•
Use the
PhoneRegion
screen (
Section 21.5 on page 249
) to change settings that depend on the
country you are in.
•
Use the
Call Rule
screen (
Section 21.6 on page 249
) to set up shortcuts for dialing frequently-
used (VoIP) phone numbers.
•
Use the
Call History Summary
screen (
Section 21.7 on page 250
) to view the summary list of
received, dialed and missed calls.
•
Use the
Call History Outgoing
screen (
Section 21.8 on page 251
) to view detailed information
for each outgoing call you made.
•
Use the
Call History Incoming
screen (
Section 21.9 on page 251
) to view detailed information
for each incoming call from someone calling you.
You don’t necessarily need to use all these screens to set up your account. In fact, if your service
provider did not supply information on a particular field in a screen, it is usually best to leave it at
its default setting.

Rate

4 / 5 based on 1 vote.

Popular Zyxel Models

Famous Router IPs
Famous Router Companies
Bookmark Our Site

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

Share
Top