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!

I was able to fix it by unchecking Obtain Topology Automatically under Policy in the settings of the shrewsoft vpn client and adding my local subnet under remote network resource.
I can ping 8.8.8.8 now but the intrenet traffic is not going thru the tunnel.  :(

It knows the CA by which cert you pick, no need to configure it. You probably missed part of the client instructions, either didn't import the CA, or didn't import it to the right place.

Definitely maybe. Provided thye're not blocking ports. I believe you will want to use "aggressive" and not "main", as it will allow pahse1 IP Address changes.

No, you can't manage them in the user manager. It has to be done in the IPsec PSK tab, or you can install FreeRADIUS and use that for authentication instead.

I've tried a few experiments in strongSwan and could never get more than one to work, but I may just not have hit a winning combination.

The problem is having it differentiate the request early enough that it can know to use the other profile. If you want to have two nearly identical profiles except for the authentication, that probably isn't going to be possible

That is not possible with mobile IPsec on pfSense. I'm not sure if it's possible in strongSwan itself.

It's very simple with OpenVPN, the RADIUS server can pass back the IP address and even firewall rules in reply attributes.