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.

It is a bug? I dont think so. FreeBSD kernel just drop packet with bad checksum. This is problem with NAT. So, maybe will be ignoring checksum nice to have feature, but in this case you must manualy put registry key in to windows : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent AssumeUDPEncapsulationContextOnSendRule dword:2 And you cant be sure, that will working another devices (iOS, android with specific version, MacOSX etc.). So, I surrende and I will have public IP directly on pfSense. Max PS: I think, that many people use pfSense for IPSEC (IPSEC working very nice behind NAT) and many people know NAT problems, so I think that many users use public IP on pfSense

hello Jimp, You were right, i bought some new hardware using intel network cards. It has been up for 2 days with no problem. I hope it stays that way…... it was sooooo frustrating. Thank you very much

Make sure your firewall rule on the IPsec tab allows all protocols (or at least both TCP and UDP) to a destination of */any, and also check your outbound NAT to be sure the source network used by the mobile clients is covered.

Sadly that did not work. I seem to still show the IPv6 address that T-Mobile is providing. I found a site that shows a IPv4 address and it is not my VPN servers IP address either. I can see the IPv4 addressed machines on my local network when the VPN connects. I will say I am puzzled.

after the passing all screen capture i restart both side and it is working please i wuold like that administrator of this forum lock this part who need help same subject in the future thanks derelict.

If you just want IPsec, you can find that in /var/etc/ipsec/ipsec.conf in the format used by strongSwan