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

    RADIUS-EAP with IPSec remote access VPN issues after Pfsense+ upgrade

    Scheduled Pinned Locked Moved IPsec
    4 Posts 1 Posters 788 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.
    • currentUsernameC
      currentUsername
      last edited by

      Hello people. As per the subject, after upgrading to the Pfsense + version the existing IPSec VPN started to have serious problems. I mean the problems that didn't happen before. Currently none of the remote users are able to synchronize data or even access the shares of the LAN in stable mode. Pfsense is configured as a RADIUS client with domain controller certificates. Authentication is based on the ActiveDirectory domain username. Phase 1 EAP-RAIUS ends quickly (as before), remote clients are authenticated without problems (as before). As long as the client does not perform any action, pings to the LAN servers and to the gateway (Pfsense) are performed. As soon as data is synchronized with the internal SQL Server, the pings stop with the message of the unreachable destination. The same thing happens while trying to change the settings (for example of Pfsense) there GUI interface from the browser. Network shares remain available for a few moments longer but even here ... not for long. Add to all this that the VPN connection from the Windows 10 client side is always on and has no error messages.
      What I did: restarted IPSec service, deleted and recreated the tunnel Phase1 - Phase 2, replaced Peer Identifier from "any" to "Peer IP address", restarted Pfsense. I need help.

      Shell Output - swanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1
      no authorities found, 0 unloaded
      loaded certificate from '/var/etc/ipsec/x509/cert-1.crt'
      loaded certificate from '/var/etc/ipsec/x509ca/92c33ddf.0'
      loaded RSA key from '/var/etc/ipsec/private/cert-1.key'
      loaded pool 'mobile-pool-v4'
      successfully loaded 1 pools, 0 unloaded
      loaded connection 'bypass'
      loaded connection 'con-mobile'
      successfully loaded 2 connections, 0 unloaded

      Contents of the swanctl file, I have replaced my public address with "X" for obvious reasons

      This file is automatically generated. Do not edit

      connections {
      bypass {
      remote_addrs = 127.0.0.1
      children {
      bypasslan {
      local_ts = 192.168.1.0/24
      remote_ts = 192.168.1.0/24
      mode = pass
      start_action = trap
      }
      }
      }
      con-mobile : con-mobile-defaults {
      # Stub to load con-mobile-defaults
      }
      }
      con-mobile-defaults {
      fragmentation = yes
      unique = replace
      version = 2
      proposals = aes256-sha256-modp1024
      dpd_delay = 10s
      dpd_timeout = 60s
      rekey_time = 25920s
      reauth_time = 0s
      over_time = 2880s
      rand_time = 2880s
      encap = no
      mobike = yes
      local_addrs = XX.XX.XX.X
      remote_addrs = 0.0.0.0/0,::/0
      pools = mobile-pool-v4
      send_cert = always
      local {
      id = fqdn:fw.hospice.local
      auth = pubkey
      cert {
      file = /var/etc/ipsec/x509/cert-1.crt
      }
      }
      remote {
      eap_id = %any
      auth = eap-radius
      }
      children {
      con-mobile {
      dpd_action = clear
      mode = tunnel
      policies = yes
      life_time = 3600s
      rekey_time = 3240s
      rand_time = 360s
      start_action = none
      local_ts = 192.168.1.0/24
      esp_proposals = aes256gcm128,aes256gcm96,aes256gcm64,aes192gcm128,aes192gcm96,aes192gcm64,aes128gcm128,aes128-sha1,aes128-sha256,aes128-sha384,aes128-sha512
      }
      }
      }
      pools {
      mobile-pool-v4 : mobile-pool {
      addrs = 192.168.10.0/24
      }
      }
      mobile-pool {
      dns = 192.168.1.7,192.168.1.8
      # Search domain and default domain
      28674 = "hospice.local"
      28675 = "192.168.1.7"
      }
      secrets {
      private-0 {
      file = /var/etc/ipsec/private/cert-1.key
      }
      }

      1 Reply Last reply Reply Quote 0
      • currentUsernameC
        currentUsername
        last edited by

        Here is a lot of work for the Wireshark. So far found the MTU errors that flood traffic, then set "Enable Maximum MSS" to a value of 1200 and then TLS in the LAN communication which is blocked by the native rule because it is in multicast, then added the "AllowIP option" option in the IPSec rule . A test client was able to stay alive and complete tasks. Anyway, I expect a patch more than the Covid vaccine 😳

        1 Reply Last reply Reply Quote 0
        • currentUsernameC
          currentUsername
          last edited by

          Can I say that after applying all these patches my problem seems to be solved? With a due and prudent optimism perhaps yes.
          @jimp said in After upgrading to 21.02 IPsec pfSense to SonicWall won't stay connected:

          When looking into all this, first apply all of the current IPsec changes:

          • ead6515637a34ce6e170e2d2b0802e4fa1e63a00 #11435
          • 57beb9ad8ca11703778fc483c7cba0f6770657ac #11435
          • 10eb04259fd139c62e08df8de877b71fdd0eedc8 #11442
          • ded7970ba57a99767e08243103e55d8a58edfc35 #11486
          • afffe759c4fd19fe6b8311196f4b6d5e288ea4fb #11487
          • 2fe5cc52bd881ed26723a81e0eed848fd505fba6 #11488

          After that, edit/save/apply an IPsec tunnel, then stop and start (not restart) the IPsec daemon, or reboot instead.

          1 Reply Last reply Reply Quote 1
          • currentUsernameC
            currentUsername
            last edited by

            I don't know why the VPN worked before the upgrade (sarcasm). The thing is, I added the rule in the target subnet (VPN assigns 162.168.10.0/24 for remote clients targeting in 192.168.1.0/24) to allow communication on ports 50, 51, 4500 and 1701 on 192.168 .1.0 / 24. This has definitely solved the problem.

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