If you have a chance, take a backup and try a pfSense 2.1 snapshot, it's using a newer version of IPsec tools (racoon).

There were a few changes to IPsec from 2.0.1 to 2.0.2 but not that I'm aware of that would cause problems with mobile client SAs.

Do make sure that you have "Prefer old IPsec SA" unchecked under System > Advanced on the Misc tab.

For the sake of your sanity (speaking from bitter experience) change the remote subnets.

I spent years using NAT to workaround just this issue, and with sites daisy-chained together over private circuits I'd got NAT(NAT(NAT))) going on in some cases!  It took me about a day to completely renumber each LAN (about 65-70 PCs each + servers, switches, printers, router(s), etc) - I wish I'd done it years ago!

To clarify the 'bringing the tunnel up' point:

All the 'connect' button does is to ping a node in the P2 subnet so the daemon will see this and bring the tunnel up for it.  It's no different than you pinging a remote node from a connected PC and the tunnel should come up if you do that.  If not then you have some troubleshooting to do.

Next, in my experience the ASAs are a bit picky about who gets to initiate the tunnel.  Usually, setting 'Obey' in the P1 proposal checking will sort them out.  Basically you're saying that when the ASA responds, agree to do things their way from then on.

Did you ever find a solution to your problem?  I have a similar problem.  My Mobile Device IPSec settings work great for OSx and iOS.  My Android device succeeds on the Phase 1 connection, but as soon as I try to connect to anything Phase 2 fails and the tunnel drops.  I have multiple Phase 2s.  My current hypothesis is that Android can't handle more than one Phase 2.  I'm trying to get my hands on a test pfSense to test this hypothesis.  Would love to hear if anyone has a solution.

Here is one answer to my question, to reset all your states go to Diagnostics->States->reset. This is a broad tools though. I would like to reset states that correspond to a specific rule established.

Hi,

Thanks for the reply, seems to have solved most of the problems will tune it over the next few days to iron out any hold outs.

Thanks again for your time.

Cisco makes a hardware VPN client, the 3002 just for this purpose.  I think it is discontinued, but still works well for connecting a group of people as a classic Cisco IPSEC client.

It probably has more to do with how the HAproxy instance is sourcing the traffic that is trying to reach the servers.

If the proxy process using the "wrong" IP to send the traffic to the server, it would never enter the tunnel because it wouldn't match the Phase 2 entry on the tunnel.

Try redirecting temporarily to a local server, see how the traffic is sourced, and account for that in the IPsec Phase 2 configuration.

Well if both devices can't ping each other, then that will need to be resolved.
You also seem to be missing rules for ISKMP (500 UDP), AH, ESP and Nat-T (4500 UDP).
I'm still learning my way around pfsense myself, but once I opened up the required ports on the WAN side filtering of both devices, the tunnel came up.

Works like a charm! Thanks a lot  ;D

Status > IPsec.

Green icon means a phase 2 is established.

You can look at the SAD and SPD tabs to see the interpreted output of "setkey -D" and "setkey -DP", if needed.

I've never done it but check out below post…seems to be exactly what you are attempting.

http://forum.pfsense.org/index.php?topic=27444.0;prev_next=prev

thank you for taking the time to follow up, DPD is disabled for the IPsec, as I found that same conclusion, but my "GRE" tunnels are what's failing.

This appears to be a routing issue:  I can do a packet capture on the IPSec interface of pfsense, and I can see incoming pings, and their destination:

12:52:18.793013 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1871, length 40 12:52:19.826520 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1872, length 40 12:52:21.329649 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1873, length 40 12:52:23.829947 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1881, length 40 12:52:25.326576 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1882, length 40

After I disconnect, and have cleared the ipsec log, this appears after a moment or two:

Apr 28 12:49:50 racoon: DEBUG: pk_recv: retry[0] recv() Apr 28 12:49:50 racoon: DEBUG: got pfkey ACQUIRE message Apr 28 12:49:50 racoon: DEBUG: suitable outbound SP found: 0.0.0.0/0[0] 10.1.53.1/32[0] proto=any dir=out. Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501288: {LAN_SUBNET}/24[0] {LAN_IP}/32[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501648: {LAN_IP}/32[0] {LAN_SUBNET}/24[0] proto=any dir=out Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x285013c8: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: suitable inbound SP found: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in.

Im not sure if that is relevant or not.