@flimadigital said in IPSEC VPN WITH NAT S2S:

This ip has a configured NAT that takes everything from 192.168.249.29 and plays to the network 192.168.200.0/24

I don't exactly understand what you mean by this but I assume the client wants your clients to connect via a single IP (192.168.249.29) so it can create firewall rules accordingly. To do that, you have to NAT your connection in your phase 2 settings.

Your clients P2:

local network: 192,168.200.0/24 remote network: 192.168.249.29/32
etc. etc.

Your own P2 setting:

local network: 172.16.0.0/16 NAT setting enabled with "address" selected: 192.168.249.29 (/32) remote network: 192.168.200.0/24

Hope that clears it up and I understood correctly that you want to NAT to a single IP.

After month of a working vpn my HDD was destroyed and I had no backup, I used the bad thing to turn it into something good - a clean pfSense and a perfect setup.

But now I have some trouble with the Encryption.

I currently use for phase 1 :

AES 256bits SHA384 DH:20

And for Phase 2 :

AES 256bits SHA384 DH:20

Is this secure enough?

When I try to follow the tutorial it doesnt work. The Hash algorithm is also grey in Apple Configurator when I chose AES-256 GCM.

Where is my mistake?

@0daymaster set MTU to 1380 or 1400 on both sides

pfSense supports AES-NI and cryptodev accelerators
see https://docs.netgate.com/pfsense/en/latest/hardware/cryptographic-accelerator-support.html

SG-3100 and above NetGate appliances have crypto accelerators:
https://store.netgate.com/pfSense/systems.aspx

@jimp good to know, thanks jimp.

@Derelict said in ASA 5505 / pfsense only one Phase 2 traffic passing at a time; swaps:

You absolutely need split tunneling enabled to do multiple IKEv2 selectors to an ASA. The ASA is the reason that checkbox exists in the first place. So leave that enabled.

I figured as much and haven't turned this off.

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.