VPN Tunnels

This section includes the following topics:

 

A VPN Tunnel defines an endpoint of an encrypted tunnel. Each VPN Tunnel is interpreted as a logical interface by the  firewall, with the same filtering, traffic shaping and configuration capabilities as regular interfaces.

When another Amaranten Firewall or a Amaranten VPN Client (or any IPSec compliant product) tries to establish a VPN tunnel to  this firewall, the configured VPN Tunnels are evaluated. If a matching VPN Tunnel definition is found, the IKE and IPSec  negotiations will start and eventually, the VPN tunnel is established.

Please note that an established VPN tunnel does not automatically mean that all traffic from that VPN tunnel is  trusted. On the contrary, network traffic that has been decrypted will be transferred to the firewall ruleset for further  evaluation. The source interface of the decrypted network traffic will be the name of the associated VPN Tunnel. Furthermore,  a Route or an Access rule, in the case of a roaming client,  has to be defined to have the firewall accept certain source IP addresses from the VPN tunnel.

For network traffic in the opposite direction, that is, going into a VPN tunnel, a reversed process takes place.  First, the unencrypted traffic is evaluated by the firewall ruleset. If a rule and route matches, the firewall tries to find an established VPN tunnel that matches the criteria. If not found, the firewall will try  to establish a tunnel to the remote gateway specified by the matching VPN Tunnel definition.

For an example of how to setup a VPN tunnel between a Amaranten VPN Client and a firewall and more examples, please see the VPN Resources section.

Note: IKE and ESP/AH traffic are sent to the IPSec engine before the firewall ruleset is consulted. Thus, encrypted  traffic to the firewall does not need to be allowed in the ruleset. This behaviour can be changed in the IPSec Advanced Settings section.

VPN Tunnels configuration

VPN Tunnels are defined in the VPN Tunnels configuration section located in the Interfaces folder.

General Parameters

Name ?A symbolic name for the VPN connection.

Local Network - The network on "this side" of the VPN tunnel. The VPN tunnel will be established between this network and the remote network.

Remote Network - The network connected to the remote gateway. The VPN tunnel will be established between the local network and this network.

Remote Gateway ?Specifies the IP address of the remote gateway. This is the address the firewall will establish the VPN tunnel to. It also dictates from where inbound VPN tunnels are allowed. In "roaming client" scenarios, this can be set to "none" in which case inbound tunnels are allowed as long as they match the remote network. Outbound tunnels will be established to the original destination.

IKE Proposal List - Specifies the IKE Proposal list used with the tunnel.

IPSEC Proposal List - Specifies the IPSEC Proposal list used with the tunnel.

Authentication

Pre-Shared Key

Pre-Shared Key - Selects the Pre-shared key to use with this VPN Tunnel.

X.509 Certificate

Gateway Certificate ?Selects the certificate the firewall uses to authenticate itself to the other IPsec peer.

Root Certificates ?Selects one or more root certificates to use with this VPN Tunnel.

The root certificate is either a ?rusted host?certificate, which is a certificate of some end-entity that should be allowed to establish a VPN tunnel.

It can also be a CA certificate, in which case all certificates signed by that CA are allowed to establish a VPN tunnel, provided the other entitys identity is present in the identification list.

Identification List ?Selects the identification list to use with this VPN Tunnel.

An identification list is a list of the identities that are allowed to establish a VPN tunnel.

Require IKE Xauth user authentication for inbound VPN tunnels - If selected requires that a user has authenticated with Xauth before the tunnel is opened.

Routing

Automatic routing

Allow DHCP over IPSec - Enable this to use Acquire Virtual IP in the VPN Client.

Dynamically add route to the remote networks when a tunnel is established - If the firewall should dynamically add routes as tunnels are added and removed.

IP Addresses

What IP Address should be used when the firewall itself is the sender, for NAT or when the firewall is logging through a VPN tunnel.

 

IKE

IKE

Main- & Aggressive mode ?Selects whether main mode or aggressive mode should be used when establishing outbound VPN Tunnels. Inbound main mode connections will always be allowed. Inbound aggressive mode connections will only be allowed if this setting is set to aggressive mode.

Perfect forwarding secrecy (PFS)

PFS ?Specifies whether PFS should be used or not.

DH Group (Diffie-Hellman Group) ?If PFS is enabled, this specifies which diffie-hellman group to use.

Security Association

Per Host - If this is selected, a new tunnel will be created for every two hosts communicating through this VPN tunnel. All VPN tunnels are initiated by the firewall on a per-host basis. Inbound tunnels are only accepted if the remote network (the initiator's local network) is a single IP address.

Per Net - If this is selected, a VPN tunnel will be created between the two networks given in local net and remote net. All traffic sent between these networks will use the same tunnel.

Compatibility Flags

Don't Verify Padding ?Compatibility setting. Should typically not need to be changed.

Data packets often have to be padded before they can be encrypted. This is due to the way block-based encryption algorithms work; the data is divided into blocks of a certain size before each block is encrypted individually. Sometimes the last part of a packet is smaller than the block size used by the encryption algorithm. In these cases extra padding data is added to the end of the packet. This padding should be a specific pattern. If this setting is disabled, an inbound ESP packet is only accepted if the padding is of the expected pattern. If this setting is enabled, the padding data is ignored.

NAT Traversal

Off - The firewall does not send the Vendor ID's that include NAT-T support when setting up the tunnel.

On if supported and NATed - Will only use NAT-T if one of the VPN gateways is NATed.

On if supported - Always tries to use NAT-T when setting up the tunnel.

 

Keep-alive

Keep-alive

Disabled ?Keep-alive is disabled.

Auto - The firewall will send ICMP pings to IP Addresses automatically discovered from the VPN Tunnel settings, and if the other side is also a 8.20 or later it will answer on the ping.

Manually configured IP addresses - Configure the source and destination IP addresses used when sending the ICMP pings.