Pfsense не работает ipsec

Pfsense не работает ipsec

• Главная
• ТЕХНИЧЕСКАЯ
• LINUX
• Pfsense (интернет-шлюз)
• PfSense — удалённый доступ к офисной сети через VPN (IPSec/L2TP)

PfSense — удалённый доступ к офисной сети через VPN (IPSec/L2TP)

Иногда сотрудникам компаний требуется возможность воспользоваться внутренними локальными ресурсами компании (базы, файловые хранилища и т.д.) в дороге (с мобильных рабочих мест) или из дома (с домашних компьютеров).

Для удалённого доступа к ресурсам офисной сети компании очень хорошим решением является создание VPN соединения. PfSense для этих задач достаточно удобен и функционален.

рабочая сеть (офис): 192.168.1.0/24

интенет шлюз (PfSense 2.4.3): 192.168.1.102(LAN) , 192.168.4.232(WAN)

Настройка L2TP

В верхнем меню выбираем VPN — L2TP

после включения L2TP и сохранения настроек, переходим на вкладку Users и добавляем пользователя

Настройка IPsec

В верхнем меню выбираем VPN — IPsec — Mobile Clients

после сохранения и применения изменений нажимаем кнопку + Create Phase 1

создаём первую фазу

после сохранения и применения изменений раскрываем список второй фазы

создаём вторую фазу

сохраняем затем применяем изменения и переходим на вкладку Pre-Shared Keys и добавляем ключ с идентификатором any (этот ключ будет использоваться для любого пользователя)

Настройка правил сетевой защиты

переходим в раздел Firewall — Rules и создаём следующие правила:

Настройка клиента WINDOWS 7

Центр управления сетями и общим доступом — Настройка нового подключения или сети — Подключение к рабочему месту — Использовать моё подключение к интернету

После сбоя подключения выбрать вариант Всё равно создать это подключение

Перейти в раздел Сетевые подключения открыть свойства созданого VPN-подключения

Чтобы удалённый компьютер не использовал VPN канал для доступа в интернет убираем галку Использовать основной шлюз в удалённой сети

На этом настройка закончена.

Для проверки подключаемся по созданому VPN-подключению и проверяем ping 192.168.1.102 (или любое другое сетевое устройство в офисной сети).

Ошибка 788 и 789

Запустите редактор реестра и перейдите в раздел HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters. Далее для параметра AllowL2TPWeakCrypto установите значение 1, а также создайте DWORD-параметр ProhibitIpSec и для него также установите значение 1 . После этого нужо перезагрузить компьютер. Данное решение универсальное и подходит, как для Windows 7, так и для Windows 10.

Источник

forum.lissyara.su

Пока противник рисует карты наступления, мы меняем ландшафты, причём вручную

pfSense IPSec+NAT-Traversal не получается пробится через NAT

Модератор: terminus

pfSense IPSec+NAT-Traversal не получается пробится через NAT

Поставил на виртуалку pfSense решил попробовать связать два pfSense’а посредством IPSec c использованием NAT-Traversal.
Только вот, один смотрит в инет прямым IP, а второй за NAT’ом. При совершенно идентичных настройках обоих pfSense’ов по
каким-то, непонятным причинам, IPSec не «поднимается».

Причем первый pfSense, (который с прямым IP), при настройке IPSec без NAT-Traversal, совершенно без проблем подключается
к шлюзу (FreeBSD+racoon, тоже с прямым IP). А вот к pfSense’у, который за NAT’ом (за этим же шлюзом), подключаться не хочет.

Firewall и там и там настроен на пропуск ISAKMP ESP и NAT-T

Видимо где-то что-то не так настраивал. IPSec c NAT-Traversal первый раз пытаю.

Есть у кого-нибудь соображения, что где надо донастроить?

И вообще, как правильно настроить IPSec c NAT-Traversal.
В инете к сожалению нет толковой статьи на эту тему.

Услуги хостинговой компании Host-Food.ru

Re: pfSense IPSec+NAT-Traversal не получается пробится через

Для начала в конфиге «racoon» на хосте что за NAT впишы:

