By the SPD.

You just create a transport mode IPsec connection specifying the same local and remote IP as the GRE, then your GRE is automatically within the IPsec transport.

Have been low on time to reply here, but the basics are:

Box B's "wan" would be the phase 2 local address on Box A's IPsec tunnel
Static route on Box A points 2.2.2.2/30 to Box B's LAN IP
Static route on Box B points 2.2.2.2/30 to Box A's WAN IP
Probably need to disable reply-to also.

The IPsec SPD prevents a routing loop as the traffic from Box A's WAN to Box B will match the P2 SPD between Box B's WAN IP and 2.2.2.2/30.

Beyond that it's hard to really lay out/describe on the forum, but it's something we're more than happy to help with on commercial support.

OK. I got it. I don't have to do route on pfsense box, the rule does it all, only my local station.

Supporting L2TP/IPsec (in a way that will allow remote access of Windows clients) under FreeBSD requires some work, check http://forums.freebsd.org/showthread.php?t=26755 for the details.

@cmb:

Phase 2 is separate (as it should be) in 2.x. Create the phase 1, then one or more phase 2.

Ahhh…. I didn't notice the 'add Phase 2'. Derp.

Thanks for pointing me in the right direction.

@SeventhSon:

you need to make sure that the local identifier matches the remote on the other end and vice versa

please can you explain more about this "identifier"
thank you

I'd also do a packet capture on WAN filtering on port 500 and make sure you have bidirectional communication between the sites on the ISAKMP (make sure everything one site is sending is received by the remote and vice versa). Modems or other things in line between the firewalls and the Internet can break that connectivity, and at times you'll lose the ability to communicate between site A and site B on the Internet in general even though the Internet at both sites otherwise works perfectly fine (that happens far more than I would have believed a few years back before our commercial support took off).

@SeventhSon:

Is this what you're trying to do:
http://www.seattleit.net/blog/pfsense-ipsec-vpn-gateway-amazon-vpc-bgp-routing/

LOL… Yes.  I actually followed that tutorial to get to where I am.

That tutorial is fantastic as it really does walk you through the process of setting up pfSense to work with Amazon VPC.  It does not however provide the information needed to allow hosts in the VPC subnet to route through the IPSEC tunnel, and then back out my pfSense to get to the internet.

That said...  I have figured it out.

The solution....

After getting the IPSEC tunnel working as described in the tutorial... You need to modify the VPC route table in AWS.  You need to add a default route for 0.0.0.0/0 and point the traffic to the AWS vpn gateway that is your IPSEC connection to AWS.  So  route 0.0.0.0/o to the vgw that was created.

Next you need to make a slight change to the IPSEC configuration on the pfSense side.
I had to change the second tunnel config to the following....
tunnel 0.0.0.0/0 10.9.0.0/16 ESP AES (128 bits) SHA1

10.9.0.0 is my VPC subnet.

Once this change was made and the IPSEC tunnels were restarted...  I can now have traffic from hosts on the VPC subnet traverse my IPSEC tunnel and go out my internet gateway.

This forum thread steered me in the right direction: http://forum.pfsense.org/index.php?topic=51057.0

You need to make sure you do three things:

1. Push a route to the remote IPsec subnet to the OpenVPN clients.
2. Add phase 2 entries to both ends of the IPsec tunnel that cover the OpenVPN clients
3. Make sure your OpenVPN and IPsec rules allow traffic between those subnets

How do I get traffic from the workstations to go through the tunnel?

I got it solved  ;D ;D ;D in phase 1 in advanced option I switched NAT Traversal from forced to Enabled.
then disabled Dead Peer Detection.

I have also used 3DES for Encryption algorithm now my mobile is connected to VPN 24/7 and is not DC at all.

@SectorNine50:

Now I'm curious as to why this was the case between these two boxes.  Can anyone give me a high-level explanation, or perhaps knows of some documentation that would explain this issue?

Sometimes there are paths between point A and point B on the Internet that have a lower MTU, and end up being a PMTUD black hole, which is especially common with IPsec. By MSS clamping, you're preventing the outer ESP from being too large for such a path by limiting the inner TCP.

you could simulate it with the limiter in pfSense:
http://doc.pfsense.org/index.php/Traffic_Shaping_Guide

limit the bandwidth to your expected speed
and the latency to something like 500 to 800ms in both directions

In the P1's My/Peer Identifier fields, put "My IP address" & "Peer IP address" respectively.

PS: Also keep in mind that DES and 3DES are different ciphers.

Off the top of my head I'd say that the issue is the virtual interface in p2.  Did you try mode: transport on the pfs side?

Also, I'm assuming the server does not require xauth; pfs won't handle that.