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.

Not sure what you mean. You may be better posting here:- https://forum.netgate.com/category/67/pfsense-international-support

@trasher-mx Then you need to show / check the phase 2 settings on both sides of the tunnel and show/check the rules on the openvpn interface Or using tcpdump to find the place where the packets are blocked

@marama So, you can try to use Policy NAT with some pseudo net which translates to 192.168.0.0/24 of WAN (10.0.0.0/24 in example): Port Forward with source field: [image: 1567415078099-screenshot-from-2019-09-02-12-04-07.png] or 1:1 NAT with destination field

AWS config problem - I reinsntalled pfsense on AWS carefully following instructions and resolved most of the issues. Still had to tweak the elastic IP assignment to get the LAN assignment to be available in pfsense. The instructions seem to indicate that the elastic ip should be assigned to an interface in AWS but when I changed it to be assigned to the pfsense instance then the ip showed up as a network interface in pFsense.

Few complements (i haven't have solved the issue) I see the following states vtnet4 icmp 10.45.226.1:15026 (172.20.74.31:47548) -> 10.45.226.3:15026 0:0 enc0 icmp 10.45.226.3:47548 (10.100.45.2:47548) <- 172.20.74.31:47548 0:0 where enc0 is ipsec i assume and vtnet4 is the LAN interface. This issue is driving me mad, i can provide schemes, and answer to anyone willing to help.

Either the states are being removed or you have some asymmetric routing happening that is cutting off the connection after the half-open state times out.