Jump to:navigation, search
Wiki

IPSec Troubleshooting

From Securepoint Wiki





notempty
Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!

notempty
Der Artikel für die neueste Version steht hier

notempty
Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Reseller-Preview bezieht





































































De.png
En.png
Fr.png

UTM v12.2.3 IPSec Log-en.png






IPSec Troubleshooting
Last adaptation to the version: 12.2.3
New:
  • The log level can be set directly in the admin interface
notempty
This article refers to a Resellerpreview

12.2 11.7 11.6.12

Preparation - Increase log level

Tab Log

Log

As a prerequisite for successful troubleshooting, the log level must first be increased.

When the log level is changed, the IPSec service is restarted. All IPSec connections are interrupted once during this process.
Log-Level:
New as of 12.2.3
 Rudimentary (recommended) Default setting
Detailed Suitable for detailed troubleshooting
very detailed May be required for specific troubleshooting
  • This setting generates an excessive number of messages, so that the log will reach its limit within a very short time and, as a result, messages will have to be deleted more quickly. Important messages (from other services) may be overlooked. It is recommended not to use this setting or to use it only for a short time.
    • User-defined All values can be logged in the
    Advanced settings
     section in 5 different levels
    Save the changed settings with Save and restart
  • This restarts the IPSec service and briefly interrupts all IPSec connections once.


    • Alternative option to change the log level:

    CLI command

    extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ]

  • IPSec service must then be restarted. This interrupts all IPSec connections! }}

    Menu → Applications →Application status Application IPSEC Button


    • Alternative option to change the log level:

    Set extc-variable

    In the advanced settings: → Extras →Advanced SettingsTab extc-variables search for DBG_LVL_IKE change value to » ✕2
  • IPSec service must then be restarted. This interrupts all IPSec connections! }}

    Menu → Applications →Application status Application IPSEC Button


    • Alternative option to change the log level:

    SSH

    via SSH at runtime as root
  • Here the IPSec service does not have to be restarted.
    • (only up to version 12.1.8):
      ipsec stroke loglevel ike 2
      This command returns the setting to its original value after a restart!

    • (as of version 12.2):
      spcli extc value set application ipsec variable DBG_LVL_IKE value 2
      spcli appmgmt config
      swanctl --reload-settings


    IKEv1 Troubleshooting

    Ipsec troubleshooting01.png

    The establishment of an IPSec connection using IKEv1 takes place in two phases. In phase 1, both gateways are authenticated against each other. This can be done in two different ways: The "Aggressive Mode" or the "Main Mode". The aggressive mode encrypts the Pre Shared Key (PSK) using a simple hash algorithm. Apart from this PSK, no further identification is provided. This results in the following disadvantages:

    • When several remote stations are connected, they cannot be distinguished from each other in phase 1. Therefore, the same PSK must be used in all connections. The probability of being compromised increases with the number of remote stations.
    • The simple hash encryption of the PSK makes it vulnerable to dictionary attacks, and more so the simpler it is. Since no other identification feature is provided besides the PSK, such attacks can be carried out by any computer with Internet access.

    For these reasons, the aggressive mode of IPSec does not find any use in connection with Securepoint NextGen UTM. Only the secure main mode is used. In addition to the PSK, this requires a further identification feature, the so-called ID. Furthermore, the transmission of the PSK is secured by the Diffie-Hellman key exchange method. This makes it mathematically impossible to intercept a transmitted key. In addition to PSKs, the main mode also allows RSA keys or X.509 certificates for authentication.



    Phase 1

    The normal connection setup

    If no errors occur in phase 1, this is indicated by an entry in the LiveLog that reports the successful establishment of an IKE_SA. If this entry is found in both the initiator's log and the responder's log, phase 1 has been configured without errors and any configuration error should be looked for in phase 2.
    Dienst Nachricht
    IPSec(charon) 10[IKE] IKE_SA Standort_1_2[1] established between 198.51.100.75[198.51.100.75]...198.51.100.1[198.51.100.1]


    False proposal

    If both sides cannot agree on encryption parameters acceptable to both sides, the responder reports this in its livelog.
    The initiator gets the message "NO_PROPOSAL_CHOSEN".
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 10[IKE] received NO_PROPOSAL_CHOSEN notify error
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 05[CFG] selecting proposal:
    IPSec(charon) 05[CFG] no acceptable ENCRYPTION_ALGORITHM found
    IPSec(charon) 05[CFG] selecting proposal:
    IPSec(charon) 05[CFG] received proposals: IKE:BLOWFISH_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
    IPSec(charon) 05[CFG] configured proposals:IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/HMAC_MD5_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_512/256/AES_XCBC_96/AES_CMAC_96/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP_512/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP_ECP_512_BP,IKE:AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP__521/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP
    IPSec(charon) 10[IKE] received proposals inacceptable



    Incorrect remote gateway address

    If the initiator attempts to establish a connection from a gateway address other than the one configured on the responder side, the responder cannot classify this connection. This is reported accordingly in the LiveLog.
    The initiator gets the message NO_PROPOSAL_CHOSEN.
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 11[CFG] looking for an ike config for 198.51.100.75...195.51.100.1
    IPSec(charon) 11[IKE] no IKE config found for 198.51.100.75...195.51.100.1, sending NO_PROPOSAL_CHOSEN



    Incorrect ID Initiator

    If the initiator logs in with an identifier (ID) other than the one stored in the responder's configuration, the responder cannot determine a PSK configuration for this connection attempt and reports this accordingly in the LiveLog.
    The initiator receives the error message AUTHENTICATION_FAILED.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 09[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
    IPSec(charon) 07[IKE] no peer config found



    Incorrect ID Responder

    If the responder reports with a different ID than in the initiator's configuration, then this is reported accordingly in the initiator's log.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 05[IKE] IDir 'blubb' does not match to '198.51.100.75'


    Incorrect PSK

    In contrast to older software versions, there is no clearly readable hint in the log for mismatched PSKs when using IKEv1. Indirectly, the indication of "malformed" packets points to this error.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 15[IKE] message parsing failed
    IPSec(charon) 15[IKE] ignore malformed INFORMATIONAL request
    IPSec(charon) 15[IKE] INFORMATIONAL_V1 request with message ID 1054289493 processing failed
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 14[IKE] message parsing failed
    IPSec(charon) 14[IKE] ID_PROT request with message ID 0 processing failed


    Incorrect RSA key initiator

    If the initiator of the connection uses a different RSA key than the one set in the responder configuration, authentication cannot take place.
    The initiator receives the error message "AUTHENTICATION_FAILED".
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 15[IKE] authentication of 'Filiale' (myself) succesful
    IPSec(charon) 16[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 14[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
    IPSec(charon) 14[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
    IPSec(charon) 14[CFG] selected peer config "Standort1_4"
    IPSec(charon) 14[CFG] using trusted certificate "Filiale"
    IPSec(charon) 14[IKE] ignature validation failed, looking for another key
    IPSec(charon) 14[IKE] no trusted RSA public key found for 'Filiale'


    Incorrect RSA key responder

    If the responder uses a different RSA key than the one specified in the initiator's configuration, the authentication fails again on the initiator's side. The responder that has already established an IKE_SA is instructed to delete it again.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 16[CFG] authentication of 'Filiale' (myself) succesful
    IPSec(charon) 16[IKE] using trusted certificate "Zentrale"
    IPSec(charon) 16[IKE] signature validation failed, looking for another key
    IPSec(charon) 15[IKE] no trusted RSA public key found for 'Zentrale'
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 10[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
    IPSec(charon) 10[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
    IPSec(charon) 10[CFG] selected peer config "Standort1_4"
    IPSec(charon) 10[CFG] using trusted certificate "Filiale"
    IPSec(charon) 10[IKE] authentication of 'Filiale' with RSA succesful
    IPSec(charon) 10[IKE] authentication of 'Zentrale' (myself) succesful
    IPSec(charon) 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
    IPSec(charon) 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
    IPSec(charon) 10[IKE] scheduling reauthentication in 2593s
    IPSec(charon) 10[IKE] maximum IKE_SA lifetime 3133s
    IPSec(charon) 13[IKE] received DELETE for IKE_SA Standort_4[1]


    Phase 2

    The normal connection setup

    If phase 2 is also configured correctly, the successful establishment of a CHILD_SA is documented in the livelog of both sides.
    Initiator-Log & Responder-Log
    Dienst Nachricht
    IPSec(charon) 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24
    IPSec(charon) 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24

    Incorrect subnet configuration

    If the configured subnets (the so-called traffic selectors) do not match in phase 2 of the initiator and responder, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder's livelog.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 13[CFH] proposing traffic selectors for us:
    IPSec(charon) 13[CFG] 10.1.0.0/24
    IPSec(charon) 13[CFG] proposing traffic selectors for other:
    IPSec(charon) 13[CFG] 11.0.0.0/24
    IPSec(charon) 05[IKE] received INVALID_ID_INFORMATION error notify
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 11[CFG] looking for a child config for 11.0.0.0/24 === 10.1.0.0/24
    IPSec(charon) 11[CFG] proposing traffic selectors for us:
    IPSec(charon) 11[CFG] 10.0.0.0/24
    IPSec(charon) 11[CFG] proposing traffic selectors for other:
    IPSec(charon) 11[CFG] 10.1.0.0/24
    IPSec(charon) 11[IKE] no matching CHILD_SA config found


    IKEv2 Troubleshooting

    IKEv2 connection setup

    The establishment of the connection with IKEv2 has been drastically simplified compared to IKEv1. It is now no longer divided into phase 1 (authentication) and phase 2 (tunnel establishment); instead, one message pair is used to exchange first the proposals and DH keys and then the authentication and the traffic selectors (subnets). This makes the connection setup easier and less susceptible to interference.

    Connection setup

    Connection is established

    Initiator-Log & Responder-Log
    Dienst Nachricht
    IPSec(charon) 11[CFG] selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
    IPSec(charon) 11[CFG] selecting traffic selectors for us:
    IPSec(charon) 11[CFG] config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24
    IPSec(charon) 11[CFG] selecting traffic selectors for ther:
    IPSec(charon) 11[CFG] config: 10.0.0.0/24, received: 10.0.0.0/24 0 => match: 10.0.0.0/24
    IPSec(charon) 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24
    IPSec(charon) 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24


    Incorrect remote gateway address

    If the gateway address of the initiator and the remote gateway address specified in the responder configuration do not match, the connection attempt cannot be assigned. This is reported in the responder's log.
    The initiator receives the error message "NO_PROPOSAL_CHOSEN".
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 11[CFG] looking for an ike config fo 198.51.100.75...198.51.100.1
    IPSec(charon) 11[IKE] no IKE config for 198.51.100.75...198.51.100.1, sending NO_PROPOSAL_CHOSEN


    Incorrect ID Initiator

    If the configured remote ID does not match the ID reported by the initiator, the connection attempt cannot be assigned here either and is documented in the responder log.
    The initiator gets the error message AUTHENTICATION_FAILED.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 09[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
    IPSec(charon) 07[IKE] no peer config found


    Incorrect ID Responder

    Vice versa, a responder ID other than the one configured at the initiator is reported accordingly in the initiator's log.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 05[IKE] IDir 'blubb' does not match to '198.51.100.75'


    Incorrect PSK

    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 13[IKE] received AUTHENTICATION_FAILED notify error
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 10[IKE] tried 2 shared keys for '198.51.100.75' - '198.51.100.1', but MAC mismatched


    Incorrect subnet configuration

    If the configured subnets (the so-called traffic selectors) of initiator and responder do not match in the second step, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder's livelog.
    Initiator-Log
    Dienst Nachricht
    IPSec(charon) 10[IKE] received T S_UNACCEPTABLE notify, no CHILD_SA built
    IPSec(charon) 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
    Responder-Log
    Dienst Nachricht
    IPSec(charon) 05[CFG] looking for a child config for 10.0.0.0/24 === 11.1.0.0/24
    IPSec(charon) 05[CFG] proposing traffic selectors for us:
    IPSec(charon) 05[CFG] 10.0.0.0/24
    IPSec(charon) 05[CFG] proposing traffic selectors for other:
    IPSec(charon) 05[CFG] 10.1.0.0/24
    IPSec(charon) 10[IKE] traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable
    IPSec(charon) 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
    Retrieved from "https://wiki.securepoint.de/index.php?title=UTM/VPN/IPSec-Troubleshooting_v12.2.3&oldid=88300"