@ralph-1 Have you tried adding the VPN connection by hand on the Mac?

I think the issue is with the profile including a self signed cert, at least it was with my iPhone.

Down load and trust the CA and the additional cert first then add the connection by hand.

Actually I stand corrected. In the advanced setting for the Phase 1, there is a setting to allow multiple P1s.

Gateway Duplicates

Allows multiple phase 1 configurations to use the same remote endpoint address. Warning This option also disables automatic static routes to the peer via specific WAN gateways. Traffic will follow the default route, not the selected tunnel interface, unless manual static routes redirect the traffic.

You'd need to have that option enabled and set up static routes.

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.