Shulou(Shulou.com)06/02 Report--

The server configuration of the mobile client has several components:

Create a certificate structure for × ×

Configure IPsec Mobile client Settings

Create phases 1 and 2 for client connections

Add IPsec Firewall Rule

Create × × × user credentials

Ipsec connection testing

Troubleshooting ipsec

Ipsec log description

Create an IKEv2 certificate structure for × ×

Create a certification authority

If there is no appropriate certificate authority (CA) in the certificate manager, let's first create one:

Navigate to system > Certificate Management, CAS tab

Click to add a certification authority

Certificate source selected to create an internal certification authority

Fill in the remaining fields according to the company or specific location information

Click Save

Create a server certificate

Be careful

Follow the steps strictly, and if any part is incorrect, some or all clients may not be able to connect.

Navigate to system > Certificate Management, Certificate tab

Click

Add a new certificate

Select certificate source to create internal certificate

Enter a description name such as: IKEv2 Server

Select the certificate authority created in the previous step

Enter key length, digest algorithm and validity period

Select the certificate type as the server certificate

Fill in the region and company data in the private name field as needed, copy it from CA and leave it as is

Enter the common name as the host name of the firewall that exists in the DNS. If the client will connect through an IP address, please fill in the IP address here

Click

Add a new alternate name

Select FQDN or hostname in the type field

Enter the hostname of the firewall again in the value field

Click

Add another alternate name

Select the IP address in the type field

Enter the WAN IP address of the firewall in the value field

Add more alternate names as needed for other hostnames or IP addresses on the firewall that the client may use to connect

Click Save

Configure IPsec Mobile client Settings

Before configuring the mobile IPsec instance, first select a range of IP addresses for the mobile client. Ensure that the IP address does not overlap with any existing network; the IP address must be different from the site hosting the mobile tunnel and the LAN to which the client connects. In this example, 10.3.200.0Compact 24 will be used, but it can be any unused subnet.

First, enable IPsec on the firewall:

Navigate to * × × > IPsec

Check to enable IPsec

Click Save

Mobile client support must also be enabled:

Navigate to * × × > IPsec

Click the Mobile client tab

Check to enable IPsec mobile client support

Enable IPsec mobile client support

Set user authentication to Local Database, as shown in the following figure. The RADIUS server defined in user management (user management and authentication) can be selected here to authenticate users when using EAP-RADIUS.

Mobile client authentication

Some settings may be pushed to the client, such as the client IP address and the DNS server. These options are displayed in the Settings for Mobile client push. Support for these options varies from client to client, but is well supported in most current operating systems

Virtual address Pool:

Define the IP address pool that will be assigned to the client. This example uses 10.3.200.0swap 24.

Virtual IPv6 address Pool:

It's the same as above, but it's the IPv6 address.

Network list:

Controls whether the client attempts to send all traffic through the tunnel, or only for a specific network. If this option is selected, the network defined in the local network option defined in Mobility Phase 2 will be sent to the client. If this option is not selected, the client will attempt to send all its traffic, including Internet traffic, through the tunnel. Not all customers respect this choice. For this example, the client can only reach the network at stage 2, so select this option.

Save the Xauth password:

When selected, clients that support this control will allow users to save their credentials when using Xauth. This is primarily promoted by Cisco-based clients, such as those on iOS and Mac OS X. Because IKEv2 is used in this example, it is not important.

DNS default domain: when selected, the value entered into the box is pushed to the client as the default domain suffix for the DNS request. For example, if this is set to example.com and the client requests the host, an attempt is made to execute the DNS request for host.example.com.

Split DNS:

Controls how the client sends DNS requests to the provided DNS server, if any. If this option is not selected, the client sends all DNS requests to the provided DNS server. If this option is selected, but left blank, and the DNS default domain is set, only requests for that domain name will go to the provided DNS server. If you select and enter a value, only the domain name request in the input box will be forwarded to the provided DNS server. In this example, both example.com and example.org are used, and DNS requests for both domains will reach the server, so enter these values here and separate them with spaces.

DNS server:

When selected to provide the client with a list of DNS servers, enter the IP address for the local DNS server (such as 10.3.0.1), and these values will be sent to the client for use when connecting.

Be careful

If the mobile client will route to the Internet via × × ×, make sure that the client uses this option to obtain the DNS server from the firewall and that split DNS is not enabled. If not, the client will try to get the DNS from any server assigned by ISP, but routing the request through the tunnel will most likely fail.

WINS server:

Similar to the DNS server, but for WINS. It is rarely used now, and it is best to disable it.

Phase 2 PFS group:

Overrides the PFS settings for all mobile Phase 2 entries. It is usually best to set this value separately on P2 entries, so please do not select it.

Landing banner:

Optional, available only for Xauth clients. Keep unchecked and blank

After the setup is completed, it is as follows:

Mobile client push Settings

