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

    Sonicwall IKEv2 Payload processing errors

    Scheduled Pinned Locked Moved
    IPsec
    3
    7
    4.0k
    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.
    • C
      cjpanici
      last edited by

      Hello, I am trying to create a site-to-site VPN connection between a sonicwall TZ470 running firmware 7.0.1-5030-R2007 and a pfSense router (2.6.0-RELEASE). I am managing the pfSense side, and I am working with a different group on the sonicwall side. It seems no matter what we select and try to match, we keep getting IKEv2 payload processing errors. Also, the sonicwall guy said there were phase not found errors as we were configuring. Me and the sonicwall guy shared screens to verify that everything matches.

      He's putting in a ticket with SonicWall, but he said they will most likely point the finger at pfSense and say that it just doesn't work with the software. Has anyone gotten this to work with this sonicwall router?

      Thanks in advance,
      CJ

      C 1 Reply Last reply Reply Quote 0
      • C
        cjpanici @cjpanici
        last edited by

        @cjpanici
        Here are the relevant logs:

        Feb 28 15:35:04 	charon 	22116 	15[KNL] creating acquire job for policy 66.66.66.66/32|/0 === 66.66.66.67/32|/0 with reqid {1}
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_VENDOR task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_INIT task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_NATD task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_CERT_PRE task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_AUTH task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_CERT_POST task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_CONFIG task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing IKE_AUTH_LIFETIME task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> queueing CHILD_CREATE task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating new tasks
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_VENDOR task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_INIT task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_NATD task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_CERT_PRE task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_AUTH task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_CERT_POST task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_CONFIG task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating CHILD_CREATE task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> activating IKE_AUTH_LIFETIME task
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> initiating IKE_SA con1[137] to 66.66.66.67
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> IKE_SA con1[137] state change: CREATED => CONNECTING
Feb 28 15:35:04 	charon 	22116 	07[CFG] <con1|137> configured proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Feb 28 15:35:04 	charon 	22116 	07[CFG] <con1|137> sending supported signature hash algorithms: sha256 sha384 sha512 identity
Feb 28 15:35:04 	charon 	22116 	07[ENC] <con1|137> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Feb 28 15:35:04 	charon 	22116 	07[NET] <con1|137> sending packet: from 66.66.66.66[500] to 66.66.66.67[500] (332 bytes)
Feb 28 15:35:04 	charon 	22116 	07[NET] <con1|137> received packet: from 66.66.66.67[500] to 66.66.66.66[500] (36 bytes)
Feb 28 15:35:04 	charon 	22116 	07[ENC] <con1|137> parsed IKE_SA_INIT response 0 [ N(INVAL_SYN) ]
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> received INVALID_SYNTAX notify error
Feb 28 15:35:04 	charon 	22116 	07[IKE] <con1|137> IKE_SA con1[137] state change: CONNECTING => DESTROYING
        1 Reply Last reply Reply Quote 0
        • C
          ctyokley
          last edited by

          I'm having a similar situation. Did you ever figure it out? its still the 7.0.1 version, but a later release.

          C 1 Reply Last reply Reply Quote 0
          • C
            ctyokley @ctyokley
            last edited by

            @ctyokley said in Sonicwall IKEv2 Payload processing errors:

            I'm having a similar situation. Did you ever figure it out? its still the 7.0.1 version, but a later release.

            I think i acutally figured out the issue... and you are right.. they were starting to point fingers at netgate/pfsense....

            Basically If you enable PFS key group on pfsense p2, you need to enable it on the the sonicwall.. It isn't called PFS in short in sonicwallos. It has it as the full name (spelled out)... "Enable Perfect Forward Secrecy"... Once enabled, and the Group is selected to what it is on the pfSense side, the tunnel was up and remained up.

            M 1 Reply Last reply Reply Quote 0
            • M
              michmoor LAYER 8 Rebel Alliance @ctyokley
              last edited by

              @ctyokley
              This seems like a very classic case of both sides not matching on parameters. Number 1 reason why IPsec fails to come up.

              Firewall: NetGate,Palo Alto-VM,Juniper SRX
              Routing: Juniper, Arista, Cisco
              Switching: Juniper, Arista, Cisco
              Wireless: Unifi, Aruba IAP
              JNCIP,CCNP Enterprise

              C 1 Reply Last reply Reply Quote 0
              • C
                ctyokley @michmoor
                last edited by

                @michmoor Would agree! Typically this is the case... but this was an incredibly odd error I had... The P1 and P2 would initiate the first time around. Where the error occurred is when it went to rekey the P2 due to the Life being set at defualt 3600. Once the life expired, it failed to create the new tunnel thus dropping the packets. Initially turned it off on PFsense and noticed it continually to respond after the rekey. Set it back to DH14 for PFS and it corrected the issue. What was odd is with the PFS being set on one side and not the other... it created the tunnel for the P2.. .not sure how...

                M 1 Reply Last reply Reply Quote 0
                • M
                  michmoor LAYER 8 Rebel Alliance @ctyokley
                  last edited by

                  @ctyokley
                  I’ve seen something like that happen. Phase 2 pfs negotiations succeed until it’s time to rekey. But not ok pfsense. Probably thinking of an ASA maybe

                  Firewall: NetGate,Palo Alto-VM,Juniper SRX
                  Routing: Juniper, Arista, Cisco
                  Switching: Juniper, Arista, Cisco
                  Wireless: Unifi, Aruba IAP
                  JNCIP,CCNP Enterprise

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post