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.

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