Well, doesn't matter now, I got it properly working using OpenVPN, took all of an hour including coffee time, vs IPsec which has been weeks in the making. Thank you for steering me into the light @Derelict

Well you should have everything at p3 anyway. I'm not aware of any particular issue between p2 and p3 though. Do you have any logs showing the negotiation failure from either end? Steve

You might get that to work with an IKEv1 Xauth style setup. It definitely will not work with IKEv2 EAP, though because EAP won't work with PAP.

@Konstanti Thank you! That clears it up! I will be using the settings on the IPsec interface tab.

It's normal to see extra copies in there depending on how the negotiation/rekey happened. As long as your traffic is flowing and the tunnel rekeys when needed and keeps going, it's not worth worrying about.

Solved, cause was a false configured policy at the Fortigate. In the policies for (incoming/outgoing) traffic the "NAT" switch was enabled. Why the fortigate choose the ip-adress of the DMZ interface instead the ip of the WAN interface is a mystery to me. So i was wrong when i said i don't have a Network with the IP 192.168.31.9. This IP was configured for an older test scenario but not used anymore and even the interface was not connected.

For anyone who is interested (n00b here), i got it to work (branch to pfsense only): Phase 1 remote subnet on pfsense has to be 0.0.0.0 with responder only option checked. on Huawei Side, the following command had to be configured: ipsec authentication sha2 compatible enable the result is: [image: 1565666662782-22accdc1-de10-456f-beb1-06c813df2382-image.png] The problem now is that pfsense does not direct traffic with destination to remote subnet (i.e. 10.2.20.0) through IPSec, it uses WAN0 for that. any ideas? [update] working now, was pinging from the wrong device.

You might also consider establishing a couple of hubs so you have redundancy and connect all other sites to both of those. A full mesh really does not scale well.

Each side should initiate when there is traffic matching the traffic selector. In many cases you can make this happen by setting an automatically ping host to something on the other side in each P2. (it just has to match the remote network - it doesn't actually have to respond to ping). Tunnels generally come up very quickly and the fact that the tunnel was not actually up when the traffic is initiated is not noticed by users or applications.

@Derelict doh Thanks a lot ... that was it ;) Thanks

Probably firewalls (think windows firewall) local on the hosts you are trying to ping. Or Anti-virus, endpoint protection, or some other software on the target host itself.

@chonkat Status >>> System Logs >>> VPN >>> L2TP Logins Is that what you are looking for?

And probably about time to ask on the D-Link forums instead of here.

@sepp_huber said in Schedules for IPSec tunnels: There is no feature to disable it, it must be deleted to stop billing ... and if you create it again you get a new configuration, not very cost efficient... That's why many people put pfSense in AWS and IPsec to that.

In case the change is not working, do we need to add an another change or bug request somewhere? Because the idea and feature is quite useful.

The looks like the ethernet LAN on the client.

You can ping from the pfSense GUI if one of the firewall interfaces is an interesting source for the traffic selector. For instance, if the pfSense LAN network is a local network in IPsec you just need to select LAN as the Source address in Diagnostics > Ping. It sets the -S flag to the ping command.