@nocling said in AES-CGM and stalling IPSec: Yes, with 22.01 my 2100 hangs up some times a day before i can find out what happened. I reproduce it and so we got the Bug Report after a other 2100 are affected to. Yeah I saw your posts on the issue, but you could see the mbuf_clusters grow in diagnostics. The mbuf_clusters graph shows no changes when I’m suffering my issue.

@lralvarez Perhaps you are suffering the same issue as I was? https://forum.netgate.com/topic/174562/aes-cgm-and-stalling-ipsec

@volans As I understand it the Endpoints play no role in the routing being established. You need an internal thing one Network A to ping an internal thing on Network B to get it to connect, if pinging is allowed.

@nocling said in Trouble setting up Client IPsec VPN: Win 10 can use AES GCM 128, SHA 256 and DH19/ECP256, no need for crepey DH Settings. 2 Lines Powershell: Add-VPNConnection -AllUserConnection -Name "RW-VPN" -ServerAddress "Dyndns" -TunnelType "Ikev2" -AuthenticationMethod Eap -RememberCredential Set-VpnConnectionIPsecConfiguration -ConnectionName "RW-VPN" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -PassThru But you need the private FW Root CA or a public trust CA on the pfSense. Yes, I know, that’s why I use powershell to create the VPN on the clients. But the OP has no options to touch/install/script anything on the clients, so I guess he has to make do with a user GUI “next - next -next” guide, and then you have to settle with what windows tries to autonegotiate.

@keyser i found the issue after changing the Phase1 settings. The CA import from wasn't successful. After reimport... all works fine... THX for your time and support... Stefan

We figured it out thus I will be posting our solution here in case anyone finds the same issue in the future. Basically once the DoT option is enabled unbound changes behavoir because of the way is implemented in pfSense software. See: https://redmine.pfsense.org/issues/13393 To make sure enabling DoT works, you should choose specific network interface(s) to which the DNS Resolver will bind when listening for queries from clients and not listening on ALL interfaces, i.e DNS Resolver > Network Interfaces > ALL , which is the default option for pfSense. In short changing our DNS Resolver's listening interfaces from ALL to just the LAN, DMZ and localhost solved the issue. Hope this helps, Alejandro

I'm not an IPSEC expert, never actually used it. In your log I could see any 'cert' related errors. Only this one : @thewaterbug said in Mobile User VPN failed w/Cert Expired; New Cert doesn't fix: Aug 15 15:15:36 charon 07[IKE] <93> DH group MODP_2048 inacceptable, requesting MODP_1024 Who/what is charon ?

@bp81 I solved my own problem, and wanted to record the answer in case others have similar. First, my initial assessment that the IP address of a Neighbor entry had to match the Router ID that was set on that neighbor's BGP service was wrong. It didn't work for me initially because I had some other things set wrong. Here's how it's now working: I setup the IPSEC connection between Hub and Branch 1 as described above. The transit network for this link is 172.16.0.0/30. Hub gets 172.16.0.1, Branch 1 get 172.16.0.2. The connection between Hub and Branch 2 is similar. The transit network is set to 172.16.0.4/30. Hub gets 172.16.0.5, Branch 2 gets 172.16.0.6. The router ID for all routers is set to the LAN IP address in BGP, NOT the transit network IP address. Each Neighbor entry specifies the transit network IP. Ergo, Hub 1 has neigbor entries that specify 172.16.0.2 (Branch 1) and 172.16.0.6 (Branch 2). The last setting, and this turned out to be the trick that made it work, is in the Neighbor settings in the Next Hop section. Took me a bit to find and identify this as the solution to my 'chicken and the egg' problem in my OP. In the Next Hop action, I set Next Hop Action to "Set (Peer Only)" and I set Peer to "Peer Address (set only)". This setting is what got things going as expected. [image: 1661348288482-7c08b0b6-27b0-4f6b-9303-d428db2ab2be-image.png]

@keyser Oof. Sounds like I'm in unsupported configuration territory here. I'll see how it performs in a lab.

@bbrendon said in IPSEC + VTI + IKEV2 - will not auto-reconnect: Hi @jimp . Regarding the "Keep Alive - Enable periodic keep alive check" option, should that be enabled on both sides or just the side initiating the connection? Usually just the side initiating