Create Phase 1 and Phase 2

Click Save, and pfSense displays a warning indicating that the mobile client does not have Phase 1 defined.

Click create Phase1 to create a new Phase1 entry for the mobile client.

Click the tunnels tab.

The configuration options are as follows:

Key exchange version: IKEv2

Internet protocol: IPv4

API: WAN

Description: Mobile IPsec

Authentication method: EAP-MSCHAPv2

My identifier: select Distinguished name from the drop-down list and enter the hostname of the firewall, which is the same as the hostname of the server certificate, * * .example.com

Peer identifier: Any

My certificate: select the IPsec server certificate you created earlier

Encryption algorithm: set to 3DES (AES 256 if there is no iOS / OS X device)

Hash algorithm: must be set to SHA1 (SHA256 if there is no iOS / OS X device)

DH group: must be set to 2 (1024 bit)

Validity period: must be 28800

Disable pre-grant password: unchecked

Disable recertification: unchecked

Response only: unchecked

MOBIKE: set to enable to allow clients to roam between IP addresses, otherwise set to disable.

Mobile client Phase 1

Click Save

Click to display the Phase 2 entry and expand the Phase 2 list

Click

Add a new phase 2 entry

The top of the configuration is as follows:

Mode: select IPv4 tunnel

Local network: set to LAN subnet or other local network. To transport all traffic through a × × tunnel, select the network and enter 0.0.0.0 with a mask of 0

NAT/BINAT: set to None

Protocol: set to ESP, which encrypts tunnel traffic

Encryption algorithm: must be set to AES, automatically select the key length. 3DES is also selected if there is an iOS or OS X client connection.

Hash algorithm: choose SHA1 and SHA256

PFS key group: set to off

Validity period: 3600

Mobile client Phase 2

Click Save

Click to apply changes

After the configuration is completed, it is shown below:

Create an IPsec mobile user

The next step is to add users for use by EAP-MSCHAPv2.

Navigate to * × × > IPsec, pre-shared key tab

Click

Add a new key

The configuration options are as follows:

Identifier: the user name of the client can be expressed in a variety of ways, such as the email address jimp@example.com

Encryption type: set to EAP

Pre-shared key: the client's password, such as abc123

Click Save

Repeat the above operation for other × × users.

Mobile IPsec users

Add IPsec Firewall Rule

Like static site-to-site tunnels, mobile tunnels also need to add firewall rules to the IPsec tab under Firewall > Rule policy. In this case, the source of the traffic will be the subnet selected for the mobile client, the destination is the LAN network, or any.

Create × × × user credential Windows IKEv2 client configuration

Versions of Windows 8 and above can easily support IKEv2 × ×, while Windows 7 can also, although the process is slightly different. This example procedure is performed on Windows 10 and is almost identical to Windows 8.

Import the CA certificate to the client PC

Export the CA certificate from pfSense and download or copy it to the client PC:

Navigate to system > Certificate Management, CAS tab

Click Export CA Certificate on the right side of the certificate list

Find the downloaded file on the client computer (for example, × × CA.crt)

Double-click the CA file

Click to install the certificate

Certificate Properties

Select the local computer

Certificate Import Wizard-Storage location

Click next

If the UAC prompt appears, click Yes

Choose to put all certificates in the following storage, as shown in the following figure

Certificate Import Wizard-Browse Storage

Click to browse

Click trusted Root Certificate Authority

Select Certificate Store

Click OK

Click finish.

Complete the Certificate Import Wizard

Set up × × connection

Once the certificate is imported correctly, you can create a client × × connection. The exact steps will depend on the version of Windows used by the client. The following is the setting method in Win10.

Open the Network and sharing Center on the client PC

Click to set up a new connection or network

Choose to connect to the workspace

Click next

Select No to create a new connection

Click next

Click to use my Internet connection (* *)

Enter the IP address or hostname of the server in the Internet address

Be careful

This must match the common name of the server certificate or the configured alternate name!

Windows IKEv2 × × connection settings

Enter the target name

Click to create

Connections have been added, but there are several default values that need to be changed. Please refer to the following figure to set up:

In the Network connection / Adapter Settings of Windows, find the connection created above

Right-click the connection

Click Properties

Click the Security tab

Set the type of * * to: KEv2

Set the data encryption option to: encryption is required (disconnect if the server refuses)

Set authentication to use Extensible Authentication Protocol (EAP) (E): Microsoft: secure password (EAP-MSCHAP v2) (enable encryption)

Click OK

After the setup is completed, it is shown in the following figure

Windows IKEv2 × × connection attribute

Now the × × connection is ready to use.

Disable EKU inspection

After the CA and server certificates are set correctly on pfSense 2.2.4 and later, it is no longer necessary to disable EKU checking. If you must use an incorrect server certificate for some reason, you may need to disable extended key usage checking on Windows. Disabling this check also disables validation of the certificate's common name and SAN fields, so it can be dangerous. When you disable this server, you can use any certificate from the same CA, so proceed with caution.

