Sorry for such a delay in response. We sidelined this project for a while and I just got back on it today. I did some more troubleshooting and determined that the 10.0.10.0 endpoint was the one with the problem. I figured this out by creating IPSEC tunnels from my office to each of 172.16.88.0 and 10.0.10.0. Both Tunnels established but I was not able to pass trafffic between my office and 10.0.10.0 netowrk in either direction. I look over every setting on that firewall again and it all looked good. The only other thing that I though of was that they have DSL at this location and maybe the "DSL Modem" was blocking some tracffic. I logged into the modem even though it is bridged and saw a lot of this in the log: 2015/02/25 22:14:49 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=22826 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:44 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=1003 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:39 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=7795 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:35 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=49042 PROTO=ESP SPI=0xc10fb172 Those IPs are the 2 endpoints to the Tunnels: Unfortunately I am at home and when I try to get into the settings of the modem it asks for the "access code" which is printed on the bottom of the modem. I will have to wait until friday at earliest to get that code to see what is set on this thing that is blocking traffic. (Snow Storm here tonight) I will make sure to follow up in  this thread with what I find out Thanks!

Just restart the box to enable unsecure preshared key with agressive mode. The logs at the end are very clear on that. Sometimes the configuration change is not applied on the daemon which will be fixed on newer versions, for now just restart it.

This is about 2.1.5 or 2.2 since it is not very clear?

@jiunnyik: I'm following thread to know how is OpenVPN will cause Ipsec phase 2 not working. I have this issue as well. I too would be intrigued to find out more.  One of my tunnels consists of pfSense 2.1.5 <-> pfSense 2.2, one of the P2s is a supernetted range of VLANs, some of which are OpenVPNs (at the 2.1.5 end).  This has been stable for 11 days. 2.2 end - 192.168.x.0/24 2.1.5 end - 10.x.0.0/16 + 192.168.x.0/24 The 10.x is actually lots of 10.x.y.0/24. y=250,251,252 are OpenVPN tunnels. IPSEC should not care what subnets or for what purpose or even if they exist locally.

I'm by no means an expert either, so take what I say for what it's worth. I had a similar issue, using EAP-MSCHAPv2. In my case, I had to create the cert a very specific way. As the instructions state, I used my local host name for the common name. Then I had to add the external IP address as an IP type alternative name, and also as a DNS type. I get connected just fine now. Only issue I now is, internal DNS names don't resolve. I can only my network devices by IP. Hope this helps. Good Luck!

Ok Seems like 2 good solutions. Thanks for your help

No idea, no logs, cannot test with dead pfSense versions.

Thanks for the link charlie I had not seen that. Will give some of it a go. :D

I have been trying to figure this one out and found something else strange going on. When the Ipsec tunnels are up, if I try to ping that SQL server's IP from Pfsense and from the same interface it connects to, it then seems to direct the traffic back down the Ipsec tunnel as I see the traffic hitting the firewall on the other end. No Ipsec then it seems to go direct. How can I specific that even with IPsec, local addresses can be found locally? May be relevant, but I have compared route tables and Arp tables between Ipsec connected and not connected and they are the same.

Thank you guys. My problem is solved. After comparing the deference between static IP and DHCP IP, I found the static IP PC was using subnet mask 255.255.0.0 instead of 255.255.255.0. Then problem is gone after I changed it to 255.255.255.0.

Thanks!  Been so busy today I didn't have a chance to write and say that I'd done that, but the tunnel still didn't appear to be working, but then we disabled and re-enabled it on a whim and then it suddenly decided to start working! Sometimes it's finding these solutions that can be maddening and at the same time, have you cheering out loud in your cube.

Just to update folks on the forum. We have been following this issue for a while and it appears the Devs were finally able to replicate this. Looks like a fix is being tragetted for 2.2.1. You can follow the link below to monitor progress. https://redmine.pfsense.org/issues/4341

@nikolaii: Hello, just one word: brilliant! I followed your instructions and everything worked flawlessly :) Thank you. Nicolas Cool! Glad to hear it worked for you! :-)

I'm answering myself to this "issue" : based on this thread (https://forum.pfsense.org/index.php?topic=88208.msg487019#msg487019) I was able to create the tunnel. The fact that I was using the same originating IP to setup the firewall than the one in the Phase1 in order to setup the tunnel was causing the problem. So I managed to connect to the firewall with another IP, and no more problem. But this is actually kind of weird … Anyway, it works, just remember NOT to connect to a remote firewall with the same IP that you'll be using in your Phase1 setup! HTH. Nicolas

I found this thread https://forum.pfsense.org/index.php?topic=88209.0 After a reboot the tunnel came up. Let's see how long it lasts.

Hello, I'm in the same boat, so I'm curious to know if you managed to setup your IPSec tunnel on the OVH infrastructure? Thanks. Nicolas

Definitely a re keying issue with strongswan >:( suggest switch all links to Openvpn. I already have and with only the most critical ones being handled by a linksys soho router. rgds