listen
<
isakmp 192.168.255.3 [500];
>

192.168.255.3 — свой адрес.

Re: pfSense IPSec+NAT-Traversal не получается пробится через

Re: pfSense IPSec+NAT-Traversal не получается пробится через

andrian_freebsd писал(а): Для начала в конфиге «racoon» на хосте что за NAT впишы:

listen
<
isakmp 192.168.255.3 [500];
>

192.168.255.3 — свой адрес.

Re: pfSense IPSec+NAT-Traversal не получается пробится через

Re: pfSense IPSec+NAT-Traversal не получается пробится через

Ну, я бы не сказал. Сам всё гораздо сложнее и запутанней чем есть всё на самом деле.

Ну да ладно, я не об этом.

Так это-то всё понятно, я не однократно перелопачивал эту документацию.
В подтверждении этому контора, в которой работаю, использует, и уже достаточно продолжительное время, для связи с удаленными филиалами IPSec (racoon) на основном шлюзе + racoon, D-Link DI824, D-Link DI808, D-Link DSR-150N ну и racoon на pfSense и т.д., в качестве шлюзов в филиалах. И, собственно всё работает. Но, работает только на белых IP.
А вот заставить весь этот зоопарк работать из внутренних подсетей, без белого IP (есть пара филиалов, работают из подсети провайдера, белый IP им провайдер не выдает, ну никак), используя NAT-T, ну никак не получается.

Я конечно буду продолжать «копать». Как чего накопаю выложу сюда.

Источник

IPsec Configuration¶

IPsec offers numerous configuration options, affecting the performance and security of IPsec connections. Realistically, for low to moderate bandwidth usage it matters little which options are chosen here as long as DES is not used, and a strong pre-shared key is defined, unless the traffic being protected is so valuable that an adversary with many millions of dollars worth of processing power is willing to devote it to breaking the IPsec encryption. Even in that case, there is likely an easier and much cheaper way to break into the network and achieve the same end result (social engineering, for one). Performance is the most important factor for most, and in cases when that is a concern, more care is needed when crafting a configuration.

IPsec Modes¶

pfSenseВ® software supports several primary modes of IPsec operation:

This mode uses policies to match specific combinations of traffic which are grabbed by the kernel and pushed through an IPsec tunnel. It also uses special “trap” policies to detect when traffic intends to use IPsec so that it can bring the tunnel up automatically. Only traffic specifically matching phase 2 child SA entries can use IPsec, and all traffic matching those entries will be taken over by IPsec.

This mode is the most common and is supported by nearly all third party IPsec implementations.

Route-based IPsec (VTI)

Routed IPsec uses a special Virtual Tunnel Interface (VTI) for each IPsec tunnel. The VTI interface is assigned and used like other interfaces. Phase 2 entries define addresses for the tunnel interface itself, rather than policies which direct traffic to IPsec. Arbitrary traffic may cross IPsec tunnels, as traffic follows the system routing table. Static routes or dynamic routing daemons can control which traffic crosses a tunnel.

Support for routed IPsec varies by vendor.

Similar to policy-based mode, but for remote access/mobile clients.

This mode encrypts all traffic from the the external IP address on this firewall to the external IP address on the far side as defined in the Phase 1 settings. Since all traffic sent between the two nodes will be encrypted, other tunneling methods that do not employ encryption, such as a GIF or GRE tunnel, can be safely used by the firewall between the endpoints.

Interface Selection¶

In many cases, the Interface option for an IPsec tunnel will be WAN, since the tunnels are connecting to remote sites. However, there are plenty of exceptions, the most common of which are outlined in the remainder of this section.

CARP Environments¶

CARP type virtual IP addresses are also available in the Interface drop-down menu for use in High Availability environments ( High Availability ). In these environments, an appropriate CARP address must be chosen for the WAN where the IPsec tunnel will terminate. By using the CARP IP address, it ensures that the IPsec tunnel will be handled by the High Availability cluster member currently in MASTER state, so even if the primary firewall is down, the tunnel will connect to whichever cluster member has taken over the MASTER role.

IP Alias VIP¶

