It seems that your IPsec network addresses not NATed to WAN interface IP You need to create appropriate NAT rules

I give you a hint: https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients AES-256-CBC and MODP2048 Regards Alitai

@awebster Yup, that works wonderfully. Just did it, confirmed what our docs were suggesting. Now to have a chat with that peer armed with sufficient evidence. :) Thanks for all the help on this!

I try change mode from tunnel IPv4 to Route (VTI) but after change IPsec not connect.

I would start here.

Just create both phases of an IPSec tunnel in one. Settings are pretty intuitive. Then do the same at the other end, matching and reversing the relevant settings. Then test using endpoints, not the UI

shame on me found this Thread, solved it. https://forum.netgate.com/topic/146217/traffic-from-firewall-trough-ipsec-tunnel-fails/2

Update After doing some wireshark traces I concluded the traffic was not getting back to the phone. I was able to identify a routing issue that was causing the problem and resolve it. I have now been able to connect the Avaya VPN handset through the IPSec tunnel to my phone system. So just in case anyone else tries to set this up the the following settings in the Avaya handset work: VPN VENDOR - OTHER Gateway address - 0.0.0.0 (set by DHCP) External Phone IP Address 0.0.0.0 (set by DHCP) External Subnet - 0.0.0.0 (set by DHCP) External DNS - 0.0.0.0 (set by DHCP) Encapsulation - 4500-4500 Copy TOS - No Auth Type - PSK with XAUTH VPN User TYPE - any VPN User -vpnuser VPN PW - * IKE ID (Group Name) - none Pre-Shared Key (PSK) - * IKE Phase 1 IKE ID Type - IPV4 ADDRESS IKE Xchg Mode - Aggressive IKE DH GROUP - 2 IKE Encryption Alg - AES-256 IKE Auth Alg - SHA-1 IKE Config Mode - Enabled. IKE Phase 2 IPSEC PFS DH Group - No PFS IPSEC Encryption Alg - AES-256 IPSec Auth Alg - SHA-1 Protected Network - 0.0.0.0/0

No limit in the code, though there might be practical limits based on your specific set of circumstances. Perform normal troubleshooting and log evaluation and communication with the other side as to why that tunnel will not come up.

@jimp Perfect, works a treat! - thank you for your help!!

You don't have to check that box, but you can. IKEv2 is more efficient there, it doesn't need to separate all those out. Some other equipment (notably Cisco) doesn't like that, though.

Great Apply IP addresses and networks to all of that and show your configuration. Need to see all of the interfaces, all of the interface rules including IPsec tabs, all of the IPsec configuration, etc. Then explain exactly what is NOT working in a manner such that there is no guessing involved.

@denis31, I wouldn't expect many people on this forum to know what / how the Motorola RFS L2TPv3 link works, however, as luck would have it, I do. I'm assuming you have another RFS at the other end of the L2TPv3 link. I've never tried do to what you are looking to do with pfSense, I'd have to spin up a lab to have a crack at it. Ultimately, I'd suggest you have a rethink on how you can replace the L2TPv3 link with an IPSEC link. You can configure the RFS to run an IPSEC tunnel to pfSense, its not as simple to configure as L2TPv3 by any stretch, but it works. If you are using the L2TPv3 to do stuff like adopting remote APs, you will ultimately have to migrate your environment from Bridged tunnelling to Local egress.

Some more debugging on the fw: ping 192.168.2.145 Generates ICMP echo request packages on the gw interface (sk0/sk2), no ICMP echo reply is received (obviously). Result: ping command gets no answer. ping -S 192.168.1.10 192.168.2.145 Generates ICMP echo request packages on the ipsec interface (enc0) and the clients answers back with ICMP echo reply packages. Result: ping command is ok. route add 192.168.2.144/28 192.168.1.10 ping 192.168.2.145 Generates ICMP echo request packages on the ipsec interface (enc0) and the clients answers back with ICMP echo reply packages. Result: ping command is ok. BUT: Even with the above route, i can ping the client only from the fw itself, but not from the network. I`ve also tried playing with NAT rules to force the fw source address, but no lock so far. Any further idea to solve the problem?

ugh I'm not smart

Also, you might be better off using VTI.