IPsec failover needs dynamic DNS, so you set the local interface as a gateway group, and on the remote host you set the destination to the dynamic DNS host you have tied to the gateway group. Of course, you need to be able to specify a resolvable host instead of an IP on the other side, and also make sure that you don't have issues with cached DNS responses and stuff alike (no idea how Juniper handles this). For example, I have implemented failover IPsec between pfSense and MikroTik routers by setting a script on the MikroTiks that resolves the dynamic DNS entry every minute and updates its IPsec config whenever necessary (pretty much what pfSense does behind the scenes). Regards!

I'm wondering if this is a bug.  My phase 2 configuration works when phase 1 is PSK+XAuth.  The same phase 2 definition does not work when I change phase 1 to RSA+XAuth.  I can see phase 1 complete successfully and my user authenticates, but phase 2 fails with… Jul 23 22:00:35 racoon: [Self]: INFO: respond new phase 2 negotiation: hh.hh.hh.hh[4500]<=>cc.cc.cc.cc[33593] Jul 23 22:00:35 racoon: ERROR: failed to get sainfo. Jul 23 22:00:35 racoon: ERROR: failed to get sainfo. Jul 23 22:00:35 racoon: [[i]cc.cc.cc.cc] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1). If the phase 2 works with a psk phase 1, shouldn't it also work with an rsa phase 1?

Firewall rules for IPsec tunnel? Routing issue? Can you access any other resources (fileserver via smb etc.) through the S2S tunnel?

On a whim, I changed Policy Generation and Proposal Checking to Default and Encryption to Blowfish on both sides.  Tunnel's now showing up, but traffic's not routing.  I have an IPSec F/W rule allowing any/any on both F/Ws.  If I'm not mistaken, the Local Network and Remote Network fields on the IPSec Phase 2 configuration create a routing table so that if I try to access addresses on Site B from Site A (and my pfSense is my default gateway), it knows to route the traffic through the tunnel, right?  Should I expect to be able to reach my pfSense on Site B from Site A using the IP address of the LAN Interface?  I can when I VPN client to site, but not site to site. Thoughts?

HA within the VMs is always better than hypervisor-level HA, where you can cluster anything inside the VM it's best. Hypervisor-level HA most always reacts slower for failover (in pfSense scenarios at least), and it does nothing for you with upgrades or other maintenance needs within the VM. Most people don't bother with any kind of HA on the VMs for pfSense, they just setup their environment as such that the primary and secondary firewalls are always on different physical hosts. To clarify a bit - generally people do have the VMs set to start on another host if their host dies, one might consider that a form of "HA", I was more referring to features in certain hypervisors where the VM can run simultaneously on two physical hosts and quickly pick up if one host fails. That level of HA is a waste of hardware resources in most all cases IMO.

@cmb: It's odd because of the way it has to work. It has to match pre-NAT for the traffic to hit the portion of the kernel that's processing the IPsec. But the NAT portion is the only thing you're presenting on the P2 to the remote end. So it has both, hits pre-NAT, gets NATed, gets sent out. You don't need or want NAT in this case though, just add another phase 2 on both ends matching the tunnel network source. I'm lazy, so I do want to NAT. :) The remote end has a box terminating the tunnel, but it is not the default route.  So if I wanted to use the OpenVPN block without NAT, I'd have to do another round of static route wrangling to get the return traffic pointed at the remote IPSEC gateway instead of the default internet gateway.

and in 2.1.4 i am sure. Although I would like to see the pfsense side config you guys are using to compare with what I have

There is some gear out there that can do L2TP on its own for tunneling only. If the protocol run over L2TP is already encrypted, it's not a huge deal. On 2.2 to get L2TP+IPsec you setup L2TP and IPsec together using both options individually.

It looks like it is working now; had to turn off NAT on the IPSec interface because of the double NATting.  Failed to mention that client is running 2.2-Alpha an host is 2.1.4.  2.2 has a V1 or V2 option for IKE.  I was using V2 it needs to be V1.  Also, the IPSec widget on 2.2 does not report the tunnel up, when it is.  Even when the tunnels are up neither end shows a route in the routing table.

The only setting on pfSense is the NAT address entry. People have used many:1 (e.g. LAN/24 -> NAT/32 ) for connecting to other gear before, including large vendors and systems such as Verizon/AT&T for cell network backend connections. If that doesn't work with the Juniper settings, there may be something else that needs set on the Juniper side. Otherwise, try using a /24 for the NAT address/network and not a many:1 type NAT setup.

IPsec is dial-on-demand essentially, it won't come up until you send traffic matching a phase 2 to trigger it. That's why the keepalive IP exists in phase 2 entries, where the firewall has a local IP configured on the IPsec connection, it'll use it as the source to ping the remote IP defined in the P2 which will trigger negotiation of the VPN (doesn't matter whether the ping gets replies) to keep it connected all the time.

It's checking the output of setkey -D and setkey -DP and correlating the output with the defined tunnels. Check /etc/inc/ipsec.inc and look at the Phase 1 and Phase 2 status code.

Solved.