@vvasilev said in No Route to Virtual Pool:

No, I didn't mean routed IPSec.

Nice...
Many times a full "states" killing is enough

Play around with TCP MSS clamping. Start with a relatively safe, low value like 1350. If you use VTI, check your MTUs aswell.

as jimp wrote, set your tunnel to the following modes:

Side 1: IKEv2, Rekey configured, Reauth disabled, child SA close action set to restart/reconnect
Side 2: IKEv2, Rekey configured, Reauth disabled, responder only set, child SA close action left at default (clear)

See also:

https://redmine.pfsense.org/issues/10176

@Stewart

Well, I guess 100.64.0.0/10 isn't public after all. You learn something new every day! What's odd is that adding the appropriate firewall rule allowed the traffic to cross but I don't see anything logged in the firewall logs to show that the firewall is what stopped the communication.

@Stefan-Cplanet said in Issues routing 2 LAN's through VPN Tunel:

10.5.0.5 towards 192.168.88.1 ( packets go to) 10.5.0.2 ( router) and then 127.0.0.1 after which they go onto public IP's before getting lost, so actually its trying to route it through WAN and not IPSec?

On the left pfSense?
You may see the packets on WAN interface.

So pfSense is presumably missing the route, though the IPSec phase 2 is set correctly.
You may check the route in Diagnostic > Routes, however I can't give more help here, since everything seems to be configured as it should be.

I'd set up an OpenVPN site-to-site instead, that's more reliable regarding routing.

Sorted it.

On line 96 of /etc/inc/ipsec.auth-user.php it reads:

$userGroups = getUserGroups($username, $authcfg, array());

Where it should read:

$userGroups = getUserGroups($username, $authcfg, $attributes = array());

To abide by PHP referenced variable.

I just happened to be on the pfsense forum today so I thought I should follow up on this post. I did in fact configure an addition device at each of our locations as a VPN gateway and put it upstream of the local firewall/router and it's an excellent solution for our scenario. Although there was some added cost for the additional hardware it really wasn't that much (we are using PCEngine APU4s for the VPN gateways). We were also replacing some existing Meraki equipment so dropping the licensing for that will more that cover the added hardware cost for the APU4s. Thanks again Derelict for your great advice!

Not enough info to say. Need a lot more details about your setup.

It's perfectly normal for mobile IPsec not to have a remote network setup (in P1 or P2) since the P1 peer could be anyone, it determines keys by identifier and so on. And P2 remote is setup dynamically using the setting from the mobile clients tab.

Check your setup against the documentation and look for what you have wrong. Coming from a version as old as you had, it switched from racoon to strongSwan so odds are high that whatever you had setup before probably wasn't 100% right.

If your clients support it, you should move up to an IKEv2 setup.

@SenseiNYC

ipsec down <name> tells the IKE daemon to terminate connection <name>. Implemented by calling the ipsec stroke down <name> command. ipsec down <name>{n} terminates CHILD_SA instance n of connection <name>. Since {n} uniquely identifis a CHILD_SA the name is optional. ipsec down <name>{*} terminates all CHILD_SA instances of connection <name>. ipsec down <name>[n] terminates IKE_SA instance n of connection <name> plus dependent CHILD_SAs. Since [n] uniquely identifis an IKE_SA the name is optional. ipsec down <name>[*] terminates all IKE_SA instances of connection <name>.

or

[2.4.4-RELEASE][admin@pfSense.localdomain]/root: swanctl --terminate --help strongSwan 5.7.1 swanctl usage: swanctl --terminate --child <name> | --ike <name | --child-id <id> | --ike-id <id> [--timeout <s>] [--raw|--pretty] --help (-h) show usage information --child (-c) terminate by CHILD_SA name --ike (-i) terminate by IKE_SA name --child-id (-C) terminate by CHILD_SA reqid --ike-id (-I) terminate by IKE_SA unique identifier