Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Phase 2 Established Only From pfSense Side

    Scheduled Pinned Locked Moved IPsec
    1 Posts 1 Posters 444 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      Mattman
      last edited by Mattman

      Hello,

      I am having a very similar, although opposite, issue as in this topic. In that issue, only the Cisco side could establish the child SA, but in my case only the pfSense side is successful.

      I am running a Netgate SG-5100 using pfSense version 2.4.5-RELEASE-p1 (amd64).
      They are running a HA pair of Cisco FTD2130s, both running version 6.6.1.

      The local pfSense network in the phase 2 is a VLAN 10.101.100.0/29. The remote Cisco network is 10.208.6.0/24. When the phase 2 is down, initiating traffic from the pfSense side brings it up no problems and everything works great. However, if the Cisco side is the initiator, then we get the following error in the logs (clog -f /var/log/ipsec.log):

      Aug 13 10:26:51 pfSense charon: 05[MGR] IKE_SA con41000[111160] successfully checked out
      Aug 13 10:26:51 pfSense charon: 05[NET] <con41000|111160> received packet: from y.y.y.y[500] to x.x.x.x[500] (288 bytes)
      Aug 13 10:26:51 pfSense charon: 05[ENC] <con41000|111160> parsed CREATE_CHILD_SA request 62 [ SA No TSi TSr ]
      Aug 13 10:26:51 pfSense charon: 05[CFG] <con41000|111160> looking for a child config for 10.101.100.2/32|/0 10.101.100.0/29|/0 === 10.208.6.31/32|/0 10.208.6.0/24|/0
      Aug 13 10:26:51 pfSense charon: 05[IKE] <con41000|111160> traffic selectors 10.101.100.2/32|/0 10.101.100.0/29|/0 === 10.208.6.31/32|/0 10.208.6.0/24|/0 unacceptable
      Aug 13 10:26:51 pfSense charon: 05[IKE] <con41000|111160> failed to establish CHILD_SA, keeping IKE_SA
      Aug 13 10:26:51 pfSense charon: 05[ENC] <con41000|111160> generating CREATE_CHILD_SA response 62 [ N(TS_UNACCEPT) ]
      Aug 13 10:26:51 pfSense charon: 05[NET] <con41000|111160> sending packet: from x.x.x.x[500] to y.y.y.y[500] (96 bytes)
      Aug 13 10:26:51 pfSense charon: 05[MGR] <con41000|111160> checkin IKE_SA con41000[111160]
      Aug 13 10:26:51 pfSense charon: 05[MGR] <con41000|111160> checkin of IKE_SA successful
      

      And the Cisco logs:

        type: 5, reserved: 0x0, id: Don't use ESN
      (11244):  N(11244):   Next payload: TSi, reserved: 0x0, length: 68
      (11244): 
      (11244):      5a 5a 9f ab ee 4e 57 ff 06 e8 c2 47 bf 21 9c d1
      (11244):      cd aa 5f 95 4d e4 cd 58 b9 de 98 4e ed 55 be e1
      (11244):      b4 8e 64 02 b6 70 cc b5 2f d3 66 5e 1b 25 0a 57
      (11244):      3e 97 b1 4d a5 e9 11 06 ec cd 8c b4 bc 78 83 e4
      (11244):  TSi(11244):   Next payload: TSr, reserved: 0x0, length: 40
      (11244):     Num of TSs: 2, reserved 0x0, reserved 0x0
      (11244):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
      (11244):     start port: 0, end port: 65535
      (11244):     start addr: 10.208.6.31, end addr: 10.208.6.31
      (11244):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
      (11244):     start port: 0, end port: 65535
      (11244):     start addr: 10.208.6.0, end addr: 10.208.6.255
      (11244):  TSr(11244):   Next payload: NONE, reserved: 0x0, length: 40
      (11244):     Num of TSs: 2, reserved 0x0, reserved 0x0
      (11244):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
      (11244):     start port: 0, end port: 65535
      (11244):     start addr: 10.101.100.2, end addr: 10.101.100.2
      (11244):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
      (11244):     start port: 0, end port: 65535
      (11244):     start addr: 10.101.100.0, end addr: 10.101.100.7
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 00000001 CurState: CHILD_I_IPSEC Event: EV_ENCRYPT_MSG
      IKEv2-PLAT-4: (11244): Encrypt success status returned via ipc 1
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 00000001 CurState: CHILD_I_IPSEC Event: EV_NO_EVENT
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 00000001 CurState: CHILD_I_IPSEC Event: EV_OK_ENCRYPT_RESP
      IKEv2-PROTO-7: (11244): Action: Action_Null
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 00000001 CurState: CHILD_I_IPSEC Event: EV_TRYSEND
      IKEv2-PROTO-4: (11244): Checking if request will fit in peer window
      (11244):  
      IKEv2-PROTO-4: (11244): Sending Packet [To x.x.x.x:500/From y.y.y.y:500/VRF i0:f0] 
      (11244): Initiator SPI : FE8199F3A245DDF1 - Responder SPI : 704ED400D63DC938 Message id: 225
      (11244): IKEv2 CREATE_CHILD_SA Exchange REQUESTIKEv2-PROTO-5: (11244): Next payload: ENCR, version: 2.0 (11244): Exchange type: CREATE_CHILD_SA, flags: RESPONDER (11244): Message id: 225, length: 288(11244):  
      Payload contents: 
      (11244):  ENCR(11244):   Next payload: SA, reserved: 0x0, length: 260
      (11244): Encrypted data: 256 bytes
      (11244):  
      IKEv2-PLAT-5: (11244): SENT PKT [CREATE_CHILD_SA] [y.y.y.y]:500->[x.x.x.x]:500 InitSPI=0xfe8199f3a245ddf1 RespSPI=0x704ed400d63dc938 MID=000000e1
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: CHILD_I_WAIT Event: EV_NO_EVENT
      (11244):  
      IKEv2-PROTO-4: (11244): Received Packet [From x.x.x.x:500/To y.y.y.y:500/VRF i0:f0] 
      (11244): Initiator SPI : FE8199F3A245DDF1 - Responder SPI : 704ED400D63DC938 Message id: 225
      (11244): IKEv2 CREATE_CHILD_SA Exchange RESPONSEIKEv2-PROTO-5: (11244): Next payload: ENCR, version: 2.0 (11244): Exchange type: CREATE_CHILD_SA, flags: INITIATOR MSG-RESPONSE (11244): Message id: 225, length: 96(11244):  
      Payload contents: 
      IKEv2-PLAT-4: (11244): Decrypt success status returned via ipc 1
      (11244):  
      (11244): Decrypted packet:(11244): Data: 96 bytes
      (11244): REAL Decrypted packet:(11244): Data: 8 bytes
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: CHILD_I_WAIT Event: EV_RECV_CREATE_CHILD
      IKEv2-PROTO-7: (11244): Action: Action_Null
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: CHILD_I_PROC Event: EV_CHK4_NOTIFY
      IKEv2-PROTO-4: (11244): Processing any notify-messages in child SA exchange
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: CHILD_I_DONE Event: EV_FAIL
      IKEv2-PROTO-2: (11244): Create child exchange failed
      IKEv2-PROTO-4: (11244): IPSec SA create failed
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: EXIT Event: EV_ABORT
      IKEv2-PROTO-7: (11244): Processed response with message id 225, Requests can be sent from range 226 to 226
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: EXIT Event: EV_CHK_PENDING_ABORT
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: EXIT Event: EV_UPDATE_CAC_STATS
      IKEv2-PROTO-4: (11244): Abort exchange
      IKEv2-PROTO-7: (11244): Deleting negotiation context for my message ID: 0xe1
      IKEv2-PROTO-7: (11244): SM Trace-> SA: I_SPI=FE8199F3A245DDF1 R_SPI=704ED400D63DC938 (I) MsgID = 000000E1 CurState: EXIT Event: EV_FREE_NEG
      IKEv2-PROTO-7: (11244): Deleting negotiation context for my message ID: 0xe
      

      I am thinking that the issue is the traffic selectors here:

      10.101.100.2/32|/0 10.101.100.0/29|/0 === 10.208.6.31/32|/0 10.208.6.0/24|/0
      

      10.208.6.31/32 is the initiating IP and 10.101.100.2/32 is the target IP in the negotiation.
      They have showed us their config and confirmed that only the /29 and /24 subnets are in their phase 2 config, so I am not really sure why the initiating IPs are coming across in the traffic selectors.
      I am guessing that the Cisco side should only be sending:

      10.101.100.0/29|/0 === 10.208.6.0/24|/0
      

      Can anyone confirm that this is the issue? Does anyone know how to fix this issue either in pfSense or Cisco configs?

      Please let me know if you need any more information and I will add it here. Thank you!

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.