RADIUS-EAP with IPSec remote access VPN issues after Pfsense+ upgrade
-
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 unloadedContents 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
}
} -
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
-
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#1143557beb9ad8ca11703778fc483c7cba0f6770657ac#1143510eb04259fd139c62e08df8de877b71fdd0eedc8#11442ded7970ba57a99767e08243103e55d8a58edfc35#11486afffe759c4fd19fe6b8311196f4b6d5e288ea4fb#114872fe5cc52bd881ed26723a81e0eed848fd505fba6#11488
After that, edit/save/apply an IPsec tunnel, then stop and start (not restart) the IPsec daemon, or reboot instead.
-
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.
