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).

Screen Shot 2020-07-30 at 1.25.03 PM.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) : 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.

@joedoe47 said in IPSEC established but no tftp or UDP:

Pfsense is doing its job as it should. The issue is the primary gateway.

I believed it was not a pfSense issue
since I have been using TFTP for a long time to upgrade IT devices FWs

dual -NAT is never good, try to eliminate it if possible...
(as if we were wrapping the gift in two separate boxes (which we put on top of each other) at Christmas, more exciting but takes longer to obtain) 😉