If multiple IP addresses are available on an interface using IP Alias type VIPs, they will also be available in this list. To use one of those IP addresses for the VPN instead, select it here.

Multi-WAN Environments¶

When using Multi-WAN ( Multiple WAN Connections ), pick the appropriate Interface choice for the WAN-type interface to which the tunnel will connect. If the connection will enter via WAN, pick WAN. If the tunnel will use a different WAN, choose whichever OPT WAN interface is needed. A static route will automatically be added to ensure that the traffic to the Remote Gateway routes through the appropriate WAN.

A gateway group may also be chosen from this list. A gateway group to be used with IPsec must only have one gateway per tier. When using a gateway group, if the first gateway goes down, the tunnel will move to the next available WAN in the group. When the first WAN comes back up, the tunnel will be rebuilt there again. If the endpoint on the far side is one that does not support multiple peer addresses, such as another firewall running pfSense software, this must be combined with a DynDNS host set using the same gateway group for failover. The DynDNS host will update the IP address as seen by the far side, so that the remote endpoint will know to accept traffic from the newly activated WAN.

Wireless Internal Protection¶

When configuring IPsec to add encryption to a wireless network, as described in Additional protection for a wireless network , choose the OPT interface which corresponds to the wireless card. When using an external wireless access point, pick the interface which is connected to the wireless access point.

Phase 1 Settings¶

The settings here control the phase 1 negotiation portion of the tunnel, as described previously.

General Information¶

Controls whether or not this tunnel (and its associated phase 2 entries) are active and used.

Key Exchange Version

This can be IKEv1, IKEv2, or Auto. The differences are discussed in IKE .

IKEv1 is more common and widely supported, but has known issues with supporting common modern issues such as dealing with NAT or mobile clients.

An updated version of the protocol which has increased capabilities and security, as well as built-in support for mobile clients and NAT.

IKEv2 is the best choice when supported by both endpoints.

This option uses IKEv2 when initiating, but will accept either IKEv2 or IKEv1 when responding.

The protocol for the outside of the tunnel. That is, the protocol that will be used between the outside peer addresses. For most, this will be IPv4 , but if both ends are capable of IPv6, that may be used instead. Whichever protocol is chosen here will be used to validate the Remote Gateway and the associated identifiers.

A tunnel using IKEv1 can only carry the same protocol traffic in Phase 2 as was used for Phase 1. For example, IPv4 peer addresses restrict Phase 2 to IPv4 networks only. A tunnel using IKEv2 can carry both IPv4 and IPv6 traffic at the same time in Phase 2 no matter which protocol was used for Phase 1.

This determines which part of the network will be the termination point (end point) for the IPsec tunnel. If the tunnel will be connecting to a remote server, then WAN is likely the desired setting. This can also be a virtual IP address. A gateway group can also be used for automatic failover. See Interface Selection earlier in this document for details on selecting the appropriate interface.

The IP Address for the peer to which the tunnel will be established. This is most likely the WAN IP address of the remote firewall.

This may be set to an IP address or a fully qualified domain name. When set to use a name, the entry is periodically resolved by DNS and updated when a change is detected.

To allow connections from any endpoint, use 0.0.0.0/0 for IPv4 or :: for IPv6. When allowing connections from any remote endpoint, the Child SA Start Action must be set to None, and the Peer Identifier cannot be set to Peer IP Address

It is a good practice to keep notes about the tunnel. Enter a few words to describe the purpose of this VPN tunnel, or about the remote end of the tunnel. This serves as a reminder for anyone managing the firewall (present or future) as to who or what will be using the tunnel.

An IPsec phase 1 can be authenticated using a pre-shared key (PSK) or certificates, the Authentication Method selector chooses which of these methods will be used for authenticating the remote peer. Fields appropriate to the chosen method will be displayed on the phase 1 configuration screen.

The peer is validated using a pre-defined string known to both endpoints. Since it is simple a string, there is a possibility that it can be guessed. For this reason a long/complex key is more secure when using PSK mode.

Select a CA and certificate used to verify the peer. During the phase 1 exchange, each peer sends its certificate to the other peer and then validates it against a CA. The CA and certificate must be created for the tunnel before attempting to setup the phase 1.

