Just a quick update on this - I had been testing with my laptop and couldn't get this working and had to plug into something else so put the connection onto an IP phone (which is what the VPN is for). And it came to life! I then tried to send a ping from the phone to the end system across the VPN, and the issue came back. Took the cable out of the phone to reset it, back in, and now it's working again. So I'm now wondering if there's some erroneous NAT occurring on my end. If anyone has seen something like this before though, any responses would still be great. Thanks! Andy

Thank you for your quick reply. Had the same problem scottzech posted and I will probably use OpenVPN now.

It is possible and should work just fine. I did not test this setup myself on the pfSense however use Fortigate in the corporate environment. It is very popular setup where remote sites are connected to central VPN CONCRENTRATOR and that VPN concentrator is responsible for routing between sites. Remote end-points do not have any additional VPN connections to each other… Worth trying. Please share your findings after you implement this.

@manxam: From the host, I cannot ping any remote host including the router (10.10.10.1) Can you please verify TCP/IP settings on that host. You should be able to ping devices in the same subnet (router) with correct settings…

You know, as long as IPSec still works I'll just recreate everything from scratch.  The old one has been running since at least 1.2.3 so I wouldn't be at all surprised if some incompatibility finally crept in.  I'm not even going to worry with diagnosing it. Thanks for the reply.  :)

OpenVPN is OpenVPN. You will not find a tutorial for pfSense to every vendor out there. Is there a tutorial on Sophos' site for Sophos to pfSense? https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

That client is not liking the transforms you have configured: Sep 30 16:24:48 05[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built If you set VPN > IPsec, Advanced settings logs to IKE SA, IKE Child SA, and Configuration backend to Diag leaving all others at Control you will get more logging about that exchange. It should show you what the Android device will accept.

added the VIP under identifiers for the IPSEC? By default they are the IP, if you change peer/local to example KEY_ID and then the designated identifiers, they also need to be matched on the other site. I used KEY_ID on my PFsense but on the sonicwall remote VPN, it was registering as FQDN ( ??? ??? ??? ??? ??? ) I had to change the sonicwall identifiers as FQDN instead lol. Remote GW is always the public IP of the other ends VPN tunnel, not a virtual IP, as it's created internally to use from the remote site.

Found something: https://redmine.pfsense.org/issues/4849 => https://forum.pfsense.org/index.php?topic=95573.0 =>https://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 =>https://doc.pfsense.org/index.php/What_should_I_ping_for_IPsec_Keep_Alive It's not a bug, it's a feature  ;)

Thank you very much. I don't understand where the .84 is coming from (we should have only .83), I'll check with the guy in charge of the firewall on the other site.

That was left over from trying to get DNS working over vpn, so I removed the gateway/route. The issue however was the VM's on Xenserver.  After rebooting them, they are now able to be accessed from the VPN.  I have no idea what happened, but likely not the fault of the AWS tunnel.  I will keep this post in case the problem comes back when we recreate the AWS tunnel.

small typo on the diagram, the 1:1 NAT goes to the pfsense "WAN" IP 10.1.1.1

It can be done, but it is a bit more complicated than that. Regular IPsec cannot be managed through the regular routes. You could setup GRE tunnels over IPsec transport mode between the public IPs. Then use a routing protocol (like RIP or OSPF) to actually handle the routing and failover

Ok, resolved it. The IPsec firewall rules setup to allow the traffic excluded UDP protocol.  I changed it to be like this: protocol: IPV4 * source: 10.3.0.0/24 Also, the static route mentioned previously in my post was not necessary.  I did not see the need for it.  I believe it was for another issue. You should also be aware of the following https://redmine.pfsense.org/issues/4418 bug which affects DNS resolving.  As a workaround I had to remove the default DNS domain and entered it twice separated by a space in the split DNS field.

Hi Swix, Thought i'd post as i was doing the exact same thing. I got mine working so it can happen. Not sure on your setup we have a routed subnet going to dual pfsense with CARP. For the purposes of below we are using the following, also note we are not using NAT at all. Public /29 P1.x.x.x (CARP P1.x.x.3 Routed Subnet to above P2.x.x.x /25 Example IP on a server would be P2.1.1.1 The tunnel would look like below. Phase 1 - Peer ID = CARP IP P1.x.x.3 Phase 2 - Local = P2.1.1.1/32 Phase 2 - Remote network = 192.168.10.0/24 Remote site would be configured as below Phase 1 - remote gateway = P1.x.x.3 Phase 2 - Local = 192.168.10.0/24 Phase 2 - Remote network = P2.1.1.1/32 So we have the entire /24 subnet able to connect to the public IP via the VPN.