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

    IPSec issues, no proposal chosen, packet loss

    Scheduled Pinned Locked Moved
    2.2 Snapshot Feedback and Problems - RETIRED
    2
    3
    4.1k
    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.
    • N
      nh5
      last edited by

      Hello,

      I'm encountering a few things with the latest 2.2 builds.

      1st, when choosing AES(anybit)-GCM on Phase 1, each side of the tunnel shows a incomplete proposal as received. I get the following in the logs,

      Oct 15 01:09:46 charon: 11[CFG] received proposals: IKE:HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      Oct 15 01:09:46 charon: 11[CFG] configured proposals: IKE:AES_GCM_16_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      Oct 15 01:09:46 charon: 11[IKE] <18> no proposal found
      Oct 15 01:09:46 charon: 11[IKE] no proposal found

      2nd, I'm having packet loss and ping time oddities under hyper-v. I've tried VMQ on and off and IPSec offloading on and off as well. But when the VPN really goes under a decent load, it starts to choke after a period of time, where ping times increase and eventually it leads to packet loss that ends a few minutes after the heavy traffic going over it stops. I've tried everything from falling back to 3DES for encrpytion and through every type of AES. I still seem to be hitting this issue. It seems that server response time drops on all interfaces as well including the WAN interface outside of the VPN and ping times are high there as well. I've tried to find evidence of high CPU load but can't as well. Where can I dig further on this?

      EDIT: looks like the CPU is getting beat up a bit on the receiving pfsense instance. I'm going to add another core and see if it assists. To note though, I'm seeing the packet loss issue on the source side of the large file transfer. Would it be typical for a single IPSec connection using P1 3DES and P2 AES256-GCM to be beating up the CPU so bad to where its affecting response to ping?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        AES-GCM is not supposed for phase1 without selecting a proper hash.

        I would recommend it only for phase2.

        It is there because of generic implementation but do not use it on phase1.

        1 Reply Last reply Reply Quote 0
        • N
          nh5
          last edited by

          @ermal:

          AES-GCM is not supposed for phase1 without selecting a proper hash.

          I would recommend it only for phase2.

          It is there because of generic implementation but do not use it on phase1.

          I kind of figured that but couldn't find any documentation on it. Thanks!

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