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!

I finally got around to this and it's working great. Thank you. If I wanted to route all internet traffic through the site-to-site VPN, is this article still valid? https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel#Configure_outbound_NAT At the end, it says to modify the Outbound NAT at Site B (where you want your Internet traffic to exit), even though you want Site A to use the Internet at Site B. Is that still correct? Edit: This worked perfectly, I missed where it said to add a route of 0.0.0.0/0 at Site A, thus my confusion.

pfSense defaults work fine, considering you replicated the settings correctly on RouterOS.

Turn up the logging on both sides as detailed here: https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29 Usually that would mean either there is a mismatch or it's not matching the connection properly (remote gateway and identifier are not matching)

Hm, at least Strongswan should be able to do what we need : https://www.strongswan.org/testing/testresults/ipv6/net2net-ip4-in-ip6-ikev2/ So it is not possible with the GUI settings or is it prevented by some other conflict? Any idea? Thanks Andreas

You can do this with gateway groups and dynamic DNS, but it is not very reliable. The best way to do it is to set up GRE tunnels over IPsec transport mode, with OSPF on top of it to handle the routing.

Hi daxpfacc, thank you for that hint. I just added both the OpenVPN and IPsec Subnets and allowed queries, but it still does not work. Kind regards, Jannik

Glad to have helped