Yeah you almost certainly want tunnel mode there, not transport.

It really depends on the mix of intended VPN clients but if I had to use IPsec instead of OpenVPN for some reason I would try to get IKEv2 working first.

@schulzie00 BINAT is not so hard. The only thing that you have to take into account is that, from the point of view of the remote site the remote net you have to supply is the one you have used in the binat field and not the original one onf the LAN interface, so your phase II configuration must use this later one and rules must apply with this.

Apart from this take into consideration that there will not be any matching rules between local IP addresses (those in the LAN Net space) and binat addresses so the remote site clients would not be able to contact servers in the binat side unless you configure a NAT static translation too.

Hope this helps.

Thanks for the help.

What is the solution please i have the same problem :/
ipsec_starter[35497]: configuration 'con1000' unrouted

@Mathews What do system logs show on both sides when this happens? Everything is okay on the other side? I recommend keep the default lifetimes 28800 for phase 1 and 3600 for phase 2. Does it bring up the tunnel if you ping again the remote side after 45 minutes?

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-a-site-to-site-ipsec-vpn.html

Phase 1 lifetime:
"The lifetime defines how often the connection will be rekeyed, in seconds. 28800 seconds is a good balance of frequent rekeying without being too aggressive."

Phase 2 lifetime:
"The lifetime for which the negotiated keys will be valid. One hour (3600) is a good setting. Do not set this to too high (e.g. more than about a day: 86400) as doing so will give people more time to crack the key. Don’t be over paranoid either; there is no need to set this to 20 minutes either."

@Daz22 Hi, you will need a RADIUS server and use the Framed-IP attribute and group the addresses by aliases. For a domain environment, see the answer in my thread. If you want just a simple setup, you can drop all the NPS/AD stuff there and install FreeRADIUS on the pfSense. If I remember correctly, the package allows to set IPs in the user properties.

@Daz22 It is not possible the way it was intended (the conventional way: create AD groups for different network access rights, create a NPS policy for each group with different pools for which different firewall rules are set and pass the pools via Framed-Pool to the VPN server). You can see from the StrongSwan docs that Framed-Pool is not supported: https://wiki.strongswan.org/projects/strongswan/wiki/EapRadius
I haven't finished this yet due to other projects but will use Framed-IP-Address. The difference in management is that you don’t put users into AD groups but manage their access based on their personal IP directly on the firewall.
Hence, the user management will get a bit cumbersome, obviously, but we really need the access differentiation.
So far, I have created a PowerShell script that sets a unique IP address from our client VPN range for all the relevant AD users (not that easy, because users come and go, the script should overwrite manual settings but not settings from its previous runs; if i remember correctly, I implemented this based on AD timestamps). It should also create a CSV for the admins to keep track of the user IPs in the future. Next, I will create the “groups” as aliases on the firewall and create firewall rules for the aliases. For access management, you would put a user IP into an alias or remove it.

@aknewhope You need to add the 0.0.0.0/0 in your Phase 2.

Go VPN>IPSEC>Tunnels> Edit your phase 2
Under local network select network and put the 0.0.0.0/0 route in. Try and let me know if that works!

Then post your exact, detailed config.

If it was done correctly it would be working. ;)

@gh0stwr1ter

Documentation PFSense is also written that the possible problems with connection of L2TP/IPsec clients behind a NAT. And it is recommended to use IKEv2.
received packet: from 75.129.232.186[4500] to 144.202.66.15[4500] (92 bytes)

I also recommend setup remote access using IKEv2

For example,
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev2-with-eap-mschapv2.html

Thanks for the help @Derelict and @Konstanti
What ended up working for me is

pfSsh.php playback svc start ipsec

along with some of the ipsec down and up commands. Hadn't tried swanctl but definitely appreciate all of the suggestions!

Yeah, after more playing it doesn't seem that VTI+IPv6 is working right. I tried adding a second SA on the IPv4-based tunnel and it didn't work right at all. I changed it to a GIF over VTI and it came right up with no trouble.

While it seems a little wasteful, anything less than a /64 causes weird behaviors with IPv6 in certain cases so I've always stuck with that. I know in recent years there have been recommendations on using /127 prefixes on intra-router links (e.g. RFC6164) but this is all interior connections.

Thanks for the response.

Another note: Apple devices behave completely differently when configured manually or via a profile. You might have better luck using a generated profile.

Did you add firewall rules on the IPsec tab for the desired incoming traffic?

As I was testing with PFS "off", I thought to myself "Perphaps they configured more groups except PFS 19" and I just tried with PFS group 14 and I think I was right. They told me 19 but 14 seems to exist, too. As far as I can tell, it works with 14 as expected, after 1 hour the rekey starts and seems to work fine. The MTU is not too big and a new child_sa is created.

