Re: IPSEC tunnel can access any Interface but LAN After spending hours in experimenting I found the issue is different, probably will open a new thread in correct section and correct details

Hi, I install Iperf3 and run a test from Local PC to Local pfSense. 940ish in both directions. If you will be able to set up iperf on pc 1 behind pfsense 1 and pc 2 behind pfsnese 2 and do an iperf test again it would more realistic and based on the entire money you spend it might be nice to hear what comes out. Being sure with this hardware setup like yours you may often connect two branches or companies to gain the entire throughput for workload and/or file transfer like syncing and / or db data exchange. Recently one of my VPN's that had been running at 250-300mbps dropped to 20mbps. By the way from what should it breaking in? Perhaps based on the other vpn end and not on your site?

@jimp said in Virtual Address Pool in Pre-Shared Keys is not used for ipsec: It works right now if the client sends the correct identifier in P1, but the problem is that Windows doesn't. Other clients like those on Linux or the strongSwan app send the correct ID and can use per-user addresses right now. There is a patch in the Redmine issue linked above that has shown promise with Windows clients but isn't a complete solution. Jimp, if you could get that patch to work - and thereby enable windows native clients to use PSK defined pool addresses - would be REALLY nice!! Any chance you could spend a little time to get the IPSec Daemon to accept a virtual address pool returned from Radius in a EAP-Radius setup? That would be the ultimate solution to get pfSense IPSec VPN go Enterprise. Right now its useless because it doesn’t scale and you cant separate user rights with firewall rules.

@cmos_battery in case you are still experiencing this it would likely be caused by having multiple similar P2 transforms selected.

Just found the answer The solution was to create another routing table on the 10.4.0.0/24 subnet. Both the below rules were needed on both subnets 172.30.0.0 /16 - next hope VA IP 10.4.1.4. Hindsight is a wonderfull thing.

Wenn du an der Arbeit anderer Agenturen zweifelst, dann verlass dich auf dein Bauchgefühl. In der Regel hat die Intuition immer Recht. Die Suche hat in unserer Firma auch eher länger gedauert, dass muss ich zugeben. Am Ende haben wir uns für die Webagentur https://treestones.ch/agentur entschieden. Seitdem ist das Thema endlich vom Tisch. Die machen einen super Job und wir können uns auf die anderen Dinge konzentrieren. Im Moment gehen ja die Preise unglaublich in die Höhle, wenn es um Sprit geht. Wir müssen unbedingt eine Strategie für unsere Firmenwagen entwerfen.

@macormick I also have a caching Problem here: openvpn-external-crl-automatic-renewing-openvpn-restart

@sergecaron This issue is reported as #7773 IPSec using IKEv2 with split DNS not using provided domain names and is opened since August 2017. This is what an iOS client currently receives in pfSense 2.6.0: 08[IKE] <con-mobile|60> IKE_SA con-mobile[60] state change: CONNECTING => ESTABLISHED 08[IKE] <con-mobile|60> scheduling rekeying in 25549s 08[IKE] <con-mobile|60> maximum IKE_SA lifetime 28429s 08[IKE] <con-mobile|60> peer requested virtual IP %any 08[CFG] <con-mobile|60> reassigning offline lease to 'RemoteUser' 08[IKE] <con-mobile|60> assigning virtual IP 192.168.233.241 to peer 'RemoteUser' 08[IKE] <con-mobile|60> peer requested virtual IP %any6 08[IKE] <con-mobile|60> no virtual IP found for %any6 requested by 'RemoteUser' 08[IKE] <con-mobile|60> building INTERNAL_IP4_DNS attribute 08[IKE] <con-mobile|60> building INTERNAL_IP4_DNS attribute 08[IKE] <con-mobile|60> building INTERNAL_IP4_SUBNET attribute 08[IKE] <con-mobile|60> building INTERNAL_IP4_SUBNET attribute 08[IKE] <con-mobile|60> building (27674) attribute 08[IKE] <con-mobile|60> building UNITY_SPLITDNS_NAME attribute 08[CFG] <con-mobile|60> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ 08[IKE] <con-mobile|60> CHILD_SA con-mobile{6} established with SPIs cf1aed7d_i 053643d4_o and TS 192.168.18.0/24|/0 192.168.166.0/24|/0 === 192.168.233.241/32|/0 08[ENC] <con-mobile|60> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS DNS SUBNET SUBNET (27674) U_SPLITDNS) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ] The 27674 and UNITY_SPLITDNS_NAME attributes are not defined in IKEv2. This client will never process interal DNS servers. Is it time to fix this ? Regards,

@jimp Thanks. This make sense... I can confirm: IOS 15.3.1 (both IPHONE and IPAD PRO) failed badly. I was hoping to use the Mobile Client for 0.0.0.0/0. I can still use the LAN access. Really appreciate the note so I can stop digging.

While it may be unexpected for you, it's doing what it was told to do. Namely, it picked a default gateway automatically. It's safest to ship with that on automatic as it ensures the most likely path to success initially. Once you add more interfaces with gateways it's not so simple, though. It's easy enough to change the default gateway to a specific entry (or a gateway group expressing your automatic failover preference). I thought we had a warning in the docs but I don't see one now. I'm probably thinking of WireGuard which does have a warning. I'll look into adding a similar note to the VTI docs.