Derelict, thank you for replying to my post! The reason I want to have pfSense connect to the VPN server is that I want to be able to connect my mobile devices to my WiFi network and have access to the remote site through the VPN tunnel. As a workaround, I can use a Mac to connect to the VPN and create a hotspot (I thins to be more reliable on a Mac than on Windows), but I consider this option as the last option. Another solution is to buy another AccessPoint that offers Cisco IPSec with authentication, but my searches on the internet have not been very productive. If any of you know of an example, please let me know. (I have a Tomato AP, but that doesn't support IPSec out of the box) Thanks, Alex

Also you should be able to restore changes from the backup/Restore???

Thank you very much jimp. I chose the first option and its working well, just as I wanted. Wasn't so hard after all. I had to add the "-4" flag in the nrpe check too. One problem less :)

It's necessary in most every IPsec device but the methods are different. Some define the Phase 2 networks as we do. Ethers define them using ACLs, policies, or "routes" of sorts – no matter what you need to have a list of networks to allow on your side and IPsec destinations on the far side. Some try to automate or hide parts of it, but it makes diagnosing tunnel issues much more difficult than it needs to be. In the future it may be simplified somewhat by using aliases for Phase 2 networks, but that isn't possible yet.

@kapara: Yeah not sure either.  I guess the best way to find out is I will post a bounty.  I am sure others will also be interested in a true IPSec failover solution. Or ask in the strongswan / freebsd communities.

No.

@l123456: So what shoould i ping in this case ? I usually ping the LAN interface address of the remote box. Why I couldn't ping from server to server ? I'd think it is because something in your configuration prevents it.

Mostly, in my experience, IPsec connections need to match exactly on both endpoints. Problems arise when connecting pfSense to hardware like Cisco and Sonicwall (for which there are many good tutorials online). I have done both successfully, but it is always a challenge making pfSense terminology match-up to vendor terminology. -J

I changed the timeout of the VPN both sides and it works better.  It happens less times but still problems sometimes.  I need to disconnect it from remote side, then VPN is automatically up. Really strange…

You running PPTP on there? That's the log you end up with in the misconfiguration described here. https://redmine.pfsense.org/issues/1421 Jim's suggestion is the other likely possibility. When it's happening, check Diag>States, filter for ESP, :500 and :4500. What do those look like?

Anyway to tell pfsense to just reconnect if a failure happens?

@breakaway: Hello, I have 192.168.254.0/24 at Site A, and 192.168.253.0/24 at Site B. Site A pfSense has 3 interfaces. WAN – Static IP from my ISP LAN -- 10.0.0.0/24 OPT1 -- 192.168.254.0/24 Site B pfSense has 4 interfaces WAN -- static IP from my ISP WAN2 -- static IP from my ISP LAN -- internal stuff (not relevant to this) OPT1 -- 192.168.253.0/24 I've got a tunnel up between OPT1 (Site A) <-> OPT1 (Site B) I am wanting all traffic that goes into OPT1 at Site A to be directed through the IPSEC tunnel to OPT1 at Site B. Site B contains NAT rules to allow 192.168.253.0/24 to access the internet. What sort of settings do I need on the tunnel @ Site A pfSense to make this happen? PS, I've found a guide on how to send ALL traffic through the IPSEC tunnel but this is not what I want – I just want traffic out of OPT1 to go through the IPSEC tunnel. [image: 8quUL.jpg] Out of curiosity, have you tried setting up an additional phase 2 entry on the tunnel config at Site A to Site B for Source=OPT1 Net, Dest=Net 0.0.0.0/0? In theory this would tell all the traffic at Site A that is not local to route through the tunnel. On the other end, you likely don't even need a complementary Phase 2 entry. If you do this, keep in mind that you may need a firewall rule for IPSec traffic at Site B to allow this traffic in order for it to work.