@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.

I am having the same issue as well, is there anyway to find out why are these errors are showing up ? I have some difficulty connecting my phone to a SIP registrar server over VPN . sometimes it registers and others it says request time out !

Is there any way to make that service restart on every hour ?

I would suspect firewall rules above anything else. If it were a problem in IPsec, it wouldn't work in either direction. Or perhaps this? http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

I have solved the issue, from the log it seems there is some files missing after I have restored the configuration to Pfsense. In one of the forums i noticed that this issue might be caused if you have installed FreeRadius2 package however I had it installed but I uninstalled it. Now I re-installed the package and I could normally start the IPSEC/Racoon service Normally. Here's the failing log: Aug 29 14:29:07 php: /status_services.php: Forcefully reloading IPsec racoon daemon Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -FP' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"' Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -F' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"' Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/racoon -d -v -f /var/etc/racoon.conf' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"' Aug 29 14:29:07 php: /status_services.php: The command '/usr/local/sbin/setkey -f /var/etc/spd.conf' returned exit code '1', the output was '/libexec/ld-elf.so.1: Shared object "libsasl2.so.2" not found, required by "libldap-2.4.so.8"' Here's after I installed Freeradius2 Aug 29 14:40:43 php: /vpn_ipsec_phase2.php: Could not determine VPN endpoint for '' Aug 29 14:40:43 check_reload_status: Syncing firewall Aug 29 14:40:53 php: /vpn_ipsec.php: Could not determine VPN endpoint for '' Aug 29 14:40:53 check_reload_status: Reloading filter

or even a roadwarrior with x509 would be great. Thats a shame.