1. Home
    2. /
  2. Manuals
    3. /
  3. Zyxel
    4. /
  4. F1000
    5. /
  5. 45
Page 221 / 359 Scroll up to view Page 216 - 220
Chapter 18 VPN
eircom F1000 Modem User’s Guide
221
Figure 133
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.
18.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 222 / 359
Chapter 18 VPN
eircom F1000 Modem User’s Guide
222
•
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.
18.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.
18.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 96
VPN and NAT
SECURITY PROTOCOL
MODE
NAT
AH
Transport
N
AH
Tunnel
N
ESP
Transport
N
ESP
Tunnel
Y
Page 223 / 359
Chapter 18 VPN
eircom F1000 Modem User’s Guide
223
Figure 134
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.
18.5.7
ID Type and Content
With aggressive negotiation mode (see
Section 18.5.4 on page 221
), 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 18.5.4 on page 221
), 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 18.2 on page 211
). The ID type and content act
as an extra level of identification for incoming SAs.
Table 97
VPN and NAT
SECURITY PROTOCOL
MODE
NAT
AH
Transport
N
AH
Tunnel
N
ESP
Transport
Y*
ESP
Tunnel
Y
A
B
Page 224 / 359
Chapter 18 VPN
eircom F1000 Modem User’s Guide
224
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.
18.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.
18.5.8
Pre-Shared Key
A pre-shared key identifies a communicating party during a phase 1 IKE negotiation (see
Section
18.5.3 on page 220
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.
18.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 98
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 99
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 100
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 225 / 359
eircom F1000 Modem User’s Guide
225
C
HAPTER
19
Log
19.1
Overview
The web configurator allows you to choose which categories of events and/or alerts to have the
Device log and then display the logs or have the Device send them to an administrator (as e-mail)
or to a syslog server.
19.1.1
What You Can Do in this Chapter
•
Use the
System Log
screen to see the system logs (
Section 19.2 on page 226
).
•
Use the
Security Log
screen to see the security-related logs for the categories that you select
(
Section 19.3 on page 227
).
19.1.2
What You Need To Know
The following terms and concepts may help as you read this chapter.
Alerts and Logs
An alert is a type of log that warrants more serious attention. They include system errors, attacks
(access control) and attempted access to blocked web sites. Some categories such as
System
Errors
consist of both logs and alerts. You may differentiate them by their color in the
View Log
screen. Alerts display in red and logs display in black.
Syslog Overview
The syslog protocol allows devices to send event notification messages across an IP network to
syslog servers that collect the event messages. A syslog-enabled device can generate a syslog
message and send it to a syslog server.
Syslog is defined in RFC 3164. The RFC defines the packet format, content and system log related
information of syslog messages. Each syslog message has a facility and severity level. The syslog
facility identifies a file in the syslog server. Refer to the documentation of your syslog program for
details. The following table describes the syslog severity levels.
Table 101
Syslog Severity Levels
CODE
SEVERITY
0
Emergency: The system is unusable.
1
Alert: Action must be taken immediately.
2
Critical: The system condition is critical.
3
Error: There is an error condition on the system.
4
Warning: There is a warning condition on the system.

Rate

3.5 / 5 based on 2 votes.

Popular Zyxel Models

Famous Router IPs
Famous Router Companies
Bookmark Our Site

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

Share
Top