To disable extended key usage checking, open the Registry Editor on the Windows client and navigate to the following location in the client registry:

HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ services\ RasMan\ Parameters\

Add a new DWORD entry named DisableIKENameEkuCheck and set its value to "1".

A reboot may be required to activate the settings.

IOS 11 IKEv2 client configuration

Starting with IOS9, iOS has built-in support for IKEv2, which can be configured from GUI without the need for a × × configuration file. Like other customers, a CA certificate must be installed.

Import CA to OS device

Importing an CA certificate into a client device is a relatively easy process. The first step is to get the CA certificate to the client device. The easiest way is to receive the CA certificate through email, as shown in the picture, using the iOS mail client to receive the CA certificate.

The iOS mail client receives the CA certificate

Install the certificate from email:

Send only the CA certificate (not the key) to an email address that is accessible from the client device

Open the mail application on the client device

Open the message containing the CA certificate

Click the attachment to install the CA certificate, and the installation profile prompt will be displayed in the iOS CA certificate installation profile prompt

IOS CA Certificate installation profile Tip

Click "install" at the top right, and a warning screen appears, as shown in the iOS security certificate installation warning.

Click the installation at the top right to reconfirm, and then display a final prompt, as shown in the iOS CA certificate confirmation prompt

Click install at the confirmation prompt and now store the CA certificate as a trusted entry.

Set up × × connection

Once the CA certificate is installed, you must configure a × × entry:

Enter the settings of mobile phone > General > × × ×

Add × × configuration

Set the type to IKEv2 (default)

Enter a description (for example, ExampleCo × ×)

Enter the firewall hostname or IP address in the server

Enter the hostname of the firewall again in Remote ID

Note: this must match the common name and SAN entry of the server certificate.

Local ID is left blank

Set user authentication to user name

Enter a user name or password

Note: with EAP-MSCHAPv2, the user name is the identifier configured for the user entry on the pre-shared key tab under "× ×" > "IPsec". Using EAP-RADIUS, this will be the user name set on the RADIUS server.

Click finish

IOS IKEv2 client Settings

Connect and disconnect

You can connect or disconnect × × by accessing the entry under the settings. There is a slight difference between the two places:

Set up × ×

Settings > General > × ×

Once there is at least one × × connection, an × × entry will appear directly in the setting.

Once in the × × list, you must select the × × entry (a check mark appears next to its entry), and then the slider can be moved to the "on" position to connect.

IOS × × list

Test IPsec connection

For IPsec tunnels, the easiest test is to ping from one client behind the firewall to another. If you can ping, the tunnel can work normally.

As mentioned in pfSense-initiated traffic and IPsec, traffic initiated from pfSense firewalls usually does not tunnel without additional routes, but the source specified by PING allows you to quickly test the connection of the firewall itself.

There are two ways to perform this test: GUI and shell.

Using Ping tools in GUI

In GUI, follow these steps

Navigate to system Diagnostics > Ping

Enter the IP of a remote router remote tunnel subnet in the host field (for example, 10.5.0.1)

IPv4 is selected for protocol.

Source address: select an interface or IP address on the local firewall (for example, select LAN as the LAN IP address)

Maximum number of ping. Default is 3.

Click Ping

If the tunnel is working properly, the firewall will receive an ping reply from the LAN address of site B.

If a tunnel is not established initially, it is common to lose several ping during tunnel negotiation, so if the first attempt fails, it is a good idea to choose more times or rerun the test.

Using the Ping command in Shell

Using shell on the Control Station or through ssh, you can run the ping command manually and specify the source address using the-S parameter. If-s or static routes are not used, packets generated by ping will not attempt to pass through the tunnel. Here is a simple test syntax:

# ping-S

The local LAN IP is the IP address on the inside interface defined by the local subnet of the tunnel, while the remote LAN IP is the IP address in the remote subnet listed on the remote router. In most cases, this is just the LAN IP address of each pfSense firewall. According to the site-to-site example above, this is entered from the console of the Site A firewall:

# ping-S 10.3.0.1 10.5.0.1

If the tunnel is working properly, the firewall will receive an ping reply from the LAN address of site B.

Troubleshooting IPsec

Because of the picky nature of IPsec, problems are not uncommon. Fortunately, there are some basic troubleshooting steps that can be used to track potential problems.

IPsec log

The examples introduced in this chapter are logs edited for brevity, but there is still important information.

IPsec logs can be configured to provide more useful information. To configure IPsec logging in pfSense to diagnose tunnel problems, follow these steps:

Navigate to the × × × > IPsec Advanced Settings tab

Set IKE SA, IKE Child SA, Configuration Backend to diagnostics

Set all other log settings to control

Click Save

