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.

I want a Tunnel that use PFS:
https://en.wikipedia.org/wiki/Forward_secrecy

Client VPN is incomming, nerver use for outgoing connections, to i set responder only.
For Outgoing i use Side 2 Side IKEv2.

Mobike is a nice feature, so I turned on this crazy shit.
At my point of view, Microsoft support it 7 and Apple up iOS 9 or newer this feature.
https://tools.ietf.org/html/rfc4555

How I've set mine up, I've got a single phase 2 setup with the local network of 10.0.0.0/16 as I have VLANs with IP ranges 10.0.100.0/24, 10.0.200/24, 10.0.201.0/24, 10.0.202.0/24. I haven't got the "provide list of accessible networks" checked. I have allow rules for it to access my LAN subnets in the IPSec firewall rules.

My client is windows and I can see that the 10.0.0.0/16 is showing up in my routing table as the second entry marked as on-link, all VLANs are accessible.

Without seeing the routing table from your computer it's a bit hard to tell what it is trying to do.

If you are still having this issue, You could change your MODP (DH Group) on pfSense to 2 and the hash to sha1, that should get you past that point.
Would be better to get the client side to use better settings though.

Thanks for that. I realise the pfSense version is badly out of date and needs updating. Unfortunately it has been planned then postponed by the people that own the firewalls several times after I'd done all of the work to prepare. It was discussed again a few days ago and the hardware will be replaced with a fresh pfSense install. I believe they had CARP break in an upgrade between 2.1.x to 2.2 and have been reluctant to upgrade them ever since.

IPsec policies match before the routing table.

Policy routing happens before IPsec policies and the routing table. But only when the connection is initially established into that interface.

Glad you found it.

piggy back off this thread, I have a mobile client ipsec tunnel set up on site a, and I've been trying to figure out a way for that mobile client (sub net 192.168.117.x) to reach site b in that hub and spokes structure. I tried adding a new p2 to the site a -> hub p1 with local subnet being 192.168.117.x remote subnet being the hub subnet. On the hub I added p2 with local being hub subnet and remote 192.168.117.x subnet. So far the mobile client can't connect to hub. I'm not too experienced with setting up tunnels using ipsec, does anyone have success in setting up similiar network?

Well this is beginning to look like a weird IPsec bug to me!

Home Office Phase 2 Entries:
192.168.10.0/24 to 192.168.40.0/24 ; Works!
192.168.11.0/24 to 192.168.40.0/24 ; Works!
10.1.12.0/24 to 192.168.40.0/24 ; Does Not Work

Remote Office Phase 2 Entries:
192.168.40.0/24 to 192.168.10.0/24 ; Works
192.168.40.0/24 to 192.168.11.0/24 ; Works
192.168.40.0/24 to 10.1.12.0/24 ; Does Not Work

Update: The problem seems to be isolated to the remote office firewall as it has the same problem with a peer-to-peer OpenVPN tunnel and other remote offices work fine with both IPsec and OpenVPN tunnels in the same configuration.

I recently got hit with this, couldn't run remote backups of my switches via SSH over a VTI tunnel after switching from site to site.

I noticed that entering 1400 in both the MTU and MSS for the interface resulted in a scrub for max-mss to 1360 which seems to be correct. Not sure why pfsense auto deducts 40 from the MSS, since MSS should be 40 less than MTU already.

Using 1400 in both fields on both ends of the links has resolved my issues here.

@jgraham5481 I did not explain myself properly with my writing. I can see how it could read that way. The domain controller has a NPC and also a DHCP and DNS services running. NPC provides the Radius server and the policies for authentication and authorization.
pfsense is managing routing between the WAN and LAN and it is assigned as the Gateway by the DHCP server (hosted in the DC) for all the devices in the LAN that use dynamic IP. When a client joins the VPN, it does in a different subnetwork with IP range assigned by pfsense. The latter does the routing between the VPN subnet and the LAN subnet for the VPN clients.