Thank you jimp, setting net.isr.dispatch=deferred solved my problem and should work until the hardware will be upgraded next year.

Sorry for this post. @Thread creator: how did you solve the problem? I'm running in exactly the same problem!

As cmb said before: You have to setup the corresponding phase 2 on both sites. Site 0 config: local subnet: 192.168.111.0/24 Remote subnet: 192.168.2.0/24 Site 1 config: local subnet: 192.168.2.0/24 remote subnet: 192.168.111.0/24 Another point may be, that your phase 2 on your mobile phase 1 of Site0 is configured wrong. Try there as local subnet 0.0.0.0/0.

Thank you for your confirmation!

2.3.1-RELEASE-p5(amd64) On the link jimp posted: I tried the manual fix for my GRE Tunnel over IPSEC and it allowed the traffic through.  Tried the Automatic Fix and it didn't work, so will have to do the manual fix for all the traffic. I see ticket 4479 talks about the issue: https://redmine.pfsense.org/issues/4479 So trying to dig into this a bit further: While creating rules to allow the traffic I ended up creating both rules on the Floating tab. Rule 1: GRE Interface, direction out, Source was the local network, destination was the remote network, any TCP flags, and Sloppy State Rule 2: Local Network interface,  direction in, source was the Remote network, destination was the local network, any TCP Flags, and Sloppy State

That is all up to the client on Windows. Nothing pfSense or the server can do.

Not sure I quite follow how you've got that setup. "IKEv2 server listens on one of the OpenVPN connections" as in you have to connect to IKEv2 through OpenVPN? Are the port forwards also on OpenVPN? What is your IPsec mobile client network? OpenVPN tunnel network? Any overlaps there? It sounds almost like when you disconnect that the firewall's routing table is losing its default gateway or something along those lines. Visit /status.php on the firewall and download the file when it works, and then again when it breaks, and compare the various files looking for what changed.

Do you have an IP address filled in on the IPsec P2 entry to ping the remote end? The P2 won't come up until some traffic tries to pass.

Invalid major version means you have one side on IKEv1 and the other on IKEv2 more than likely. Some vendors have proprietary IPsec extensions that use other version numbers, but pretty sure Netgear isn't among those.

That means you have tunable net.inet.ipsec.debug set to something other than 0. In addition to the log spam, that has a significant amount of performance overhead, so I'd recommend setting that back to 0.

Search around a bit more and you'll find that you have to either: 1. Use a VPN profile to make iOS and OS X use parameters that Windows will use -or- 2. Make a registry change on Windows to make it accept the parameters that iOS/OS X will use Option 1 is the easiest path. If you purchased a device from us you can set your VPN such that Windows will connect and then click VPN > IPsec Profile to download an iOS/OS X VPN profile that will configure them automatically. Otherwise you'll have to roll your own profile using Apple's tools.

I marked the topic as solved. If anyone wants to comment on my rules you are welcome. :)

What's in the logs?

