Hi there @lmendoza
And you can get valid wildcard certificates (LE) with godaddy's dns api
Dynu.com (also you can get valid wildcard certificates (LE) with dynu dns api)
I was recently struggling on the same issue, every strongswan doc about my intended setup says I need to set leftsourceip=%config (into ipsec.conf. which is .vips in swanctl.conf).
As far as I understand I can't simply edit the strongswan config manually otherwise they would get overwritten. Could you provide any advice about hot to get this working?
Restricting the local (pfsense side) site subnet to a single address in tunnel mode does not work because (as per strongswan doc's warning) that address is not installed on the tunnel. The VTI mode somehow "works" because that "local" address gets set on the virtual interface but the CHILD_SA local subnet is not getting restricted to that single address and ofc I can't restrict this from the remote responder since that phase2 conf is made to match many pfsense roadwarriors, not just a single one.
Use Radius for authentication. When I checked the Radius server settings. I noticed that I made a config mistake I set the Services Offered to "authentication". When I changed it to "authentication and accounting". Everything started working as it supposed to.
@jimp ive had an idea which i just tried. i made a subdomain for each phase 2 entry (4 in sum), so i connected 1 ipsec (phase 1) with the IP and added another 3 with different subdomains to the same ip and with the different phase 2 entrys. Seems to work. Looks pretty ugly but at least it works on 2.5.2.
Just ran into this ourselves...on this router back in late September I stopped pcscd but I didn't bother installing the patch since 21.09 was presumably imminent. Fast forward a few months and we're setting up IPSec, with pcscd long stopped. Diag/activity showed 88% idle at the top, yet had the lines for charon and syslogd and the idle/CPU entries were only a few percent. Starting pcscd dropped CPU use to normal. Patch + stop IPSec + stop pcscd + start IPSec fixed it.
I finally managed to do it by adding 10.10.10.0/24 to phase 2 at local and remote site.
I should have been more concrete in the initial problem description.
The problem was not, that I could not add a phase 2 entry at the remote site, but that there is another router behind the vpn remote gateway and the remote clients.
And it would have been impossible for me to add routes on this router.
Now I added 10.10.10.0/24 as phase 2 just to bring up the tunnel and force the kernel to route the traffic (DNS responses) over IPSec. In this configuration, native communication between 192.168.0.0/24 and 10.10.10.0/24 is still not possible, but port forwarding from 10.120.0.250>10.10.10.10 now works like a charm 👍
So it's more like a hack than a solution, but it's not stuppid als long as it works 😁
I spent several hours in trial and error with Routed IPsec (VTI) but finally ended up in using (NATed) openVPN config behind the partner IPSec tunnel.
The main issues I had was with a endpoint using dynamic IPs and the leck of knowlege how to use vti config if the other side uses P2 config without vti. It looks like pfsense is mixing up P2 phases when using 0.0.0.0 on the other side due to dynamic IPs. Ubiquity (on one partner side) is not supporting dynamic IPs at all when using VTI.
@restrictedrRouted IPsec (VTI) may work in your scenario but I had a hard time and ended up in using openvpn. The restrictions and/or best practices are not well documented and additonally will not work if you have endpoints using dynamic IPs