IPsec interfaces don't support reply-to yet, so it's not possible to send traffic back down a different tunnel than the one it entered.

Which network you use in p2 for your clients? Local Network have to be 192.168.0.0/19, to route the trafic to all local Networks throu the tunnel. I want to route all trafic throu my tunne, i use 0.0.0.0/0 and no split tunneling option on the clients. If you route only this network, you have do set split tunneling with the right Network + Mask on client side.

Unfortunately, per-interface rules do not currently function for VTI interfaces. It's a limitation in the underlying OS (either in if_ipsec, pf, or some combination of the two). Communication from a subnet like that wouldn't necessarily succeed anyhow, though, because your return routing wouldn't send it back to the "wrong" tunnel. In your example, if "Prefix A" came in from "Site-Tunnel 2" the reply traffic would go back to whichever one had the route on it, likely "Site-Tunnel 1". If you are using a routing protocol (BGP, OSPF) you could filter routes that way as well.

A bit more info, and a question: Based on another topic where traffic was not flowing, I have disabled these params in IPSEC : Advanced Auto-exclude LAN address Asynch Crypto My question... Unlike each of my OpenVPN tunnels on pfSense, I don't see IPSEC tunnel creating an interface to be activated in Interface::Assignments. There is an IPSEC interface, and I have enabled it and given it a pass all all all rule in Firewall. But there is not another specific to the tunnel I configured. Does the tunnel not need an interface? If it does, what am I missing to enable it and to give it a Firewall rule to permit IP?

AES-GCM is the only exception to the way the drop-down works.

The traffic would have to hit a proxy on pfSense1 for that to work. The problem is that anything on pfSense2 will need to see a source address of pfSense1 or the traffic won't return to pfSense1. So you could have haproxy on pfSense1 accept and hand off the requests to the second reverse proxy. If you were using OpenVPN then it's possible to port forward directly across, since OpenVPN will work properly with reply-to if you make the right set of rules on assigned interfaces. That doesn't work with IPsec VTI yet.

@viktor_g Any other suggestions?

It's not suitable for me, because IPSEC failover using Dynamic DNS and multi WAN doesn't work properly (with WAN failure it need some time to resolve new IP, and when WAN is UP DynDNS is not refresh so fast, but IPSec is using wrong WAN gateway and didn't connect till DynDNS new IP refresh). I want to make load balancing with IPSec VTI gateways (without connection drops) on pfSense side, so - both connections must be UP all time. and when one connection is fails - another stay UP without any connection drops for tunneled networks. But, as i see, it isn't standard situation for pfSense IPSec - when 1 WAN Server is using for 2 WAN's Servers.

@hdservices said in KeyID tag issue since 2.4.5: May 6 07:58:47 charon 08[CFG] <290> candidate "bypasslan", match: 1/1/24 (me/other/ike) May 6 07:58:47 charon 08[CFG] <290> looking for pre-shared key peer configs matching x.x.x.x...x.x.x.x[192.168.1.60] May 6 07:58:47 charon 08[ENC] <290> parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] May 6 07:58:47 charon 08[NET] <290> received packet: from x.x.x.x[4500] to x.x.x.x[4500] (108 bytes) May 6 07:58:47 charon 08[NET] <290> sending packet: from x.x.x.x[500] to x.x.x.x[500] (396 bytes) May 6 07:58:47 charon 08[ENC] <290> generating ID_PROT response 0 [ KE No NAT-D NAT-D ] May 6 07:58:47 charon 08[CFG] <290> candidate "con1000", match: 1/1/3100 (me/other/ike) May 6 07:58:47 charon 08[CFG] <290> candidate "bypasslan", match: 1/1/24 (me/other/ike) It's selecting bypasslan which means the P1 info didn't match. Either you didn't match up the ID (Looks like the remote is sending 192.168.1.60 as its ID) or the Pre-Shared key for 192.168.1.60 could not be found.

Phase 1: IKEv1 IPv4 PSK Aggressiv Distinguished name Distinguished name PSK Generate by pfSense AES 256 SHA512 DH2 DPD on Phase 2: IPv4 NAT None ESP AES 236 SHA1 PFS Key Group 2 Lifetime 3600 However, a new Netgate has been ordered and replace the Fritz shortly.

Great that it is working now as it should be. And my respect that you stayed on this till you solved it and posted the solution here.

here also, earlier here on the forum, @groupers made recommendations, you can also stick to them [https://forum.netgate.com/topic/150670/safe-ikev2-configuration-for-pfsense-and-windows-10-and-macos](link url) although they contradict what I wrote above, (deleting the registry key, and setting up the algorithms through the powershell) the essence is the same = setting the same parameters both on the pfsense and on Windows

pfSense doesn't support that role currently for a couple reasons: It does not support acting as an EAP client (Or any remote access style IPsec client) It does not support accepting parameters pushed by the IPsec server (e.g. dynamic addressing, DNS, etc) And a few other related reasons but they boil down to the two above.