Hello after trying some configurations I found the following config working with PFS 2.3.1 and Fritzbox 7490 (06.55-33668 BETA): Assuming the following Values: PFS IP: 10.0.10.1 PFS Network: 10.0.10.0/24 PFS EXTERN IP: 217.0.0.217 FB IP: 192.168.10.1 FB Network: 192.168.10.0/24 FB DDNS Name: abcd.myfritz.net PSK: same_most_secret_password_as_in_PFS Fritzbox VPN Import File: /* Path_to_Fritzbox_VPN_config_file.cfg Timestamp */ vpncfg {         connections {                 enabled = yes;                 conn_type = conntype_lan;                 name = "VPN_fancy_name";      <<< VPN Name                 always_renew = yes;                 reject_not_encrypted = no;                 dont_filter_netbios = yes;                 localip = 0.0.0.0;                 local_virtualip = 0.0.0.0;                 remoteip = 217.0.0.217;              <<< External IP of PFS                 remote_virtualip = 0.0.0.0;                 keepalive_ip = 10.0.10.1;            <<< Private IP of PFS (usually default gateway IP of local PFS network)                 localid {                         fqdn = "abcd.myfritz.net";    <<< external FQDN e.g. MyFritz ID                 }                 remoteid {                         ipaddr = 217.0.0.217;          <<< External IP of PFS                 }                 mode = phase1_mode_aggressive;                 phase1ss = "def/3des/sha";                 keytype = connkeytype_pre_shared;                 key = "same_most_secret_password_as_in_PFS";  <<< Pre-Shared-Password                 cert_do_server_auth = no;                 use_nat_t = no;                 use_xauth = no;                 use_cfgmode = no;                 phase2localid {                         ipnet {                                 ipaddr = 192.168.10.0;  <<< Private Network of Fritzbox                                 mask = 255.255.255.0;                         }                 }                 phase2remoteid {                         ipnet {                                 ipaddr = 10.0.10.0;        <<< Private Network of PFS                                 mask = 255.255.255.0;                         }                 }                 phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";                 accesslist = "permit ip any 10.0.10.0 255.255.255.0";         }         ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",                             "udp 0.0.0.0:4500 0.0.0.0:4500"; } // EOF Config within PFS 2.3.1: =============== Phase 1 - General Information Disabled: off Key Exchange version : V1 Internet Protocol: IPv4 Interface: WAN Remote Gateway: abcd.myfritz.net    <<< external FQDN e.g. MyFritz ID Description: VPN Name Phase 1 Proposal (Authentication) Authentication Method: Mutual PSK Negotiation mode: Aggresive My identifier: My IP address Peer identifier: Distinguished name  /  abcd.myfritz.net      <<< external FQDN e.g. MyFritz ID Pre-Shared Key: same_most_secret_password_as_in_PFS  <<< Shared Password Phase 1 Proposal (Algorithms) Encryption Algorithm: 3DES Hash Algorithm: SHA256  or SHA1  (try both, one should work!) DH Group: 1 (768 bit) Lifetime (Seconds): 3600 Phase 1 - Advanced Options Disable rekey: off Responder Only: off NAT Traversal: auto Dead Peer Detection: on Delay: 10 Max failures: 5 –- Phase 2 - General Information Disabled: off Mode: Tunnel IPv4 Local Network: LAN subnet NAT/BINAT translation: none Remote Network: Network / 192.168.10.0 / 24 Description: VPN Name Phase 2 Proposal (SA/Key Exchange) Protocol: ESP Encryption Algorithms: AES / 256 bits  and 3DES Hash Algorithms: SHA1 PFS key group: 1 (768 bit) Lifetime: 3600 Phase 2 - Advanced Configuration Automatically ping host: 192.168.10.1  <<< Private IP of Fritzbox I did not try to find the most secure VPN settings possible, but this config works with my needs. I use on both side more then one VPN. Using this setup works on the Fritzbox in combination of Single User VPNs and additional Fritzbox-Fritzbox Connections. If one has any Ideas to change settings to increase the security level, please let me know.

@aventrax: But GRE is unencrypted… isn't it? Yes, that's why you wrap the GRE tunnel within IPsec, so the whole tunnel get encrypted

Looking through your screenshots, I saw an error. Under General Information for the Phase 2 settings. You have for the local Network 0.0.0.0 /24 When it should be 0.0.0.0 /0 to route all traffic from the remote network to the pfsense box.

When using PAP authentication the password field is encrypted with the shared secret so it is only as insecure as your shared secret.

Hey Anvar, I'm running pfSense 2.3.1_5 and I have a somewhat similar setup.. Site 1: Office (pfSense) Site 2: Azure 1 Site 3: Azure 2 We started with only Site 1 & 2 (no Azure 2) and had a Site to Site VPN working 100% fine. We later added Azure 2 (Site 3) and wanted to connect it to Site 1 & 2. Connecting Site 1 & Site 3 was trivial, pretty much duplicated the Phase 1 & 2 settings and just updated the IPs as required. Where I think things started to fall off the rails was when connecting Site 2 & 3 together. We created another Site to Site VPN between the two networks. Traffic between them is fine, but traffic to/from Azure & Office is terrible and pfSense reports high packet loss on the WAN Gateway for some reason. From your knowledge, is what I'm doing not the proper way? Should I be setting up a Multi-Site VPN on Azure instead of 2 Site to Site VPNs (per site)? Does pfSense handle Azure's Dynamic Routing? Thanks in advance!