Be careful

Changing the logging option does not interrupt IPsec activity, nor does it require you to enter a specific "debug mode" for IPsec on the current version of pfSense.

Tunnel cannot be built

First check the system status > the status of the system service. If the IPsec service has been stopped, check that it is enabled at * * × > IPsec. Also, if you are using a mobile client, make sure that the enable box on the mobile client is also selected.

If the service is running, check the firewall log (system status > system log, firewall tab) to see if the connection is blocked, and if so, add a rule to allow blocked traffic. Rules are usually added automatically for IPsec, but this feature can be disabled.

The most common reason for IPsec tunnel connection failure is a configuration mismatch. Typically, it is small, for example, the DH group is set to 1 on the A side, 2 on the B side, or a subnet mask of / 24 on one side or / 32 on the other. Some routers (Linksys) also like to hide some of the options behind the Advanced button. A lot of trial and error may involve a lot of log reading, but it is most helpful to ensure that both sides match accurately.

Depending on the Internet connection at both ends of the tunnel, the router involved by one or the other may not handle IPsec traffic correctly. This is a greater concern for the networks involved by mobile clients and NAT beyond the actual IPsec endpoints. Generally speaking, the ESP protocol has been blocked or mishandled. NAT traversal (NAT-T) encapsulates ESP in UDP port 4500 traffic to solve these problems.

The tunnel has been established, but there is no traffic flow.

If a tunnel is established but no traffic is passing through, you should first check the IPsec firewall rules. If site A cannot reach site B, check the firewall logs and rules for site B. Conversely, if site B cannot contact site A, check site A's firewall logs and rules. Before viewing the rules, check the firewall log in system status > Syslog on the Firewall tab. If there are blocked entries involving subnets used in the IPsec tunnel, continue to check the rules.

Blocking packets on IPsec or enc0 interfaces indicate that the tunnel itself has been established, but traffic is being blocked by firewall rules. Packets blocking on a local area network or other internal interface may indicate that additional rules may be required on that interface rule set to allow traffic from the internal subnet to reach the far end of the IPsec tunnel. Blocking packets on the WAN or OPT WAN interface prevent the establishment of a tunnel. This usually occurs only when the automatic × × rule is disabled. Adding a rule that allows ESP protocol and UDP port 500 from this remote IP address will allow tunneling. In the case of mobile tunnels, allow traffic from any source to connect to these ports.

The rules for the IPsec interface can be found under Firewall > Rule Policy on the IPsec tab. Common errors include setting rules to allow only TCP traffic, which means that protocols such as ICMP ping and DNS cannot work through tunnels.

In some cases, mismatched settings may also prevent traffic from passing through the tunnel. In one example, the subnet defined on a non-pfSense firewall is 192.0.2.1 Universe 24, while on the pfSense firewall it is 192.0.2.0 Universe 24. A tunnel is established, but traffic cannot pass through until the subnet is corrected.

Routing problems are another possibility. Using a trace route (tracert on Windows) to check the IP address on the other side of the tunnel can help track down these types of problems. Repeat the tests on both sides of the tunnel. When tracking routing (traceroute) is used, traffic entering and leaving the IPsec tunnel seems to lack some intermediate jumps. This is normal and part of IPsec's work. Traffic that does not enter the IPsec tunnel correctly will appear as leaving the WAN interface and routing outward through the Internet, which will point to routing problems, such as the pfSense is not a gateway (as in routing and gateway considerations), the remote subnet on the tunnel definition is incorrectly specified, or the tunnel is disabled.

Some mainframes work, but not all

If the traffic between some hosts passing through × × is normal, but other hosts do not pass, it is usually one of the following four situations:

1. Missing, incorrect, or ignored default gateway: if the device does not have a default gateway, or if there is a device pointing to a device other than the pfSense firewall, you do not know how to correctly return the remote network on xxx. Some devices do not use that gateway even if they use the specified default gateway. This has occurred on a variety of embedded devices, including IP cameras and some printers. Nothing can be done except to fix the software on the device. This can be verified by running packet capture on the internal interface of the firewall connected to the network that contains the device. Use tcpdump for troubleshooting, and an IPsec-specific example can be found in the IPsec tunnel. If traffic is observed leaving the internal interface of the firewall but no reply is returned, the device does not route its reply traffic correctly or may be blocked through the local client firewall.

two。 Incorrect subnet mask: if one end uses a subnet of 10.0.0.0ax 24 and the other end has a subnet mask of 255.0.0.0 or / 8, the host can never communicate through × × because it believes that the remote × × × subnet is part of the local network, so the routing will not work properly. A system that configures an outage will try to contact the remote system through ARP instead of using a gateway.

3. Host firewall: if there is a firewall on the target host, connections may not be allowed. Checking the Windows firewall, iptables, or similar utility may prevent the host from processing traffic.

