IPsec Configuration

Windows Filtering Platform (WFP) is the underlying platform for Windows Firewall with Advanced Security. WFP is used to configure network filtering rules, which include rules that govern securing network traffic with IPsec. Application developers may configure IPsec directly using the WFP API, in order to take advantage of a more granular network traffic filtering model than the model exposed through the Microsoft Management Console (MMC) snap-in for Windows Firewall with Advanced Security.

What is IPsec

Internet Protocol Security (IPsec) is a set of security protocols used to transfer IP packets confidentially across the Internet. IPsec is mandatory for all IPv6 implementations and optional for IPv4.

Secured IP traffic has two optional IPsec headers, which identify the types of cryptographic protection applied to the IP packet and include information for decoding the protected packet.

The Encapsulating Security Payload (ESP) header is used for privacy and protection against malicious modification by performing authentication and optional encryption. It can be used for traffic that traverses Network Address Translation (NAT) routers.

The Authentication Header (AH) is used only for protection against malicious modification by performing authentication. It cannot be used for traffic that traverses NAT routers.

For more information on IPsec, see also:

What is IKE

Internet Key Exchange (IKE) is a key exchange protocol that is part of the IPsec protocol set. IKE is used while setting up a secure connection and accomplishes the safe exchange of secret keys and other protection-related parameters without the intervention of the user.

For more information on IKE, see also:

What is AuthIP

Authenticated Internet Protocol (AuthIP) is a new key exchange protocol that expands IKE as follows.

While IKE only supports computer authentication credentials, AuthIP also supports:

• User credentials: NTLM, Kerberos, certificates.
• Network Access Protection (NAP) health certificates.
• Anonymous credential, used for optional authentication.
• Combination of credentials; for example, a combination of machine and user Kerberos credentials.

AuthIP has an authentication-retry mechanism that verifies all configured authentication methods before failing the connection.
AuthIP can be used with secure sockets to implement application-based IPsec secured traffic. It provides:

• Per-socket authentication and encryption. See WSASetSocketSecurity for more information.
• Client impersonation. (IPsec impersonates the security context under which the socket is created.)
• Inbound and outbound peer name validation. See WSASetSocketPeerTargetName for more information.

For more information on AuthIP, see also:

What is an IPsec Policy

An IPsec policy is a set of rules that determine which type of IP traffic needs to be secured using IPsec and how to secure that traffic. Only one IPsec policy is active on a computer at one time.

To learn more about implementing IPsec policies, open the Local Security Policy MMC snap-in (secpol.msc), press F1 to display the Help, and then select Creating and Using IPsec Policies from the table of contents.

For more information on IPsec policies, see also:

How to Use WFP to Configure IPsec Policies

The Microsoft implementation of IPsec uses Windows Filtering Platform to setup IPsec policies. IPsec policies are implemented by adding filters at various WFP layers as follows.

At the FWPM_LAYER_IKEEXT_V <4|6>layers add filters that specify the negotiation policies used by the keying modules (IKE/AuthIP) during Main Mode (MM) exchanges. Authentication methods and cryptographic algorithms are specified at these layers.

At the FWPM_LAYER_IPSEC_V <4|6>layers add filters that specify the negotiation policies used by the keying modules during Quick Mode (QM) and Extended Mode (EM) exchanges. IPsec headers (AH/ESP) and cryptographic algorithms are specified at these layers.

A negotiation policy is specified as a policy provider context associated with the filter. The keying module enumerates the policy provider contexts based on the traffic characteristics and obtains the policy to use for the security negotiation.

The WFP API can be used to specify the Security Associations (SAs) directly and therefore to ignore the keying module negotiation policy.

At the FWPM_LAYER_INBOUND_TRANSPORT_V <4|6>and FWPM_LAYER_OUTBOUND_TRANSPORT_V <4|6>layers add filters that invoke callouts and determine which traffic flow should be secured.

At the FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V <4|6>layers add filters that implement identity filtering and per-application policy.

The following diagram illustrates the interaction of the various WFP components, with respect to IPsec operation.

Once IPsec is configured, it integrates with WFP and extends the WFP filtering capabilities by providing information to be used as filtering conditions at the Application Layer Enforcement (ALE) authorization layers. For example, IPsec provides the remote user and remote machine identity, which WFP exposes at the ALE connect and accept authorization layers. This information can be used for fine-grained remote identity authorization by a WFP-based firewall implementation.

Below is a sample isolation policy that may be implemented using IPsec:

• FWPM_LAYER_IKEEXT_V <4|6>layers – Kerberos authentication.
• FWPM_LAYER_IPSEC_V <4|6>layers – AH/SHA-1.
• FWPM_LAYER_INBOUND_TRANSPORT_V <4|6>and FWPM_LAYER_OUTBOUND_TRANSPORT_V <4|6>layers — negotiation discovery for all network traffic.
• FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V <4|6>layers — IPsec required for all network traffic.

Related topics

WFP Layers

IPsec Policy Scenarios Implemented using WFP API:

Windows firewall and ipsec

Вопрос

В Windows 7 и Windows 10 есть возможность подключения по IPSec через дополнительные параметры брандмауэра Windows.

В моем случае есть 2 сети:

1. Сервер с внешним IP, за сервером локальная сеть

2. Клиент, за NAT

Произвожу следующие настройки:

Брандмауэр Windows в режиме повышенной безопасности > Правила безопасности подключения > Создать правило > Туннельный > От шлюза к клиенту > Требовать. > Локальная конечная точка туннеля: Внешний IP Сервера; Укажите локальные конечные точки: Локальная сеть сервера > Проверка подлинности: настраиваю предварительный ключ > Имя > Готово

Брандмауэр Windows в режите повышенной безопасности > Правила безопасности подключения > Создать правило > Туннельный > От клиента к шлюзу > Требовать. > Удаленная конечная точка туннеля: Внешний IP Сервера; Укажите удаленные конечные точки: Локальная сеть сервера > Проверка подлинности: настраиваю предварительный ключ > Имя > Готово

В результате, если с клиента делать Ping в локальную сеть сервера, соединение устанавливается (видно в Брандмауэр Windows в режиме повышенной безопасности > Наблюдение > Сопоставления безопасности > Основной и Быстрый режимы появляются записи подключения), но при этом Ping не проходит, и вообще не проходит любой другой трафик, например ftp, шара и т.д.

Подскажите, что я делаю неправильно. Задача стоит в объединении сетей посредствам IPSec

Windows firewall and ipsec

Вопрос

I can’t understand the following: theoretically, for a packet to pass into a host the corresponding inbound allow rule must exist in Windows Firewall (conversely, for a packet to leave a host an outbound allow rule must exist). Nevertheless, I can’t seem to find an inbound rule(s) that would allow IPSec packets (auth and/or esp) to get into a host.

For example, if I use the default block all action for the inbound connections and create a single inbound rule for icmp (local rules do not apply) — that will be enough for a client to establish an encrypted ipsec connection and ping the server (the connection security rules are also applied to the server and the client):

Some articles in the Internet explicitly state that «Inbound and Outbound firewall rules must still be configured in order to use IPSec» — in my tests there are no inbound ipsec rules but it doesn’t prevent computers from establishing secure communications.

Q: By what means ipsec packets are allowed to get into the server when no inbound rules exist for ipsec (udp 500. ) ?

Ответы

My remark regarding the warning text was meant to indicate that there is a more complex model underlying the simple model presented by the MMC snap-in and that this mapping between models sometimes makes itself visible.

You could try the following: interpret «outbound IPsec network traffic» as the IPsec protected traffic (i.e. the data carried by IPsec (AH/ESP), such as ICMP packets, TCP/IP packets, etc.) rather than the protocols that implement IPsec/IKE. Perhaps a reading your sources of information will make more sense under this interpretation.

Все ответы

When looking at rules with the «Windows Defender Firewall with Advanced Security» MMC snap-in, you probably occasionally see warnings like this:

This is a hint that the underlying mechanism is more complex than can be viewed and managed with this tool. To see the complete set of «rules» that are applied, use the command «netsh WFP show state file=rules.xml».

Some of the key «rules» for the processing of IPsec will have as their action «callout» (rather than block/permit), which allows kernel-mode code to process the packet.

UDP port 500 is just used for key exchange (IKE/IKEv2/AuthIP), the IPsec protected traffic is either carried directly over IP protocols AH/ESP or potentially encapsulated in UDP to port 4500 (if NATT is needed).

In rules.xml, you should be able to find the «rules» (filters/actions) that allow the IKE/IKEv2/AuthIP daemon to receive packets from UDP port 500 and the rules for handling of ESP traffic.

• Предложено в качестве ответа cynthfan Microsoft contingent staff 21 ноября 2019 г. 9:30

Netsh wsp context just allows you either to diagnose problem with WF/ipsec (using the capture option) or see the internal FW state (using the state option). Yes, the netsh WFP show state file=rules.xml does return lots of internal information on FW including IPSec but these are NOT the firewall rules and I should not take them into consideration when designing the firewall rules — UNLESS the developer’s documentation claims the opposite.