Similar to Mutual Certificate but the certificate is read from a locally attached PKCS#11 device.

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a shared (or “group”) pre-shared key.

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with certificate authentication using certificates on both the client and server.

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a certificate only on the server side. It is not quite as secure as Mutual Certificate+Xauth , but it is easier on the clients.

Used with mobile IPsec and IKEv2, EAP-TLS verifies that certificates on the client and server are from the same shared CA, similar to Mutual Certificate. The client and server certificates require special handling:

The server certificate must have the firewall hostname as it exists in DNS listed in its Common Name, and again as a Subject Alternative Name (SAN). The firewall IP address must also be listed in a SAN.

The identifier in Phase 1 must also be set to match the firewall hostname as listed in the Common Name of the certificate.

The client certificate must have the username listed as the common name and then again as a SAN.

The CA and server certificates must be generated before attempting to configure EAP-TLS. The CA and user certificate must be imported into the client.

Used with mobile IPsec and IKEv2, this selection performs CA verification along with username and password authentication via RADIUS. A RADIUS server must be selected on the Mobile Clients tab. Though user certificates are not necessary, EAP-RADIUS still requires that a CA and server certificate be present using the same attributes mentioned under EAP-TLS . The CA must be imported to the client, but no user certificate.

Used with mobile IPsec and IKEv2, EAP-MSCHAPv2 works identically to EAP-RADIUS except the usernames and passwords are defined on the Pre-Shared Key tab under VPN > IPsec with the Secret type set to EAP. It also requires a CA and server certificate with the same requirements listed previously. The CA must be imported to the client, but no user certificate.

(IKEv1 only) The type of authentication security used by this tunnel. This can be either Main or Aggressive.

Main is the most secure mode, though it also requires more packets between the peers to accomplish a successful negotiation. It is also much more strict in its validation. This mode is best for security, but not speed.

Aggressive is generally the most compatible and is the fastest mode. It is more forgiving with identifier types, and tends to be more successful when negotiating with third-party devices. It is faster because it sends all of the identifying information in a single packet, which also makes it less secure because the verification of that data is not as strict as that found in main mode.

Identifiers are used by IPsec to identify remote peers and associate specific peers with a tunnel and its related settings, such as authentication components (keys, certificates, etc).

Identifier type and value sent by this firewall to the far side. It is best left at My IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the identifier, it will work.

Identifies the remote peer on the other side of the tunnel. It is best left at Peer IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the identifier, it will work.

Identifier Types My IP Address / Peer IP address

This choice is a macro that will automatically use the IP address on the interface, or the selected VIP, as the identifier. For peers, this is the IP address from which incoming IPsec packets are received by this firewall, which should be the Remote Gateway.

The IP Address option allows a specific manual IP address to be used as the identifier. One potential use for this would be if the firewall is behind a router performing NAT. The real external IP address could be used in this field.

A Distinguished Name is another term for a fully qualified domain name (FQDN), such as host.example.com . Enter a value in that format into the box.

User Distinguished Name

A User Distinguished Name is an e-mail address, such as vpn@example.com .

ASN.1 Distinguished Name

If using Mutual Certificate authentication, this can be the subject of the certificate being used, or a similar string.

An arbitrary string to use as the identifier.

A hostname to resolve and use as the identifier. This is mostly useful if the firewall is behind NAT and has no direct knowledge of its external IP address aside from a dynamic DNS hostname. This is only available for My identifier, not the Peer identifier.

In cases when the remote identifier is unknown or cannot be matched, the Peer Identifier may be set to Any. This is more common on certain types of mobile configurations, but it is a much less secure choice than matching the identifier properly.

(Mutual PSK authentication only) This key must be exactly the same on both VPN peers. It is case sensitive. Think of this like a “password” for the tunnel. Since this only gets entered once on each side and there is no need to remember it, the best practice is to make this as long and complex as possible.

Click Generate new Pre-Shared Key to populate the field with a random long string suitable for use as a Pre-Shared Key.

