Are you using IPSec client built into Windows running Windows 10 ikev2?

Doh! The ipsec firewall rule on remote. Fsck, forgot about that little gem. Thanks!

I already use OpenVPN BUT I like IPSec at lot more. I like that it's intergrated in my devices and I don't need third party software for like Mac and etc. I actually have this problem with my OpenVPN as well.

Small update: I've tried now adding a Virtual IP on HQ, it's the exact same behaviour as for IPsec (i.e. settings are not saved/updated). What's even stranger is that HQ is actually a pair of Netgate SG-4860 in an HA pair. They both behave like this. AGain, any help would be greatly appreciated

Yep, finally saw what was happening there. I'm not sure how it didn't happen to me previously. In that case it affects several pages. I was looking for a bug ticket for this, remembering this thread but misremembered it as a redmine ticket.

Yeah there's a status display issue in that case. There is a bug ticket open on general issue there. https://redmine.pfsense.org/issues/6335 It'll work fine, the status output's just wrong on the "down" one.

Good suggestions. Below is the iptables output from the host that runs all the VM's. There are two address ranges in use here: 192.168.5.0/24 which is the intended network, all devices should operate on this one ideally 192.168.12.0/24 the second ip range created for the VM guests to operate in as a work around to this issue. 192.168.122.0/24 I have not idea what this is, given the limited range I assume it would not be causing any issues. Does this seem correct? service iptables status Table: nat Chain PREROUTING (policy ACCEPT) num  target    prot opt source              destination        Chain POSTROUTING (policy ACCEPT) num  target    prot opt source              destination        1    MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 2    MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535 3    MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    Chain OUTPUT (policy ACCEPT) num  target    prot opt source              destination        Table: mangle Chain PREROUTING (policy ACCEPT) num  target    prot opt source              destination        Chain INPUT (policy ACCEPT) num  target    prot opt source              destination        Chain FORWARD (policy ACCEPT) num  target    prot opt source              destination        Chain OUTPUT (policy ACCEPT) num  target    prot opt source              destination        Chain POSTROUTING (policy ACCEPT) num  target    prot opt source              destination        1    CHECKSUM  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:68 CHECKSUM fill Table: filter Chain INPUT (policy ACCEPT) num  target    prot opt source              destination        1    ACCEPT    udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:53 2    ACCEPT    tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:53 3    ACCEPT    udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:67 4    ACCEPT    tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:67 5    ACCEPT    udp  --  192.168.5.0/24      0.0.0.0/0          state NEW multiport dports 111,892,2049,32769 6    ACCEPT    tcp  --  192.168.5.0/24      0.0.0.0/0          state NEW multiport dports 111,892,2049,32803 Chain FORWARD (policy ACCEPT) num  target    prot opt source              destination        1    ACCEPT    all  --  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED 2    ACCEPT    all  --  192.168.122.0/24    0.0.0.0/0          3    ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0          4    REJECT    all  --  0.0.0.0/0            0.0.0.0/0          reject-with icmp-port-unreachable 5    REJECT    all  --  0.0.0.0/0            0.0.0.0/0          reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) num  target    prot opt source              destination       

The same issue here. Upd. Solved it by adding appropriate p2 entries.

Guessing you probably have a static route pointing to the LAN IP to force the box itself to source traffic to the VPN to the right IP. That sends an ICMP redirect that causes some Linux kernels to ARP that as a local subnet. System>Advanced, System Tunables, set net.inet.ip.redirect to value 0. Save and apply changes. Might need to reboot the NAS for it to lose the route it picked up.

No comments at all? NOBODY has ever met this issue, seeing TSP resets during a failover and state lost? Anyone???

Hi, I have this working with multiple DrayTek firewalls. If you are willing to provide me remote access to both your firewalls I'm happy to get this up and running for you. Jonathan.

Set it all up using OpenVPN.  Working great!  I had to fiddle with my outbound NAT rules a bit, but got it working.  Can telnet to port 25 all day long now.

Change your hashing to AES-XCBC because that will get accelerated by AES-NI since it's AES (of course). The hashing algorithm really doesn't matter that much, because an attacker still needs to break to break the encryption layer, so AES-XCBC is perfectly fine and will be accelerated by AES-NI. Everyone should always choose AES-XCBC when using AES-GCM. I hope that helps.

OK, fixed it - for anyone else trying a setup like this, the key for me was to set the Local Network setting to WAN network instead of LAN network, and setting NAT/BINAT to "none." Working like a champ now!