Security

 View Only
last person joined: 6 days ago 

Ask questions and share experiences with Juniper Connected Security. Discuss Advanced Threat Protection, SecIntel, Secure Analytics, Secure Connect, Security Director, and all things related to Juniper security technologies.

IKE v2 P1 phase PRF default settings

  • 1.  IKE v2 P1 phase PRF default settings

    Posted 6 days ago
    Edited by Jodi Meier 6 days ago

    Hi all,

       I hope someone can shed some light on this issue regarding bringing up an IPSec between an old SSG-550 (yes it's old!) and a Fortinet 1001. During the initial Ike-v2 P1 set with AES 256 encryption, SHA 256 auth and DH group 14 on both ends with preshared key the SSG logs an unmatched PRF algorithm (debug ike all stream dump)- details below:

    SSG IKE P1 P2 conf:

    set ike p1-proposal "VPN_P1" preshare group14 esp aes256 sha2-256 second 86400
    set ike p2-proposal "VPN_P2" no-pfs esp aes256 sha2-256 second 43200
    set ike gateway ikev2 "IPSEC VPN" address xx.xx.xxx.xxx outgoing-interface "loopback.33" preshare "xxxkey" proposal "VPN_P1"
    set ike gateway ikev2 "IPSEC VPN" auth-method self preshare peer preshare
    set vpn "REMOTESITE" gateway "IPSEC VPN" no-replay tunnel idletime 0 proposal "VPN_P2" 

    Debug ike all stream relevant part:

    ## 2025-03-10 16:19:28 : Process [SA] for IKEv2
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx>   rmt_prop[0] protocol 1, encr 0, prf 0, auth 0, dh 0, esn 0
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   Process transform type 1, id 12.
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   skip attribute processing for transform 1.
    dump *payload (12):
    03 00 00 0c 01 00 00 0c  80 0e 01 00 
    dump xform_attr (4):
    80 0e 01 00 
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   prop->key_len 256.            <------------------------
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   xform_payload.trans_type 1, prop->enc_alg 12.    <------------------------ AES 256
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   Process transform type 2, id 5.
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   xform_payload.trans_type 2, prop->prf_alg 5.    <------------------------ PRF 5 ? Should be 12?
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   Process transform type 3, id 12.
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   xform_payload.trans_type 3, prop->auth_alg 12.    <------------------------ SHA 256
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx  >   Process transform type 4, id 14.
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   xform_payload.trans_type 4, prop->dh_group 14.    <------------------------ DH 14
    ## 2025-03-10 16:19:28 : IKE<xx.xx.xxx.xxx   >   Proposal 1: 1 enc, 1 prf, 1 auth, 1 dh, 1 esn, 0.
    ## 2025-03-10 16:19:28 : Before matched proposal num_props = 1, max_prop = 10

    ## 2025-03-10 16:19:28 : prf algorithm does not match 

    And the P1 is not established and the loop restarts. I have been trying to find out what prf_alg 5 exactly is - in any case it is evidently not the same as the one on the Fortinet side which is supposedly the same as the one set for Authentication (SHA256) as read in some documentation - but this is also not editable apparently. I found no documentation relevant to these table numbers (12 and 5) anywhere.

    Thanks for any insight, I know it's a long shot and the hardware is old but I don't see why a tunnel shouldn't be established with compatible and still supported methods.



    ------------------------------
    Luca Forattini
    ------------------------------