Apr 13 19:19:32 charon 06[CHD] <con4000|30> CHILD_SA con4000{1584} state change: INSTALLING => INSTALLED Apr 13 19:19:32 charon 06[IKE] <con4000|30> CHILD_SA con4000{1584} established with SPIs c25045b2_i 495408d7_o and TS 10.207.239.61/32|192.168.1.0/24 === 10.11.0.0/11|/0 Apr 13 19:19:32 charon 06[CHD] <con4000|30> SPI 0x495408d7, src 213.34.11.17 dst 185.121.192.8 Apr 13 19:19:32 charon 06[CHD] <con4000|30> adding outbound ESP SA Apr 13 19:19:32 charon 06[CHD] <con4000|30> SPI 0xc25045b2, src 185.121.192.8 dst 213.34.11.17 Apr 13 19:19:32 charon 06[CHD] <con4000|30> adding inbound ESP SA Apr 13 19:19:32 charon 06[CHD] <con4000|30> using HMAC_SHA2_256_128 for integrity Apr 13 19:19:32 charon 06[CHD] <con4000|30> using AES_CBC for encryption Apr 13 19:19:32 charon 06[CHD] <con4000|30> CHILD_SA con4000{1584} state change: CREATED => INSTALLING Apr 13 19:19:32 charon 06[CFG] <con4000|30> config: 10.11.0.0/11|/0, received: 10.11.0.0/11|/0 => match: 10.11.0.0/11|/0 Apr 13 19:19:32 charon 06[CFG] <con4000|30> selecting traffic selectors for other: Apr 13 19:19:32 charon 06[CFG] <con4000|30> config: 10.207.239.61/32|192.168.1.0/24, received: 10.207.239.61/32|/0 => match: 10.207.239.61/32|192.168.1.0/24 Apr 13 19:19:32 charon 06[CFG] <con4000|30> selecting traffic selectors for us: Apr 13 19:19:32 charon 06[CFG] <con4000|30> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ Apr 13 19:19:32 charon 06[CFG] <con4000|30> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ Apr 13 19:19:32 charon 06[CFG] <con4000|30> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ Apr 13 19:19:32 charon 06[CFG] <con4000|30> proposal matches Apr 13 19:19:32 charon 06[CFG] <con4000|30> selecting proposal: Apr 13 19:19:32 charon 06[IKE] <con4000|30> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Apr 13 19:19:32 charon 06[IKE] <con4000|30> received NON_FIRST_FRAGMENTS_ALSO notify Apr 13 19:19:32 charon 06[IKE] <con4000|30> received ESP_TFC_PADDING_NOT_SUPPORTED notify Apr 13 19:19:32 charon 06[ENC] <con4000|30> parsed CREATE_CHILD_SA response 2 [ SA No KE TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ] Apr 13 19:19:32 charon 06[NET] <con4000|30> received packet: from 185.121.192.8[500] to 213.34.11.17[500] (480 bytes) Apr 13 19:19:32 charon 06[NET] <con4000|30> sending packet: from 213.34.11.17[500] to 185.121.192.8[500] (480 bytes) Apr 13 19:19:32 charon 06[ENC] <con4000|30> generating CREATE_CHILD_SA request 2 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ] Apr 13 19:19:32 charon 06[IKE] <con4000|30> establishing CHILD_SA con4000{1584} reqid 70 Apr 13 19:19:32 charon 06[CFG] <con4000|30> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ Apr 13 19:19:32 charon 06[CFG] <con4000|30> 10.11.0.0/11|/0 Apr 13 19:19:32 charon 06[CFG] <con4000|30> proposing traffic selectors for other: Apr 13 19:19:32 charon 06[CFG] <con4000|30> 10.207.239.61/32|192.168.1.0/24 Apr 13 19:19:32 charon 06[CFG] <con4000|30> proposing traffic selectors for us: Apr 13 19:19:32 charon 06[IKE] <con4000|30> activating CHILD_CREATE task Apr 13 19:19:32 charon 06[IKE] <con4000|30> activating new tasks

I'll let it run through the night to see if it works but I'm pretty confident that it will. I don't know why PFS group 19 raises this problems I described above but if it works with 14, this should be a problem for another day.

Anything in the firewall log regarding those two clients? If it's working once, it should continue to work.

That shouldn't matter, as long as the ISP router doesn't block or otherwise mess with IPsec.

Configured by this method. Everything works and Apple and Android devices.
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev1-xauth.html