@viktor_g L2TP Log file is attached l2tp.txt
I think it depends on the load on the channel, but not on the number of connections. At the now moment, 21 users are connected.

Finally found a fix for this. Adding a route as suggested by @corradolab was unnecessary as it turns out. This problem was irking me to no end as all other traffic was working well except SMB. I'd tested HTTP, FTP, ping e.t.c. to the LAN and all were working fine - just not SMB, and only SMB on Windows (macOS clients were fine).

I thought I might be running into this bug;

https://redmine.pfsense.org/issues/8964

But it actually turned out to be something in the way Windows authenticates to the server. To fix, you need to go to the Windows Credential Manager and add in the credentials for the SMB server before trying to connect.

After that it all works fine.

The problem seems to be the macOS and iOS clients. I found the answer in this thread here;

https://forum.netgate.com/topic/113422/ikev2-child-sa-beware-phase-2-dh-on-macos-ios

The answer seems to be to enable Perfect Forward Secrecy in the Apple Configurator profile.

Another question.
I have a client that connects from the outside, and needs to connect with a vpn to the existing ipsec.
What vpn should I create on Pfsense?

L2TP?

Is there any guide?

Thanks

@orangehand said in IPSec pfSense to Unifi USG:

As I posted elsewhere, you CANNOT test the VPN via the UI Ping utility. It always fails. You need to test the tunnel using endpoints. I am assuming this is a small bug?

Not a bug. If you are testing an IPsec tunnel and want to test from LAN to LAN you have to tell ping to source using an address in the LAN. If you leave it at the default it will follow the routing table and attempt to leave WAN (in most cases). So pick the LAN or whatever local interface has an address which will pass through the IPsec tunnel.

So it's doing exactly what it was told to do. That may not be what you wanted it to do, but it has no way to know that.

ITS WILL WORK, BCZ OUR COMPETITOR ALREADY DONE THAT

Probably because we fixed this: https://redmine.pfsense.org/issues/9243

It worked before because, technically, both sides were misconfigured :-)

That is not related to this thread, start a new thread for each of those questions separately.

This seems to be somewhat expected with VTIs and nothing to be too concerned about https://forum.netgate.com/post/795763

c62931b1-b5a5-4152-98d7-656347d1867d-image.png

"Leftauth" c'est bien pour l'authentification en local?

La valeur pubkey est-elle bonne?

wan mtu is set to 1500
mss clamping it set to 1380
I have offloading turned off
AES-NI is not active
I'll try aes-gcm

Cpu's are at 3-5% so not doing much.

Aha! I think I've got it. By switching to VTi mode I was able to make a gateway interface for it, and then do firewall rules. Not as simple but it works.

@lfoerster said in Possible IPSec routing issue:

So its more intelligent to place the static route NOT on 10.10.0.251 here, but on the default gateway both .251 and .2 devices (and probably all in the 10.10.0.0 segment) have configured.

Of course you were correct. I put a static route in the default GW on our side and it started to work immediately.

I do have to admit it gets me a little confused though, since I've been using static routes on clients before. And, while it says it's a headache when administering multiple clients (which we don't), this article says it should work:
https://docs.netgate.com/pfsense/en/latest/book/ipsec/site-to-site.html

Anyway, thanks a million!