Solved it myself

So I thought I would solve the last piece of the puzzle but it seems authentication failes for my user in radius (not the password of the user). Not sure why failing. Tried to change several modes like PEAP but same problem must be something with the user but what!!!

I hade choosen password encryption MD5 for my user in FreeRadius. Strangely i though this was how the password was stored in FreeRadius but it seems that IPSEC couldn't resolve my password when it was encrypted. Sound wrong needs to be investigated.

There are endless different reasons you can have the same symptoms with IPsec. Please start a new thread with your logs and status output if it happens again, as it's almost certainly not the same root cause so that's the best bet for getting help.

I had a very similar problem last time. I could ping, but almost no other services work through the tunnel.

I assume you has the right firewall settings in place?

Especially when NAT-T is used for your IPSec connection, you surely can get into trouble with MTU. Do you use NAT-T?
Go to IPSec -> Advanced Settings and set the Maximum MSS to 1350.
This fixed the problem for me.

Give it a try.

There is no mechanism to send routes over L2TP. It either sends all, or the client has to maintain its own routes.

They don't show in the GUI, but you'd see them in /tmp/rules.debug or the live pf rules (e.g. pfctl -sr)

Thanks for the reply!

Both CA and server certs were generated in pfSense. I even tried deleting them and generating new ones. I'll try switching up the Phase 1 settings in a bit, see if that changes anything. I'll also take a looks to see what certs ipsec thinks is loaded.

I have this working, will post the configs for anyone's reference..

I deleted my 'Mobile Client'  under Tunnels, then went to 'Mobile Clients' tab and saw that "Create Phase 1" option was available.
I re-created Phase and Phase 2 and the vpn worked again.

Cheers

VPN: IPsec: Edit Phase 1: Mobile Client

Key Exchange version  V1
Internet Protocol      Ipv4
Interface  WAN
Description Mobile Client

Authentication method  Mutual PSK
Negotiation mode  Aggressive
My identifier  My IP Address

Encryption algorithm  AES 256
Hash algorithm    SHA1
DH key group  2
Lifetime  28800

NAT Traversal  Force
Dead Peer Detection  Enable  /  10  /  5

VPN: IPsec: Edit Phase 2: Mobile Client

Local Network  DMZ  (mine is DMZ but yours might be LAN)
Protocol  ESP

Encryption algorithms  AES 256 (only)
Hash algorithms    SHA1
PFS key group  2
Lifetime  3600

I deleted my 'Mobile Client'  under Tunnels, then went to 'Mobile Clients' tab and saw that "Create Phase 1" option was available.
I re-created Phase and Phase 2 and the vpn worked again.

Cheers

VPN: IPsec: Edit Phase 1: Mobile Client

Key Exchange version  V1
Internet Protocol      Ipv4
Interface  WAN
Description Mobile Client

Authentication method  Mutual PSK
Negotiation mode  Aggressive
My identifier  My IP Address

Encryption algorithm  AES 256
Hash algorithm    SHA1
DH key group  2
Lifetime  28800

NAT Traversal  Force
Dead Peer Detection  Enable  /  10  /  5

VPN: IPsec: Edit Phase 2: Mobile Client

Local Network  DMZ  (mine is DMZ but yours might be LAN)
Protocol  ESP

Encryption algorithms  AES 256 (only)
Hash algorithms    SHA1
PFS key group  2
Lifetime  3600

I deleted my 'Mobile Client'  under Tunnels, then went to 'Mobile Clients' tab and saw that "Create Phase 1" option was available.
I re-created Phase and Phase 2 and the vpn worked again.

Cheers

VPN: IPsec: Edit Phase 1: Mobile Client

Key Exchange version  V1
Internet Protocol      Ipv4
Interface  WAN
Description Mobile Client

Authentication method  Mutual PSK
Negotiation mode  Aggressive
My identifier  My IP Address

Encryption algorithm  AES 256
Hash algorithm    SHA1
DH key group  2
Lifetime  28800

NAT Traversal  Force
Dead Peer Detection  Enable  /  10  /  5

VPN: IPsec: Edit Phase 2: Mobile Client

Local Network  DMZ  (mine is DMZ but yours might be LAN)
Protocol  ESP

Encryption algorithms  AES 256 (only)
Hash algorithms    SHA1
PFS key group  2
Lifetime  3600

It looks like DPD is the problem. Disabled it on 15 tunnels (both sides). All 15 connections are stable for at least a day now.

DPD is still active on the "Strongswan" boxes. Not having any problems with them.

I have test result.
Client PC –> Pfsense 2.2.6 --------IPSec IKEV2------------> Remote Pfsense 2.2.6 IPSec VPN Server
This is will failed and get error code 809

Client PC --> Mobile Hot Spot Internet Share ------IPSec IKEV2 ----------> Remote Pfsense 2.2.6 IPSec VPN Server
This is can connect it.

I don't know why my client under pfsense 2.2.6 will failed.But it's can connect if Client PC under ip sharing or mobile hot spot.
How to check it?

Configure your IPsec logs as shown here: https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29

And then post (in a code block or attached .txt file) the logs generated by a connection attempt.

It may be a good time to upgrade yourself to an IKEv2 VPN rather than the old-style IPsec, too.

That GRE method is very interesting to me. First time I have seen it. Are there any MTU issues with it?

The first matching P2 would be the only one that would apply. You're right in that scenario is almost certainly something you'll never need to use, as if you can't get from B to A, then either C won't be able to get to A either, or B won't be able to get to C, so probably a moot point.

What you can do is configure a disabled P2 to do that routing from B to A via C, then if you happen to get into a situation where you can't get from B to A but can get from B to C to A, then disable the B to A matching P2 and enable the B to C and C to A ones. Manually disabling and enabling would be necessary in that case.