If you disable the StrongSwan farp module, it appears to resolve the problem:
Oct 8 2018
Sorry for spamming this thread, but I found this bug report that might be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1488421
I've tested the above setup with 1.2.0-rc1 and the problem persists.
I've also managed to test ipsec/vti today by setting up a test environment like this:
Oct 7 2018
@syncer I would be happy to give it a try, even if it's a little risky for me. My router VM is running on an ESXi server, and when the ARP issue strikes I loose direct access to ESXi and have to go through the tunnel. That basically means that if the router VM breaks, I won't be able to access anything on that server. The server is located in a datacenter 1.500 km away.
Just a though... I noticed that vlesk has IPSEC tunnels over vti in his config, and so do I. I remember previous 1.2.0-rolling builds had issues with IPSEC/vti where the router wouldn't respond to ARP because of some routing table mumbo-jumbo I don't quite understand. This has since been worked-around, because it can't really be fixed at the moment.
I can confirm that the test image works for me as well.
I’ll see if I can test it tonight (CET) and report back.
I've tested radius authentication with L2TP on 1.2.0-rolling+201810060337 and it works. Not sure if you need a separate test with PPTP?
Oct 6 2018
I have the exact same problem since updating from 1.2.0-rolling+201805280337 to 1.2.0-rolling+201810060337. My VyOS VM is running on ESXi 6.5 with two virtual VMXNET3 interfaces. The (shared) physical interface is an Intel i210 Gigabit interface.