In transport mode, the traffic will not be tunneled, and is
hence not applicable to VPN tunnels. It can be used to secure
a connection from a VPN client directly to the D-Link
Firewall,
for
example
for
IPsec
protected
remote
configuration.
This setting will typically be set to "tunnel" in most
configurations.
Remote Endpoint
The remote endpoint (sometimes also referred to as the
remote
gateway)
is
the
device
that
does
the
VPN
decryption/authentication and that passes the unencrypted
data on to its final destination. This field can also be set to
None, forcing the D-Link Firewall to treat the remote address
as the remote endpoint. This is particularly useful in cases of
roaming access, where the IP addresses of the remote VPN
clients are not known beforehand. Setting this to "none" will
allow anyone coming from an IP address conforming to the
"remote network" address discussed above to open a VPN
connection, provided they can authenticate properly.
The remote endpoint can be specified as a URL string such as
vpn.company.com. If this is done, the prefix dns: must be
used. The string above should therefore be specified as
dns:vpn.company.com.
The remote endpoint is not used in transport mode.
Main/Aggressive Mode
The IKE negotiation has two modes of operation, main mode
and aggressive mode.
The difference between these two is that aggressive mode will
pass more information in fewer packets, with the benefit of
slightly faster connection establishment, at the cost of
transmitting the identities of the security firewalls in the clear.
When using aggressive mode, some configuration parameters,
such as Diffie-Hellman groups and PFS, cannot be negotiated
and this mean it is important to have "compatible"
configurations at both ends.
IPsec Protocols
The IPsec protocols describe how the data will be processed.
The two protocols to choose from are AH, Authentication
Header, and ESP, Encapsulating Security Payload.
ESP provides encryption, authentication, or both. However, it
is not recommended to use encryption only, since it will
dramatically decrease security.
Note that AH only provides authentication. The difference
from ESP with authentication only is that AH also
authenticates parts of the outer IP header, for instance source
and destination addresses, making certain that the packet
really came from who the IP header claims it is from.
Note
NetDefendOS does not support AH.
IKE Encryption
This specifies the encryption algorithm used in the IKE
negotiation, and depending on the algorithm, the size of the
encryption key used.
9.3.2. Internet Key Exchange (IKE)
Chapter 9. VPN
335
Summary of Contents for 800 - DFL 800 - Security Appliance
Page 24: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 24 ...
Page 69: ...2 6 4 Restore to Factory Defaults Chapter 2 Management and Maintenance 69 ...
Page 121: ...3 9 DNS Chapter 3 Fundamentals 121 ...
Page 181: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 181 ...
Page 192: ...5 5 IP Pools Chapter 5 DHCP Services 192 ...
Page 282: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 282 ...
Page 300: ...mechanism 7 3 7 SAT and FwdFast Rules Chapter 7 Address Translation 300 ...
Page 301: ...7 3 7 SAT and FwdFast Rules Chapter 7 Address Translation 301 ...
Page 318: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 318 ...
Page 322: ...ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 322 ...
Page 377: ...Management Interface Failure with VPN Chapter 9 VPN 377 ...
Page 408: ...10 4 6 SLB_SAT Rules Chapter 10 Traffic Management 408 ...
Page 419: ...11 5 HA Advanced Settings Chapter 11 High Availability 419 ...
Page 426: ...12 3 5 Limitations Chapter 12 ZoneDefense 426 ...
Page 449: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 449 ...