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.

Issue has been resolved, it ended up being a bug within Ubiquity firmware causing weird routing issues with /31 routes (Single addresses)

My guess is that you setup a policy-based ipsec and not a route-based VTI ipsec. VTI=virtual tunnel interface, hence the interface shows up for those users. As for NAT, I recently read that it is now entered in the phase 2 page. The 3rd option down should be where you enter NAT. If you have further issues, post the p1/p2, static routes, and related firewall rules.

@Zawi said in Access from IPSec site to other IPSec site: Add p2 example: Office Greece <> Customer 1 Customer 1 <>Office Greece During configuring this, i noticed that this is not what we want as we need to setup a p2 for each costomer-greece office relation. Both, the customer and the greece office are already connected to our main office. We want to "route" the traffic from our greece office to our customer via our main office.

@scurrier I think I have the same issue. https://forum.netgate.com/topic/155727/site-to-site-ipsec-suspect-not-passing-tcp-traffic How did you make traceroute use a specific protocol?

if p1 is up, you need to create p2 to match the traffic for example Azure subnet<> client network

Here is a diagram of the network topology Home 2 you can think of as remote site with two networks. One network is site to site, while the other network should route all traffic to the HQ (Home 1). [image: 1596140726779-screen-shot-2020-07-30-at-1.25.03-pm-resized.png]

Still getting issues: https://pastebin.com/wpWqPEYZ

@moelharrak Hi, read Jimp's answer (L2TP): https://www.reddit.com/r/PFSENSE/comments/fkqwnb/pfsense_as_l2tp_client/

@ads76 I also think it's an external factor, like the Windows client but nothing in the Event viewer logs appart the connection setting up. I don't have another VPN no. It's a virtual lab built on an ESXi so I'd say it's wired-like. No I can't while it's up. pfSense logs only show this (as shown before) : [image: 1595585173169-851e0d78-6902-4387-8ef5-b0234e85e77d-image.png] When the tunnel is up I cannot access or ping anything outside the LAN where the client is and the WAN interface (192.168.101.40 - tunnel). We don't need to bother about the NAT gateway it's irrelevant sorry it's juste the default gateway of my pfsense to go outside of my lab.

Normally that would only happen when you are editing the Phase 2 of a Mobile IPsec entry. Not a site-to-site. The Remote Network field is not relevant to mobile IPsec.