Firewall rules on 4.pfSense: ensure that the rules on both sides allow the required network traffic.

Connection suspended

IPsec does not handle fragmented packets properly. Many of these problems have been solved over the years, but there may be some lagging problems. If you see hang or packet loss only when using a specific protocol (SMB,RDP, etc.), you may need to set MSS. You can activate the MSS limit on the Advanced Settings tab of "× × > IPsec". On this page, check to enable the MSS limit on × × communication, and then enter a value. You can start by typing 1400, slowly increase the MSS value until you connect properly, and then lower it a little bit.

"Random" tunnel disconnect / DPD failure on embedded router

On other embedded hardware, it may be necessary to disable DPD on the tunnel if the IPsec tunnel is discarded. This failure tendency is associated with high bandwidth usage time. This occurs when CPU on a low-power system sends IPsec traffic or consumes other resources. Due to CPU overload, you may not be able to take the time to respond to DPD requests or see the response to your own request. As a result, the tunnel will not pass the DPD check and disconnect. This shows that the hardware is going beyond its limits. If this happens, consider using more powerful hardware.

The tunnel has been established and working, but cannot be renegotiated

In some cases, the tunnel is operating normally, but once the useful life of Phase 1 or Phase 2 expires, the tunnel will not be renegotiated correctly. This can be shown in several different ways, each with a different way of resolution.

DPD not supported, discarded by one party and discarded by the other

Traffic originating from site An is tunneled from site A to site B.

Phase 1 or phase 2 in which site B expires before site A.

Site A will believe that the tunnel has been started and continues to send traffic, just as the tunnel is working properly.

Site A renegotiates as expected only when the useful life of Phase 1 or Phase 2 of site An expires.

In this case, two possible solutions are to enable DPD, or site B must send traffic to site A, which will cause the entire tunnel to be renegotiated. The easiest way to achieve this is to enable a survival mechanism on both sides of the tunnel.

The tunnel is established at startup, not at response time

If tunnels are sometimes built, but not always, generally speaking, some aspect is mismatched. The tunnel can still be built because if the setting proposed by one side is more secure, the other side can accept it, but not the other way around. For example, if you communicate with a site with Aggressive / Main mode set at an IKEv1 tunnel and a site that is set to Main mode, although it does not match, the tunnel will still be established. However, if the port set to Aggressive attempts to start the tunnel, it will fail.

A period of validity mismatch does not cause Phase 1 or Phase 2 to fail.

To track these failures, configure the log as described in IPsec logging, then try to initiate a connection tunnel from each side, and then check the log.

IPsec log description

The IPsec log provided in system status > system Log on the IPsec tab contains a record of the tunnel connection process and some messages from ongoing tunnel maintenance activities. This section lists some typical log entries, including good and bad. The main thing to look for is a key phrase that indicates which part of the connection works. If "IKE_SA... established" exists in the log, it means that phase 1 has been successfully completed and the security association has been negotiated. If "CHILD_SA... has been established", then the second phase has been completed and the tunnel has been built.

In the following example, the log is configured to listen in the IPsec logging, and irrelevant messages may be ignored. Please keep in mind that these are samples, specific ID numbers, IP addresses, and so on will be different.

Successful connection

When the tunnel is successfully established, both sides establish an IKE SA and a sub-SA. When multiple phase 2 definitions appear with IKEv1, the child SA is negotiated for each phase 2 entry.

The initiator's log shows:

Charon: 09 [IKE] IKE_SA con2000 [11] established between 192.0.2.90 [192.0.2.90]... 192.0.2.74 [192.0.2.74] charon: 09 [IKE] CHILD_SA con2000 {2} established with SPIs cf4973bf_i c1cbfdf2_o and TS 192.168.48.0 established with SPIs cf4973bf_i c1cbfdf2_o and TS 24 | / 0 = = 10.42.42.0

The responder's log shows:

Charon: 03 [IKE] IKE_SA con1000 [19] established between 192.0.2.74 [192.0.2.74]... 192.0.2.90 [192.0.2.90] charon: 16 [IKE] CHILD_SA con1000 {1} established with SPIs c1cbfdf2_i cf4973bf_o and TS 10.42.42.0 established with SPIs c1cbfdf2_i cf4973bf_o and TS 24 | / 0 = = 192.168.48.0 Unip 24 | / 0

Example of a failed connection

These examples show connections that fail for a variety of reasons in most cases, it is clear from the example that the initiator does not receive a message about a specific item mismatch, so the responder log is more informative. This is done to protect the tunnel, and it is not safe to provide information to potential users, which will provide them with information about the tunnel configuration.

Aggressive / Main mismatch for stage 1

In this example, the launcher is set to Aggressive mode and the responder is set to Main mode.

The initiator's log shows:

