Not sure what you mean by IP alias of localhost. It's a Virtual IP Address/IP Alias configured on the WAN interface. It is then chosen in the interface entry of Phase 1, instead of the WAN interface. The reason I do this is to avoid exposing the Mobile VPN on the router's primary IP address.

@gustavo7w: Googling I found that the problem with smb protocol can be fixed changing MTU value. We've also transferred large files with SFTP or SCP and it doesn't have the same speed issues as SMB.  That may be an option for you too.

The problem still exists in 2.2.5.  Upgraded from the Development stream to the production version on Friday and today the tunnels are inoperative and can not be restarted.  The IPSEC task can not be stopped from the GUI or from the command line and the only option is to reboot pfsense.

Thanks for the info. I just used the Apple configurator to use AES256/SHA2…but it seems my Windows 10 VPN wants to use DH group2 (1024). Is there an easy way I can change win10 VPN client to use group 21 DH?

Thanks Itctech. Added 256. I have discovered that the issue is that the iPhone does not like ".me" addresses. Perhaps it does some pre-validation on the device.  I have just registered a .com address and it connects to the server. However using the .me (which is with the same registry and the sme dynamic ns provider and pointing to the same IP) it fails to connect at all. Looks like an Apple issue. So, now I can connect no problems!  Both from my windows tablet AND my iPhone!  YAY!!!!! Thankyou so much for your help.

Ensure that you have put in static routes in AWS VPC for the network on pfSense. Ensure that they have propagated into your routing table on AWS. Check that your Network ACLs and Security Groups allow traffic from the pfSense network to your AWS subnets. Check that the AWS instances don't have a firewall configured that blocks your traffic too.

Just realized I posted it in the wrong subforum. If a mod can move it to IPSEC that would be great. Looks like someone requested this functionality four months ago: https://redmine.pfsense.org/issues/4826 Something as simple as "Auto" in AES selection box on Phase 1 that replicates the proposals for each strength would probably work too.

@cmb: The most significant leaks are now fixed in 2.2.5. Well, we've patched around them, anyway.

What exactly didn't work? And are you certain it was the firewall that didn't work? L2TP/IPsec client support is extremely inconsistent and in some cases broken. Move on to IKEv2… L2TP/IPsec isn't worth the trouble.

EAP-TLS is IKEv2 with per-user certificates.

Check your phase 1 and phase 2 lifetimes, sounds like there is a mismatch.

@David_W: As jimp has stated in the forums several times recently, IPsec using IKEv2 is probably a better option than L2TP/IPsec at this point. I have no problems using Windows 7 Professional clients with pfSense's IKEv2 support. Ok did that, and it worked ^^

i am doing it another way now, i am just using "mutual PSK" for authentication but i still cant get it to connect got screenshots incase it helps ipsec_site.zip

I believe it has to do with the nat rules in the asa you need to tell the asa that any traffic destined for the tunnel cannot go out the wan interface. I did it once don't remember the exact steps however.

Assuming that A, B, and C are all running pfSense it's relatively straightforward. Example LANs: Router A -> 10.10.0.0/24 Router B -> 10.20.0.0/24 Router C -> 10.30.0.0/24 Router A –--------- Phase 1 on A heading to B has two child Phase 2 1. 10.10.0.0/24 -> 10.20.0.0/24 2. 10.10.0.0/24 -> 10.30.0.0/24 Router B (B must know what to do with transiting traffic, this is probably what you're missing) Phase 1 on B heading to A has two child Phase 2 1. 10.20.0.0/24 -> 10.10.0.0/24 2. 10.30.0.0/24 -> 10.10.0.0/24 (C -> A Transit) Phase 1 on B heading to C has two child Phase 2 1. 10.20.0.0/24 -> 10.30.0.0/24 2. 10.10.0.0/24 -> 10.30.0.0/24 (A -> C Transit) Router C Phase 1 on C heading to B has two child Phase 2 1. 10.30.0.0/24 -> 10.20.0.0/24 2. 10.30.0.0/24 -> 10.10.0.0/24 Also make sure that under Firewall -> Rules -> IPSEC that you pass IPSEC traffic for anything (all asterisks in all columns) on all routers. After getting the tunnels up you can make finer grained rules if you want.

That's probably not what you want for a site to site connection. There are a variety of potential routing complications. The Draytek should support a proper site to site IPsec connection without L2TP's inherent complications, use that instead.