Navigation

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

    Packets Not Being Decrypted ("could not decrypt payloads")

    IPsec
    2
    5
    4045
    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.
    • D
      digiPixel last edited by

      Attempting to setup a site to site VPN using IPSec and pfSense. Been getting the could not decrypt payload errors every time a packet is received successfully between the 2 VPN sites. This error has appeared out of the blue. Using the latest stable version of pfSense. Below is the relevant contents of the IPSec log:

      charon: 16[NET] <61> sending packet: from xxx.xxx.xxx.xxx[500] to xxx.xxx.xxx.xxx[500] (396 bytes)
      charon: 16[NET] <61> received packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[4500] (92 bytes)
      charon: 16[ENC] <61> invalid ID_V1 payload length, decryption failed?
      charon: 16[ENC] <61> could not decrypt payloads
      charon: 16[IKE] <61> message parsing failed

      1 Reply Last reply Reply Quote 0
      • C
        cmb last edited by

        The "invalid ID_V1 payload length, decryption failed" part is typical of a mismatched pre-shared key, though that's not the only possible cause.

        The fact you're sending on UDP 500, and receiving on 4500 (NAT-T) indicates some kind of problem as well, unless there are two different devices coming from the same IP (assuming those IPs it's showing are the same pair on the first two lines), like a site to site on the firewall and a mobile client on the LAN.

        1 Reply Last reply Reply Quote 0
        • D
          digiPixel last edited by

          Can safely rule out mismatched PSKs. Did get completely different error messages in the IPSec log that clearly pointed to mismatched PSKs, however that issue was resolved.

          How is it possible for a packet to be sent via port 500 yet is received through a different port on 4500?

          1 Reply Last reply Reply Quote 0
          • C
            cmb last edited by

            @digiPixel:

            How is it possible for a packet to be sent via port 500 yet is received through a different port on 4500?

            It's not (short of some weird port translation in between that's almost certainly not happening).

            Either it's two different systems (probably most likely), or one side somehow thinks it's NAT-T and the other doesn't. Not enough log context there to tell.

            1 Reply Last reply Reply Quote 0
            • D
              digiPixel last edited by

              Will be going back to the drawing board. Looking at having the following VirtualBox VMs running on a single PC (via a single NIC):

              • VPN Server 1 - Bridged Networking interface, Internal Network interface (site1)

              • VPN Client 1 - Internal Network interface (site1)

              • VPN Server 2 - Bridged Networking interface, Internal Network interface (site2)

              • VPN Client 2 - Internal Network interface (site2)

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

              Products

              • Platform Overview
              • TNSR
              • pfSense
              • Appliances

              Services

              • Training
              • Professional Services

              Support

              • Subscription Plans
              • Contact Support
              • Product Lifecycle
              • Documentation

              News

              • Media Coverage
              • Press
              • Events

              Resources

              • Blog
              • FAQ
              • Find a Partner
              • Resource Library
              • Security Information

              Company

              • About Us
              • Careers
              • Partners
              • Contact Us
              • Legal
              Our Mission

              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

              Subscribe to our Newsletter

              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

              © 2021 Rubicon Communications, LLC | Privacy Policy