Charon: 15 [IKE] initiating Aggressive Mode IKE_SA con2000 [1] to 203.0.113.5charon: 15 [IKE] received AUTHENTICATION_FAILED error notifycharon: 13 [ENC] parsed INFORMATIONAL_V1 request 1215317906 [N (AUTH_FAILED)] charon: 13 [IKE] received AUTHENTICATION_FAILED error notify

The responder's log shows:

Charon: 13 [IKE] Aggressive Mode PSK disabled for security reasonscharon: 13 [ENC] generating INFORMATIONAL_V1 request 2940146627 [N (AUTH_FAILED)]

Note that the log in the responder status clearly indicates that the Aggressive schema has been disabled, which is a good clue to the pattern mismatch.

On the contrary, if the endpoint set for Main mode starts, a tunnel to the pfSense firewall will be established because Main mode is more secure.

Phase 1 identifier mismatch

When the identifiers do not match, the initiator only shows that the authentication failed, but for no reason. The responder indicated that the peer could not be found, indicating that the matching phase 1 could not be found, which means that the matching identifier could not be found.

The initiator's log shows:

Charon: 10 [ENC] parsed INFORMATIONAL_V1 request 4216246776 [HASH N (AUTH_FAILED)] charon: 10 [IKE] received AUTHENTICATION_FAILED error notify

The responder's log shows:

Charon: 12 [CFG] looking for pre-shared key peer configs matching 203.0.113.5.. 198.51.100.3 [someid] charon: 12 [IKE] no peer config foundcharon: 12 [ENC] generating INFORMATIONAL_V1 request 4216246776 [HASH N (AUTH_FAILED)]

Phase 1 pre-shared key mismatch

Mismatched preshared keys can be difficult to diagnose. An error indicating that this value does not match is not displayed in the log, but the following message is displayed:

The initiator's log shows:

Charon: 09 [ENC] invalid HASH_V1 payload length, decryption failed?

Charon: 09 [ENC] could not decrypt payloads

Charon: 09 [IKE] message parsing failed

The responder's log shows:

Charon: 09 [ENC] invalid ID_V1 payload length, decryption failed?

Charon: 09 [ENC] could not decrypt payloads

Charon: 09 [IKE] message parsing failed

When the above log messages exist, check the pre-shared key values of both parties to ensure that they match.

Phase 1 encryption algorithm mismatch

The initiator's log shows:

