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

    IPsec one client connects, other does not

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 478 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.
    • A
      AudioDave
      last edited by

      I worked through some issues with Phase 1 & 2 that was preventing my phone from connecting via IPsec.

      When then attempting to connect iPad, I had to repeat this to find Phase 1 & 2 that would get both clients through authorization.

      However, I still cannot get a completion on the iPad. I'm not sure what's going on, but it appears that there are possibly issues with the IKE_AUTH response getting fragmented into 2 messages. Any help resolving this would be appreciated.

      ec32665f-2cb3-4a62-a0dc-7fa3ba293e36-image.png

      Note: While I don't think this is an issue, for the iPad I am first connecting to the mobile hotspot on the phone so that the iPad WIFI is not on my local network. It is certainly possible that the hotspot is causing the fragmentation. I will try a different WIFI at some point to eliminate this potential problem.

      Current Phase 1:

      e96b9adb-2f0e-414f-b42f-7b5057fd21bf-image.png

      Current Phase 2:

      609149e6-2956-4e45-b8dd-6e98ca6c5c02-image.png

      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @AudioDave
        last edited by Konstanti

        @AudioDave

        Hi
        Message fragmentation usually occurs when RSA certificate data is transmitted (the size of this data is larger than the standard packet size of 1500 bytes) It is possible that your device does not work with fragmented packets
        a3a2264f-fce8-4d95-a40a-8aa024708712-image.png
        I would suggest the following
        1 use ECDSA certificate instead of RSA

        ECDSA XXXXXX.ORG
        CA: No
        Server: No
        ECDSA ROOT CERT O=Mxxxx, CN=strongswan.xxxxx.org, C=XXX
        Valid From: Tue, 16 Jan 2018 20:21:12 +0300
        Valid Until: Fri, 15 Jan 2021 20:21:12 +0300

        Serial: 3785148995795911198
        Signature Digest: ecdsa-with-SHA384
        SAN: DNS:pfsense.xxxxxx.org

        Connection example (ECDSA) , Iphone-> PFSense (packet size 720 bytes instead 1358 bytes without fragmentation)

        Jan 10 13:17:58	charon		15[IKE] <con-mobile|398> sending end entity cert "C=xxx, O=XXXX, CN=xx.XXXXX.org"
        Jan 10 13:17:58	charon		15[ENC] <con-mobile|398> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
        Jan 10 13:17:58	charon		15[NET] <con-mobile|398> sending packet: from XX.XXX.XXX.141[4500] to XXX.XXX.XXX.119[52837] **(720 bytes)**
        Jan 10 13:17:58	charon		15[NET] <con-mobile|398> received packet: from xxx.xxx.xxxx.119[52837] to xxx.xxxx.xxx.141[4500] (112 bytes)
        

        2 use a SHARED SECRET instead of a certificate

        3 try to create a VPN profile in the Apple Configurator program and upload it to your device

        A 1 Reply Last reply Reply Quote 0
        • A
          AudioDave @Konstanti
          last edited by

          @Konstanti

          Thanks! I will take a look at this. The problem is that I don't know for sure that this is the problem. I would hate to go through regeneration and deployment of new certificates and STILL have the issue.

          I've managed to get everything (HTTPS/IPsec) working, except for the iPad. I'm guessing that the fragmentation is the issue since it's the last thing I see before destroying the connection.

          It's not urgent that I get this working on the iPad since I do have a working IPsec on my phone. It would be rare I'm travelling with the iPad and NOT also have my phone available.

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