This Pre-Shared Key must be as random as possible to protect the contents of the tunnel.

(Mutual Certificate authentication only) Defines the certificate which identifies this firewall. The CA which signed this certificate must be copied to the peer. If one is not shown, create or import it under System > Cert Manager on the Certificates tab.

Peer Certificate Authority

(Mutual Certificate authentication only) Defines the CA which has signed the certificate sent by the peer. This is used to validate the peer certificate. If it does not show in the list, import it under System > Cert Manager on the Certificate Authorities tab.

Phase 1 Encryption algorithms¶

There are many options for encryption algorithms on both phase 1 and phase 2.

Encryption choices depend on the device to which the tunnel will connect and the hardware. Generally speaking, AES-GCM is the most desirable cipher. When connecting to third party devices, AES with a 128-bit key length is a common choice on endpoints which lack support for AES-GCM.

Multiple combinations of these options can be defined using the Add Algorithm button to add another line. The order of the entries is the order of preference, so configure the strongest settings first.

If both sides support AES-GCM, use AES128-GCM with a 128 bit Key Length. This will combine strong encryption and hashing together and can be accelerated by AES-NI. Failing that, use AES With a Key Length of 128. If the peer does not support any of these, use the strongest available option supported by the peer.

Hash algorithms are used with IPsec to verify the authenticity of packet data and as a Pseudo-Random Function (PRF). These hash algorithms may also be referred to with HMAC (Hash Message Authentication Code) in the name in some contexts, but that usage varies depending on the hardware or software in use.

When using AES-GCM, this is used solely as a PRF because AES-GCM already performs hashing internally. The best choice for use with AES-GCM is AES-XCBC. If a different type of Encryption Algorithm is in use, then use SHA256 if possible. If the peer does not support any of these, use the strongest available option supported by the peer.

Specifically set a manual PRF different than the one the IPsec daemon would choose automatically based on the Hash Algorithm. This control is hidden by the GUI unless PRF Selection is enabled in the Advanced Options section at the bottom of the page.

The best practice is to use DH Group 14 (2048 bit) or higher if both sides support it. Avoid using groups 1, 2, 22, 23, and 24 as they do not provide sufficient security. As with the other options, if the suggested value is not supported by the peer, use the strongest available option.

Expiration and Replacement¶

The total lifetime for Phase 1 defines how often the connection will be rekeyed or reauthenticated by the IPsec daemon, in seconds.

Take care when crafting these values. Incorrect or sub-optimal values can lead to problems such as tunnels failing to renegotiate in a timely manner or multiple duplicate security associations.

The specific values for these fields depend on the IKE mode and which mechanisms are supported by both endpoints, but in most cases setting the Life Time value will allow the firewall to choose the best option.

The hard IKE SA life time, in seconds, after which the IKE SA will be expired. This value must be larger than Rekey Time and Reauth Time and cannot be set to the same value.

28800 total seconds is a good balance of frequent rekeying without being too aggressive.

Set one endpoint to this recommended value, but use a higher Life Time on the other endpoint by at least 10% (e.g. 31680 ) to help avoid overlap.

If left empty, the value defaults to 110% of Rekey Time or Reauth Time, whichever is higher.

Time, in seconds, before the IPsec daemon attempts attempts to establish a new set of keys for the IKE SA. Only supported by IKEv2, and is the best choice for use with IKEv2.

Rekey works without interruption and allows both endpoints to seamlessly change to new keys on the fly. This is optimal, but implementation quality varies by vendor.

Leave blank to automatically calculate the value based on 90% of Life Time, or enter a value of 0 to disable rekeying.

Normally both sides will rekey as needed, but if the tunnel often fails when a rekey event occurs, try disabling this feature on one side.

Some clients, especially Windows clients behind NAT, misbehave when they receive a rekey request. In those cases it is safer to allow the client to initiate the rekey by disabling the option on the server.

Time, in seconds, before an IKE SA is torn down and recreated from scratch by the IPsec daemon, including authentication. Supported by IKEv1 and IKEv2, but should be avoided with IKEv2 where possible.