Charon: 14 [ENC] parsed INFORMATIONAL_V1 request 3851683074 [N (NO_PROP)] charon: 14 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 14 [CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14 [CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14 [IKE] no proposal foundcharon: 14 [ENC] generating INFORMATIONAL_V1 request 3851683074 [N (NO_PROP)]

In this case, the log entry is an exact illustration of the problem: the initiator is set to AES 128 encryption and the responder is set to AES 256. Set the two values to match and try again.

Phase 1 hash algorithm mismatch

The initiator's log shows:

Charon: 10 [ENC] parsed INFORMATIONAL_V1 request 2774552374 [N (NO_PROP)] charon: 10 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 14 [CFG] received proposals: IKE:AES_CBC_256/MODP_1024charon: 14 [CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14 [IKE] no proposal foundcharon: 14 [ENC] generating INFORMATIONAL_V1 request 2774552374 [N (NO_PROP)]

The hash algorithm is displayed by the HMAC section provided by the record. As you can see above, there are no matching HMAC entries for the received and configured propsals.

Phase 1 DH group mismatch

The initiator's log shows:

Charon: 11 [ENC] parsed INFORMATIONAL_V1 request 316473468 [N (NO_PROP)] charon: 11 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 14 [CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192charon: 14 [CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14 [IKE] no proposal foundcharon: 14 [ENC] generating INFORMATIONAL_V1 request 316473468 [N (NO_PROP)]

The DH group is represented by the "MODP" section of the example. As shown in the log message, the initiator is set to 8192 (group 18) and the responder is set to 1024 (group 2). This error can be corrected by setting the DH group at both ends of the tunnel to a matching value.

Phase 2 network mismatch

In the following example, the stage 2 entry on the initiator side is set to 10.3.0.0swap 24 to 10.5.0.0lap24. The responder is not set to match because it lists 10.5.1.0 take 24.

The initiator's log shows:

Charon: 08 [CFG] proposing traffic selectors for us:charon: 08 [CFG] 10.3.0.0 HASH SA No ID ID 24 | / 0charon: 08 [CFG] proposing traffic selectors for other:charon: 08 [CFG] 10.5.0.0According to 24 | / 0charon: 08 [ENC] generating QUICK_MODE request 316948142 [HASH SA No ID ID] charon: 08 [NET] sending packet: from 198.51.100.3 [500] to 203.0.113.5 [bytes] charon: 08 [NET] received packet: From 203.0.113.5 [500] to 198.51.100.3 [76 bytes) charon: 08 [ENC] parsed INFORMATIONAL_V1 request 460353720 [HASH N (INVAL_ID)] charon: 08 [IKE] received INVALID_ID_INFORMATION error notify

The responder's log shows:

Charon: 08 [ENC] parsed QUICK_MODE request 2732380262 [HASH SA No ID ID] charon: 08 [CFG] looking for a child config for 10.5.0.0Unip 24 | / 0 = 10.3.0.0Unip 24 | / 0charon: 08 [CFG] proposing traffic selectors for us:charon: 08 [CFG] 10.5.1.0 0charon 24 | / 0charon: 08 [CFG] proposing traffic selectors for other:charon: 08 [CFG] 10.3.0.0Unip 24 | / 0charon: 08 [IKE] no matching CHILD_SA Config foundcharon: 08 [IKE] queueing INFORMATIONAL taskcharon: 08 [IKE] activating new taskscharon: 08 [IKE] activating INFORMATIONAL taskcharon: 08 [ENC] generating INFORMATIONAL_V1 request 1136605099 [HASH N (INVAL_ID)]

In the responder log, it lists the networks it received (the "child config" line in the log) and what it configured locally ("proposing traffic selectors for us...." in the log). OK). By comparing the two, we can find that they do not match. When this mismatch occurs, the "no matching CHILD_SA config foundcharon" line in the log always exists and directly indicates that the phase 2 definition cannot be found to match what was received from the initiator.

Phase 2 encryption algorithm mismatch

The initiator's log shows:

Charon: 14 [CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 14 [ENC] generating QUICK_MODE request 759760112 [HASH SA No ID ID] charon: 14 [NET] sending packet: from 198.51.100.3 [to 203.0.113.5] (188 bytes) charon: 14 [NET] received packet: from 203.0.113.5 [500] to 198.51.100.3 [(76 bytes) charon: 14 [ENC] parsed INFORMATIONAL_V1 request 1275272345 [HASH N (NO_PROP)] charon: 14 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 13 [CFG] selecting proposal:charon: 13 [CFG] no acceptable ENCRYPTION_ALGORITHM foundcharon: 13 [CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 13 [CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 13 [IKE] no matching proposal found Sending NO_PROPOSAL_CHOSENcharon: 13 [IKE] queueing INFORMATIONAL taskcharon: 13 [IKE] activating new taskscharon: 13 [IKE] activating INFORMATIONAL taskcharon: 13 [ENC] generating INFORMATIONAL_V1 request 1275272345 [HASH N (NO_PROP)]

In this case, the initiator receives a message that the responder cannot find the appropriate offer ("received NO_PROPOSAL_CHOSEN"), and as you can see from the responder log, this is because the site is set to a different encryption type, AES 128on one side and AES 256on the other.

Phase 2 hash algorithm mismatch

The initiator's log shows:

Charon: 10 [CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 10 [ENC] generating QUICK_MODE request 2648029707 [HASH SA No ID ID] charon: 10 [NET] sending packet: from 198.51.100.3 [to 203.0.113.5] charon: 10 [NET] received packet: from 203.0.113.5 [to 198.51.100.3] (76 bytes) Charon: 10 [ENC] parsed INFORMATIONAL_V1 request 757918402 [HASH N (NO_PROP)] charon: 10 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 11 [CFG] selecting proposal:charon: 11 [CFG] no acceptable INTEGRITY_ALGORITHM foundcharon: 11 [CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 11 [CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 11 [IKE] no matching proposal found Sending NO_PROPOSAL_CHOSENcharon: 11 [IKE] queueing INFORMATIONAL taskcharon: 11 [IKE] activating new taskscharon: 11 [IKE] activating INFORMATIONAL taskcharon: 11 [ENC] generating INFORMATIONAL_V1 request 757918402 [HASH N (NO_PROP)]

Similar to the phase 1 hash algorithm mismatch, the HMAC values in the log entries are not aligned. However, when this happens in Phase 2, the responder will also record the clearer message "No acceptable INTEGRITY_ALGORITHM found".

Phase 2 PFS mismatch

The initiator's log shows:

Charon: 06 [ENC] generating QUICK_MODE request 909980434 [HASH SA No KE ID ID] charon: 06 [NET] sending packet: from 198.51.100.3 [500] to 203.0.113.5 [bytes] charon: 06 [NET] received packet: from 203.0.113.5 [to 198.51.100.3] (76 bytes) charon: 06 [ENC] parsed INFORMATIONAL_V1 request 3861985833 [HASH N (NO_PROP)] charon: 06 [IKE] received NO_PROPOSAL_CHOSEN error notify

The responder's log shows:

Charon: 08 [CFG] selecting proposal:charon: 08 [CFG] no acceptable DIFFIE_HELLMAN_GROUP foundcharon: 08 [CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQcharon: 08 [CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 08 [IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 08 [ENC] generating INFORMATIONAL_V1 request 3861985833 [HASH N (NO_PROP)]

PFS works like the first phase of the DH group, but is optional. When the selected PFS options do not match, a clear message is logged pointing out the fact that "no acceptable DIFFIE_HELLMAN_GROUP was found." PFS (Perfect Forward Secrecy's perfect forward secrecy) is a secure communication protocol that prevents the destruction of one encrypted session from causing the destruction of multiple encrypted sessions. With PFS, the server generates a unique private key for each secure session established with the client. If the server private key is corrupted, only a single session established with that key will not be able to retrieve data from past and future sessions because the server uses a unique generated key to establish each connection.

Be careful

In some cases, if one side's PFS is set to off and the other party sets a value, the tunnel can still build and work. The mismatch shown above can only be seen if the values do not match, for example, 1 to 5.

Identifiers that do not match NAT

In this case, the pfSense is configured as the peer identifier of the peer IP address, but the remote device actually comes after the NAT. In this case, strongSwan expects the actual private NAT-IP address as the identifier. The racoon daemon used on older versions is much easier and can match any address, but strongSwan is more formal and needs to be matched correctly.

The responder's log shows:

Charon: 10 [IKE] remote host is behind NAT

Charon: 10 [IKE] IDir '192.0.2.10' does not match to '203.0.113.245' [...]

Charon: 10 [CFG] looking for pre-shared key peer configs matching 198.51.100.50...203.0.113.245 [192.0.2.10]

To correct this, change the peer identifier setting to the IP address, and then enter the IP address before NAT, in this case 192.0.2.10.

Vanishing traffic

If IPsec traffic arrives but never appears on the IPsec interface (enc0), check for conflicting route / interface IP addresses. For example, if an IPsec tunnel is configured with a remote network of 192.0.2.0Universe 24, and there is a local Open × × server and a tunnel network of 192.0.2.0Universe 24, then ESP traffic may arrive and strongSwan may process these packets, but they never appear at the enc0as delivered by the operating system.

Resolve duplicate interfaces / routes and traffic will begin to pass.

IPsec status Page issu

If an error occurs on the IPsec status page, such as:

Warning: Illegal string offset 'type' in / etc/inc/xmlreader.inc on line 116

This indicates that the incomplete xmlreader XML parser is active, which is triggered by the existence of the file / cf / conf / use_xmlreader. This alternative parser can read large config.xml files faster, but lacks some of the functionality necessary for other areas to work well. Removing / cf / conf / use_xmlreader immediately returns the system to the default parser, which corrects the display of the IPsec status page.

IPsec terminology

Before delving into the configuration, there are several terms that need to be explained in this chapter. Other terms are used to explain in more detail in configuration options.

IKE

IKE stands for Internet key exchange, which is divided into two types: IKEv1 and IKEv2. Almost all devices that support IPsec use IKEv1. More and more devices also support the newer IKEv2 protocol, which is a newer version of IKE, which solves some of the problems in earlier versions. For example, IKEv2 has MOBIKE, which is the standard for mobile clients, allowing them to switch addresses dynamically. It also has a built-in NAT traversal function and a reliability standard mechanism similar to DPD. In general, IKEv2 provides a more stable and reliable experience, but both sides must support it.

ISAKMP Security Alliance

ISAKMP stands for Internet Security Alliance and key Management Protocol. It provides a mechanism for both parties to establish a secure communication channel, including exchanging keys and providing authentication.

The ISAKMP Security Alliance (ISAKMP SA) is an one-way policy that defines how to encrypt and handle traffic. Each active IPsec tunnel will have two security associations, one in each direction. The ISAKMP security association is set between the public IP addresses of each endpoint. The data associated with these active security associations is stored in the security association database (SAD).

Security policy

Security policy is a complete specification for managing IPsec tunnels. Like the Security Association, these are one-way, so each tunnel has one in each direction. These entries are saved in the security policy database (SPD). Once a tunnel is added, each tunnel connection is populated with two entries for the SPD. By contrast, the SAD entry exists only if the connection is successfully negotiated.

In pfSense software, the security policy control kernel intercepts traffic that passes through IPsec.

Stage 1

The IPsec tunnel has two stages of negotiation. In phase 1, a secure channel is established between the two endpoints of the tunnel to negotiate SA entries and exchange keys using ISAKMP. This also includes authentication, checking identifiers, and checking pre-shared keys (PSK) or certificates. After the first phase is completed, the two sides can exchange information securely, but no decision has been made on the traffic to pass through the tunnel or its encryption.

Stage 2

In phase 2, the two endpoints negotiate how to encrypt and send the data of the dedicated host according to the security policy. This section builds a tunnel for transferring data between the endpoint and the client that the endpoint handles traffic. If the policies of both parties are the same and the second phase is successfully established, the tunnel will be started and ready for traffic that matches the second phase definition.

Translated from pfsense book

2017-11-21

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.