In any case what’s the purpose of the firewall which actions depends not only on the rules created by administrators but on the lots of internal action/filters as well? How can an administrator be sure that any other traffic (for which no rules have been created) would not be allowed by the internal filters?

Regarding the documentation: the most complete guide on Windows Firewall I’ve read so far is this: «Step-by-Step Guide: Deploying Windows Firewall and IPsec Policies» — it says nothing about the internal «rules» but cleary states this:

The most weird thing here is that this guide does NOT have the same statement regarding the INBOUND traffic! And this is true: the guide’s examples show that we can have the INBOUND ipsec connections WITHOUT any firewall rules (with the default inbound action set to Block) but we MUST HAVE the explicit allow OUTBOUND rule(s) to let the ipsec traffic leave the network interface — doesn’t it look strange?

Other articles (as the one in my initial post) say the rules must be created for both inbound and outbound traffic -either way the MS documentation seems to be incomplete.

What Are Windows Firewall and IPsec?

One key component in securing your IT infrastructure is protecting against network-related security threats. Windows Server offers several network security features to help:

• Windows Firewall with Advanced Security
• IPsec
• Message Analyzer Free Tool

Windows Firewall with Advanced Security

Windows Firewall with Advanced Security blocks unauthorized network traffic flowing into or out of a local device by providing host-based, two-way network traffic filtering. You can either manually configure Windows Firewall with Advanced Security on each server or use Group Policy to centrally configure the firewall rules.

While the old Windows Firewall allowed you to configure only a single set of inbound and outbound rules (a profile), Windows Firewall with Advanced Security includes three profiles (Domain, Private and Public), so you can apply the appropriate rules to each server based on its connection to the network. These profiles are tightly connected to three network profiles in the Network and Sharing Center:

• Domain networks. Networks at a workplace that are attached to a domain.
• Private networks. Networks at home or at work where you trust the people and devices on the network. When private networks are selected, network discovery is turned on but file and printer sharing is turned off.
• Guest or public networks. Networks in public places. This location keeps the computer from being visible to other computers. When a public network is the selected network location, network discovery and file and printer sharing are turned off.

You can also configure the following options for each of the three network profiles:

• Firewall State. You can turn the firewall on or off independently for each profile.
• Inbound Connections. You can block connections that do not match any active firewall rules (this is the default), block all connections regardless of inbound rule specifications, or allow inbound connections that do not match an active firewall rule.
• Outbound Connections. You can allow connections that do not match any active firewall rules (this is the default) or block outbound connections that do not match an active firewall rule.
• Protected Network Connections. You can select the connections — for example, the Local Area Connection — that you want Windows Firewall to help protect.
• You can configure display notifications and unicast responses, and merge rules that are distributed through Group Policy.
• You can configure and enable logging.
• IPsec Settings. You can configure the default values for IPsec configuration.

IPsec

Connecting to the internet exposes a company to many types of security threats, from malware to drive-by downloads to social engineering attacks. IPsec is a set of industry-standard, cryptography-based protection services and protocols that can help to protect data in transit through a network by providing authentication, integrity checking and encryption. IPsec protects all protocols in the TCP/IP protocol suite except Address Resolution Protocol (ARP).

The design of IPsec helps it provide much better security than protection methods such as Transport Layer Security (TLS) and Secure Shell (SSH), which provide only partial protection. Network administrators who use IPsec do not have to configure security for individual programs because all network traffic between the specified hosts is protected when they use IPsec.

• Offers mutual authentication before and during communications.
• Forces both parties to identify themselves during the communication process.
• Enables confidentiality through IP traffic encryption and digital packet authentication.

Message Analyzer

You can use Message Analyzer to capture, display and analyze protocol messaging traffic, events and other system or application messages in network troubleshooting and other diagnostic scenarios. Message Analyzer enables you to save and reload captures, aggregate saved captures, and analyze data from current and saved trace files. When Message Analyzer performs network captures, it limits irrelevant data, and exposes issues and hidden information that is critical for quick analysis. It accomplishes this by enabling you to remove lower-level details so you can perform analysis on higher-layer data of interest.

You can use Message Analyzer in a variety of scenarios:

• Capturing network traffic for security review
• Troubleshooting application issues
• Troubleshooting network and firewall configuration issues

Using these Windows Server features can greatly enhance your security during network communications, and help you block man-in-the-middle (MITM), replay, hijacking, distributed denial-of-service (DDoS) and other attacks.