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.

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

This is for customer VPN access not site to site. Client will come in from any IP. How can I tag customer1 to see only their customer1_servers and customer2 only their customer2_servers?

Yes, HA will figure out how to route, all you need is to use VIP as interface instead or WAN.

This shouldn't be an issue with OSPF/FRR. I'm having this issue prior to even installing FRR. The tunnel being up generates traffic that should be showing.

opened https://redmine.pfsense.org/issues/10745 so that we know when this gets applied to pfsense and when we can go back to IPSec.

Glad I could be helping you :)

@CodeNinja said in How to setup a second local network for an IPSec connection?: I'm also curious if its preferred/best practice to use "supernet" or this "multiple tunnel" construction like i currently do. In many bigger scenarios, I see "supernets" or bigger CIDR masks to simplify tunnel deployments. Especially in centralized structures with one or two "main" sites with big uplinks and many small/branch offices network design often tends to do sth. along these lines: Roll out big network structure on main(1) -> e.g. multiple 172.19.x.0/24 networks for security segmentation Dial Up / RAS VPN uses IP ranges either from an upper 172.19.x segment or another IP range altogether (e.g. 192.168.vvv.0/24) Branch offices use separate range -> e.g. 10.10.bbb.0/24 for office 1, 10.20.bbb.0/24 for office 2 (or 10.11.bbb.0 if you have a whole lot of branch offices). With that setup, you can easily do tunnels from "main" to "site a" with <172.19.0.0/16> <-> <10.10.0.0/16> and have no problem whatsoever to grow in either space. If you have the need for new networks on site or on in the main location - just add another VLAN with /24 and as your tunnel is set up with /16 it already includes the new networks. So yeah, pretty common to use CIDR ranges bigger than your local network to add some "space to grow" lateron. I also noticed this morning that one of the connection had 8 tunnels where i expected only 4. 5 are duplicates from eachother and 1 is missing.. That seems strange. A duplicate can (and will) happen at times, when rekeying gets near and the lifetime is about to expire. Then it's pretty normal to sometimes see every phase with a second entry as the old one gets "disabled" (but not disconnected) and the new one takes over so the rekey/lifetime turnaround goes smooth. You then see new traffic accumulate on the newer P2 and the old one won't get any more and after expiry should vanish a few seconds/minutes later. But having the same phase 5 times is strange. And some were brought up only seconds after another. Weird. I'd disconnect the whole bunch and reestablish the tunnel and check if that happens again. Perhaps something with the edgerouter on the other site? Maybe setting the split option in P1 of the connection could help if pfsense tries to group the connection but the edgerouter doesn't support it (fully) - but that's just a guess.

Added more details in the commands: Didn't add any "sel" option in the state command but by default "sel src ::/0 dst ::/0". Can anyone please help me to understand. IPSEC : ip -6 xfrm command for STATE ip -6 xfrm state add src fe78::290:bff:fe59:ffa dst ff02::5 proto esp spi 256 mode transport auth sha256 Test enc cipher_null list of added states: ip -6 xfrm state list src fe78::290:bff:fe59:fffa dst ff02::5 proto esp spi 0x00000100 reqid 0 mode transport replay-window 0 auth-trunc hmac(sha256) 0x54657374 96 enc ecb(cipher_null) 0x sel src ::/0 dst ::/0 -thanks,

To close the issue, I found that I had a client-specific override that I have no recollection of creating which set the 'IPv4 remote networks' for the OpenVPN client in site A. Adding the IPSEC subnet to it made everything work. Hope that helps somebody else.