@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

You would use separate P2 entries for each subnet. Though you could combine the 172.x.x.x as 172.16.0.0/14 which would cover both 172.17 and 172.18, so long as it doesn't conflict with anything else you are doing. Alternately, use routed IPsec then you don't need to worry about tunnel mode policies at all.

Haha so I stumbled over Seed4me because a friend gave me like 10 365 days promo codes. ;-) Thought it could be fun to use it with pfSense/policy route to bypass some geo blocking.... then I was surprised they don't offer OpenVPN or IPsec (WTF?!). They only do PPTP with 128-bit MPPE or L2TP/IPsec with pre-shared key. Seems like there is no way to do this with pfSense... -Rico

If it is really set like you say it should work without reply-to. Going to probably have to packet capture hop-by-hop to see where the connection request is going then where the reply traffic is going. The first place I would capture is at the 10.2.20.0/24 interface.

@Alitai THAT'S GREAT IT WORKED. I accualy added AES / 256 bits / SHA256 / 14 (2048 bit) to the current one. Thanks @Alitai

@jimp Oh I get it, not making any sense. I originally built the tunnel with one side as the initiator and the phase 1 and 2 lifetimes being unique. Not sure why, but the current setup was the only combination that made the tunnel work consistently.

Hello more details today. I find a workaround : First step, disable all P1 ipsec configuration on each firewall. Second step: changing the lifetime P1 to 1 year (31536000) Enable conf Site1-Site2 on hardware 1 Enable conf Site1-Site2 on hardware 2 Connection autostart OK. Enable conf Site1-Site3 on hardware 3 Disable conf Site1-Site2 on hardware 1 => not closing actual connection !! let it working even if you disable configuration Enable conf Site1-Site3 on hardware 1 Connection autostart OK. Enable conf Site1-Site2 on hardware 1 Now the 2 tunnels are ON on hardware 1 => made the same strategy on 2 others firewall , all tunnels working now ... not clean, but working since 20 hours now. Take care => if 1 connexion down, (manually or because "lifetime parameter", you have to make same step manually again) Analysis All my tests show me that version 2.4.5-1 (initial install 2.4.4-p2, upgraded 2.4.4p3 few months ago) isn't able to work with more than 1 tunnel. If you have more than 1 tunnel configuration enable on a firewall, pfsense can't establish the second tunnel : Hardware1 Site1-Site2 conf enable Site1-Site3 conf enable Hardware2 Site1-Site2 conf enable Site2-Site3 conf disable Hardware3 Site1-Site3 conf enable Site2-Site3 conf disable => in this case, hardware2 and 3 have only 1 tunnel enable, but as hardware1 has two, only 1 tunnel can be establish. as soon you have more than 1 tunnel configuration enable, system can't establish connection. The main idea is to disable conf from a tunnel already open, it allow pfsense to open second tunnel. => not very clean but working. I will try to send this bug to dev. Best regards

Hello, I have same case after upgrade on 3 firewall. Upgrade borke IPSEC multi tunnels. I have open an other discussion on this issue.