This process can be disruptive to traffic flow unless all peers support IKEv2 make-before-break ( Advanced IPsec Settings ) and overlapping IKE SA entries.

Leave blank to automatically calculate the value based on 90% of Life Time, or enter a value of 0 to disable reauthentication.

Introduces randomness into the rekey or reauthentication process to avoid both endpoints attempting to renegotiate simultaneously.

A random value up to this amount will be subtracted from Rekey Time or Reauth Time for each scheduled renegotiation to reduce the chance of collisions.

If left empty, the value defaults to 10% of Life Time. Enter 0 to disable randomness.

Disabling Rand Time increases the likelihood of simultaneous renegotiation, which can lead to duplicate security associations.

Advanced Options¶

This option forces specific behavior performed by the IPsec daemon loading a phase 2 configuration (“Child SA”) during service startup. This happens at boot and when the service is restarted for any reason.

Automatically chooses behavior based on other settings.

None (Responder Only)

When set, then IPsec daemon will not attempt to initiate the tunnel. The tunnel will only be established by an initiation attempt from the far side. Also, if DPD detects that the tunnel has failed, the tunnel will be left down rather than restarted, leaving it up to the far side to reconnect.

This is the default behavior for mobile IPsec and tunnels with unknown remote endpoints.

Initiate at Start

(VTI or Tunnel Mode) When set, the firewall will attempt to establish the IPsec tunnel immediately when the IPsec daemon starts.

This is the default behavior for VTI mode.

Initiate on Demand

(Tunnel mode only) When set, traffic which matches the networks in phase 2 definitions for this tunnel (“interesting traffic”) will trigger initiation of the tunnel.

This is the default behavior of Tunnel Mode.

Finding “interesting” traffic relies on trap policies to function, and trap policies are not compatible with VTI mode.

Controls how the IPsec daemon behaves when a child SA (P2) is unexpectedly closed by the peer.

Retains the default behavior based on other settings for the tunnel.

Close connection and clear SA

Removes the child SA and does not attempt to establish a new SA. This is the desired behavior when acting in a Responder Only or mobile IPsec role.

Immediately attempts to reconnect the child SA. This ensures that the tunnel reestablishes properly in cases that do not support trap policies, such as routed IPsec (VTI). Set this on one side only if the tunnel does not reconnect after it disconnects, rekeys, or reauthenticates.

This option must not be set on both peers! Otherwise both peers will attempt to initiate and hold open multiple copies of each child SA.

Clears the child SA and reinstalls trap policies to watch for interesting traffic. Will reestablish the tunnel on demand when traffic attempts to cross the tunnel.

This option is not compatible with modes which do not support trap policies, such as routed IPsec (VTI).

(IKEv1 Only) Also known as NAT-T. NAT Traversal encapsulates ESP traffic for IPsec inside of UDP packets, to more easily function in the presence of NAT. If this firewall or the firewall on the other end of the tunnel is behind a NAT device, then NAT Traversal will likely be necessary for the tunnel to function properly.

(Default) Allows the IPsec daemon to detect and use NAT Traversal automatically when it determines one or both peers is behind NAT.

Instructs the IPsec daemon to always use NAT Traversal for the tunnel. This can help if there is a known issue detecting NAT, or with issues carrying ESP traffic between the two endpoints even when neither side is behind NAT.

IKEv2 integrates NAT Traversal natively so the option is unnecessary in that case.

An extension to IKEv2 which handles multi-homed clients and clients which roam between different IP addresses. This is primarily used with mobile clients to allow them to switch remote addresses while keeping the connection active. Leave disabled unless the remote peer must change addresses dynamically.

When set, the GUI validation allows multiple Phase 1 configurations to the same remote endpoint.

This option also disables automatic static routes to the peer via specific WAN gateways. Traffic will follow the default route, not the tunnel interface, unless manual static routes redirect the traffic.

(IKEv2 Only) When an IKEv2 tunnel has multiple Phase 2 definitions, by default the settings are collapsed in the IPsec configuration such that all P2 combinations are held in a single child SA.

Split Connections changes this behavior to be more like IKEv1 where each P2 is its configured by the daemon as own separate child SA.

