Hi You need to set the phase2 "Local Network" to the "Lan Subnet" option, and also - leave the tickbox for "Network List  Provide a list of accessible networks to clients" ticked - unless you want ALL traffic from the mobile client to be sent over the tunnel. Regards Ben

Ok thanks for the info.

Check Diagnostics > Routes - when you pick the interface for OpenVPN or IPsec, it adds a route to the peer's IP via that interface's gateway. Having two gateways on the same interface might be confusing that code. OpenVPN you can set for an interface of "any" and then it won't add a route like that.

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.