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.

Sounds like something is interfering with the traffic between the sites. Usually that's an indication that traffic is not getting through in one direction. Check the state tables and run some packet captures on the WAN looking at traffic while the tunnel is attempting to establish. Also, set your logs as described on the wiki, which should provide much more useful information: https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29

Most likely you need to set MSS clamping (VPN > IPsec, Advanced Settings tab), enable it and set it to 1300 or so. If that helps, you might raise it up a bit, 1400 or so and try again. Reset states between tests.

Thanks for looking! We have found that this is not an issue with IPSec, but a general issue with our connection to google compute platform. iperf benchmarking and wireshark analysis hints to a TCP window scaling problem. Not related to pfSense, not sure what it is related to honestly!!!

There is no way to assign them static addresses at this time. Perhaps the clients could be configured to self-register in a DNS server once connected? That would be a question for the client OS.

What does "only allows passthrough" mean? What, exactly, are you looking to do?

@J69ANT: Thanks for taking the time to reply, and i understand your theory behind Samba causing the slow down.. But the test where without the pfsense was still using SMB - just not behind a firewall - and that was hitting 13MB/s So although latency and SMB may be dragging the speed down, a SMB copy without the pfsense is a lot more than a copy behind it - hence the issue is the pfsense, not the SMB..? does my logic make sense ? thanks In that case, try to discover the overhead created by the IPSec encapsulation and lower the endpoints' MTU to the value that would prevent pfSense from having to fragment the packets. Whereas IPSec encryption can be offloaded to hardware, IP fragmentation and reassembly is done in software. Use the ping command with the DF flag set and ping host-to-host across the VPN tunnel. Keep lowering the payload length value specified in the ping command until your ping gets a response. The TCP + ICMP header overhead is 28 Bytes. So, start with the payload length of 1472 Bytes and keep lowering the length until you stop getting a response that the packet needs fragmentation but that the DF bit is set and instead get an ICMP response. Once you figure out the the ICMP payload length that goes through the VPN tunnel without fragmentation, you can add 28 Bytes to that value and set the total value as the MTU on the hosts. Then try to run SMB file transfer again and see if the speed of transfer has increased.

Sorry that didn't work for you.  To get our VPN working, I just followed instructions here: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

Config on my side - openwrt was made by me - i prefer to make networks as separate SA because managing is for me better. Split connection is ok - after this works well but in status is strange. - attached status. The main connection is as disconnected but appear new without name and this new have SA . [image: screen.png] [image: screen.png] [image: screen.png_thumb]

As I mentioned above, I have completely removed and re-added the configuration at both ends.

Thanks, through the process of trying to figure out how to get a connection to AWS, we installed the OpenBGP package then retried the wizard.  Viola, it worked! We saw no errors anywhere else in the interface and the system is very stable.  This router is our main gateway for the company, so resetting would be a major PIA. So, while we're working now after installing that package.  I don't know if that package is required for the AWS Wizard to work or if the process to install that package corrected the pkg-utils.inc issue.

No, there is no mechanism in L2TP for this – It's 100% up to the client. You can probably script some routing to happen on connect on the client side, but the firewall (or any L2TP server) can't send routes.