Personally, I prefer OpenVPN for that role, especially when working with multiple architectures. However, IKEv2 can work fine as well. You'll get better performance out of IKEv2, but if load is not a concern, OpenVPN can be easier and more flexible.

Both are secure, so long as you use secure settings. There are articles on the Doc wiki for both setups.

Isn`t mixed traffic (IPv4 and IPv6) supported with IKEv2 or is it just mixed traffic for phase 1 and phase 2?

Hi,

create a new revocation list from System->CertManager->CertificateRevocation add the certificates that you do not want to be active any more assign the new revocation list to the vpn server in my case VPN->OpenVPN->Servers

You can easily choose your revocation list from the combobox Peer Certificate Revocation list.
do not need to restart or refresh the change is immediately

bye
Domenico

I did not. Silly me.

Thanks for the help!

Answer

Use a new 10.6.23.0/24 subnet for this site.

Then add a new P2 at the main site for 192.168.2.0/24 to 10.6.23.0/24.

At the remote site add a new P2 for 10.5.35.0/24 to 192.168.2.0/24 and add the NAT address field to 10.6.23.0/24.

The 1:1 NAT setting is no longer required as route-based IPsec is not supported in FreeBSD 10(pfSense 2.3.4) hopefully in 2.5.
Thanks to pfSense support that gave me this valuable information.
https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html

Hi, nevermind, I found the issue, some time ago I installed BIND, I think its conflicting. I stopped BIND and it works now. thanks.

I Have this same issue.

I have read some articles which lead to this https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules

as theology have TCP:SA in them which indicates asymmetric routing
Jul 14 16:04:15 ► gre0   172.16.15.30:179   172.16.15.29:65116 TCP:SA
Jul 14 16:04:23 ► gre0   172.16.15.30:179   172.16.15.29:65116 TCP:SA

I've added tcp flaps and sloppy states to all my rules under floating and the traffic is still getting blocked which is rather frustrating!

anyone come across a fix or things to check?

Thank you.

FYI this appears to have been resolved as per below and does not appear to have been load related;

The Sonicwall Syslog was more revealing - "IKEv2 IPsec proposal does not match: DH Group mismatch" & "VPN Policy: GHtoBH; ESP TFC Padding not Supported". I'm not sure why but checking "Enable Perfect Forward Secrecy" appears to have fixed it, although
"ESP TFC Padding not Supported" still appears in the logs. Article here https://www.sonicwall.com/en-us/support/knowledge-base/170505666326684.

If anyone can offer an explanation that would be appreciated. I'm not 100% convinced is resolved as I feel it may just have renegotiated and worked - However this is a finger in the air feeling and does not come from any solid fact!

@Bengatzu:

Had same Problem:

PfSense 2.3.4 and lot of Clients which running Win10 (1607). Connect via Open VPN or via TheGreenBow IPsec works without problems.

Then Client Updates Win10 (1703) killed all. No possible VPN Connection.

Changed HDD and Restored Veeam Backup on Test Client to Win10 (1607) - VPN works successful

After HDD replace to old one with Win10 (1703) - no possible VPN Connection.

Workaround that solved my Problem:

Deaktivate on Win10 (1703) Clients the following Services:

IKE- and AuthIP Ipsec Keymodule, IP-Helpservice, IP-sec Rule Agent

after reboot all VPN Connections working successful

This worked…although all I did was disable the "IP Helper" service by setting to "Manual" Startup Type.  My VPN would not connect unless the "IKE and AuthIP IPSec Keying Modules" were set to Automatic and I did not have an "IP-sec Rule Agent" Service.

Thanks so much for the help!

No one? :(

I (maybe wrongly) figured I'd try

1. Interfaces> (Assign)
2. PPPs > New (pptp)
3. Link (tried both wan and lan), input one of the IP's I usually get from my server as local with /24 network mask. Gateway typed in the public IP of the pptp server
4. Interface assignments > Assigned the pptp to OPT1
5. Interfaces > OPT1. Enabled it
6. Status > Interfaces. Hit connect.. nothing happens

Am I on the right track here?

Firewall reboot took care of the issue

i found this but it doesn't work. can anyone else chime in.

he's describing the same situation im facing. but i find that it dosnt work when i try to replicate it.

https://forum.pfsense.org/index.php?topic=109524.0

https://redmine.pfsense.org/issues/6263