Certain scenarios require this behavior, such as:

The remote peer does not properly handle multiple addresses in single traffic selectors. This is especially common in Cisco, Checkpoint, Fortinet, and Juniper equipment.

Each child SA must have unique traffic selector or proposal settings. This could be due to the peer only allowing specific combinations of local/remote subnet pairs or different encryption options for each child SA.

When set, the GUI enables a control to specifically set a Pseudo-Random Function (PRF) rather than allow the IPsec daemon to choose one automatically based on the selected Hash Algorithm. Can be useful in combination with AEAD encryption algorithms such as AES-GCM.

Custom IKE/NAT-T Ports

In rare situations the remote endpoint may be running IPsec on alternate port numbers for IKE and NAT-T. These settings can accommodate such endpoints.

Remote IKE Port

The UDP port for IKE on the remote gateway. Leave empty for the default automatic behavior (Port 500 for IKE and 4500 for NAT-T)

Remote NAT-T Port

The UDP port for NAT-T on the remote gateway.

If Remote IKE Port is empty and NAT-T contains a value, the tunnel will use only NAT-T.

Dead Peer Detection (DPD) is a periodic check that the host on the other end of the IPsec tunnel is still alive. This detects when an IPsec peer has lost connectivity or otherwise is unreachable. If a DPD check fails, the tunnel is torn down by removing its associated SAD entries and a fresh negotiation is attempted.

The default settings are sufficient for most connections. Increase the values for bad quality links to avoid tearing down a usable, but lossy, tunnel.

Time between DPD probe attempts. The default of 10 is best.

Number of failures before the peer is considered down. The default of 5 is best.

The default values of 10 seconds and 5 failures will result in the tunnel being considered down after approximately one minute.

Phase 2 Settings¶

The phase 2 settings for an IPsec tunnel govern how the tunnel handles traffic (e.g. policy-based or route-based, see IPsec Modes ) as well as the encryption of that traffic.

Phase 2 entries are used in a few different ways, depending on the IPsec configurations:

For policy-based IPsec tunnels, this controls which subnets will enter IPsec. Multiple phase 2 definitions can be added for each phase 1 to allow using multiple subnets inside of a single tunnel.

For route-based IPsec, this controls the VTI interface addresses.

For mobile IPsec this primarily controls the encryption for phase 2, but can also optionally be used by the IPsec daemon or export utilities to generate a list of networks to the clients for use in split tunneling.

Each Phase 2 entry has the following options:

An on/off switch for this Phase 2 entry only.

The IPsec Mode for this Phase 2 entry, which controls how the tunnel handles traffic. See IPsec Modes for more detailed explanations of each type of mode.

With policy-based IKEv1 tunnels, this must match the outer protocol of the tunnel, for example an IPv4 peer would be Tunnel IPv4. Policy-based IKEv2 tunnels can have either/or (or both).

A policy-based tunnel that will carry traffic between IPv4 networks matching the specified Local Network and Remote Network.

A policy-based tunnel that will carry traffic between IPv6 networks matching the specified Local Network and Remote Network.

Encrypts all traffic between the endpoints. The Local Network and Remote Network are not set for transport mode, it assumes the addresses based on the phase 1 settings.

Routed IPsec using Virtual Tunnel Interfaces. The Local Network and Remote Network define the addresses used by the firewall for the VTI interface. Typically only one Phase 2 entry is present for each address family (e.g. one for IPv4, one for IPv6)

See Routed IPsec (VTI) for more information.

Local Network Tunnel Mode

Defines which subnet or host can be accessed from the other side of the VPN tunnel. This is typically the LAN or other internal subnet for the VPN, but can also be a single IP address if only one client needs to use the tunnel. The Type selector is pre-loaded with choices for each interface (e.g. LAN subnet ), as well as Address and Network choices that allow entering an IP address or subnet manually.

Most often this is set to LAN subnet, meaning the entire LAN will be accessible from the remote network.

Sets a different subnet or address which is used by IPsec to perform NAT on the local network addresses to make them appear to the remote peer as a different subnet.

Set to None to disable NAT for the tunnel.

