I think I'm hitting the same issue in 2.6.0-RELEASE I have a working VTI IPv4 routing scenario linking two LANs and wanted to add ipv6 I added a second P2 on both pfsenses nodes configured as follow : On node A : local fd87:dcb9:c321:6610::01/126 remote fd87:dcb9:c321:6610::02 On node B : local fd87:dcb9:c321:6610::02/126 remote fd87:dcb9:c321:6610::01 The ipv6 tunnel come up successfully, however gateways are not defined correctly : In dashboard/gateway widget for OPT1_VTIV6 : ipv6 is displayed as ~, RTT pending, status Unknown In system_gateways.php, a gateway named OPT1_VTIV6 appears but stays empty with no ipv6 nor monitor ip. Interfaces are configured correctly : Node A : inet6 fd87:dcb9:c321:6610::1 prefixlen 126 Node B : inet6 fd87:dcb9:c321:6610::2 prefixlen 126 I'm however able to ping both sides of the vti tunnel If I add a static route from my lans to OPT1_VTIV6, boths lans can ping themself However, netstat -rn for the static route shows : 2001:41c9:1111:d2d::/64 ipsec1 US ipsec1 Which confirms the lan is routed directly to the interface and not to the ipv6 vti tunnel like it is done for ipv4 If I add a manual gateway 'test' (on node B for example) on interface OPT1 with ip fd87:dcb9:c321:6610::01 -> the dashboard displays this gateway correctly I can then define my static route on this 'test' gateway Now netstat -rn shows this for the static route : 2001:41c9:1111:d2d::/64 fd87:dcb9:c321:6610::1 UGS ipsec1 (same behaviour as with ipv4 vti) Traffic is passing correctly in both scenarios, however it does not feel normal to have a route directly to the interface in this case. I tried to set P2 local ip to single address (fd87:dcb9:c321:6610::01) or wider range fd87:dcb9:c321:6610::01/64) with no more success If I disable gateway monitoring : no changes If I force a monitoring IP, the gateway is shown as 'Online' but still with empty ipv6 Any clue on fixing this ? Or to disable automatic gateway creation ?

@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]