Routed (VTI) Mode

Sets the local IP address and subnet mask of the ipsecX interface.

Remote Network Tunnel Mode

(Non-mobile only) Specifies the IP Address or Network which exists on the other (remote) side of the VPN. This field operates similarly to the Local Network option.

Routed (VTI) Mode

Sets the remote IP address for the ipsecX interface tunnel network (the remote address of the VTI).

A description for this Phase 2 entry. Shows up in the IPsec status for reference.

Phase 2 Proposal (Child SA)В¶

Controls how IPsec protects its traffic.

ESP (Encapsulating Security Payload)

Encrypts traffic before sending it to the peer.

In nearly all circumstances, ESP is the correct choice.

AH (Authenticated Header)

Provides assurance the traffic came from a trusted source but does not provide encryption. Rarely used in practice.

With automatic VPN rules ( Disable Auto-added VPN rules ), the firewall automatically passes the appropriate ESP or AH protocol traffic from the remote endpoint. If automatic VPN rules are disabled, add manual rules to pass the traffic instead.

Sets the encryption algorithms used when negotiating Phase 2 child SA entries with peers. Must match values available to and configured on the peer.

In systems with AES-NI, the fastest and most secure choice is AES-GCM if it is supported by the peer. When using AES-CGM do not select any options for Hash Algorithms in Phase 2.

If AES-NI cannot be used both both peers, use AES with a 128-bit or higher key length.

This set of controls allows for multiple selections so that multiple choices will be accepted when acting as a responder, or proposed when working as an initiator. The best practice is to only select a single desired cipher on both peers, but in some cases, such as mobile clients, selecting multiple will allow a tunnel to work better in both a responder and initiator role.

Controls which hash algorithms are used when negotiating phase 2 child SA entries with peers. Must match values available to and configured on the peer.

As with the Encryption Algorithms, multiple hashes may be selected. The best practice is to select a single desired choice if possible. For more discussions on the quality of the various hash types, see Phase 1 Settings .

The optimal choice for speed and security is SHA256, unless using AES-GCM for the Encryption Algorithm. With AES-GCM, no Hash Algorithm should be selected as AES-GCM performs hashing on its own.

Perfect Forward Secrecy (PFS) provides keying material with greater entropy, hence improving the cryptographic security of the connection, at the cost of higher CPU usage during rekeying.

The options have the same properties as the DH key group option in phase 1 (See DH key group ), and some products also refer to them as “DH” values even in Phase 2.

The optimal choice for speed and security is 14 (2048 bit). The default is off.

The hard child SA life time, in seconds, after which the child SA will be expired. This value must be larger than Rekey Time and cannot be set to the same value.

3600 total seconds is a good balance of frequent rekeying without being too aggressive.

Set one endpoint to this recommended value, but use a higher Life Time on the other endpoint by at least 10% (e.g. 5400 ) to help avoid overlap.

If left empty, the value defaults to 110% of Rekey Time. If both Life Time and Rekey Time are empty, defaults to 3960 .

Time, in seconds, before the child SA establishes a new set of keys. This works without interruption and allows both endpoints to seamlessly change to new keys on the fly.

Leave blank to automatically calculate the value based on 90% of Life Time. If both Life Time and Rekey Time are empty, defaults to 3600 . Enter a value of 0 to disable rekeying.

If rekeying is disabled, connections can be interrupted while a new child SA is negotiated after an old entry expires.

Introduces randomness into the rekey process to avoid both endpoints attempting to renegotiate simultaneously.

A random value up to this amount will be subtracted from Rekey Time for each scheduled renegotiation to reduce the chance of collisions.

If left empty, the value defaults to 10% of Life Time. Enter 0 to disable randomness.

Disabling Rand Time increases the likelihood of simultaneous renegotiation, which can lead to duplicate security associations.

For use on non-mobile tunnels, this option tells the firewall to initiate a ping periodically to the specified IP address. This option only works if the firewall has an IP address inside of the Local Network for this Phase 2 entry and the value of the ping host here must be inside of the Remote Network.

See Configuring IPsec Keep Alive for additional information.

Источник