Ran across this error this morning while tweaking some VPN tunnels in my setup and thought I'd throw this up for people in my boat.
Background:
I recently added a secondary ISP to my Head Office to offload some traffic from our WAN which was getting swamped. We use Uplink Balancing and multipathing for the traffic flowing through the UTM
I'd had some issues getting the VPN tunnels to connect to the new IP. The error line noted in the subject kept showing up in the live logs of the remote end of the VPN. It turns out that the UTM was accepting inbound traffic from the remote UTM on ISP2, but transmitting back over ISP1. Causing the remote UTM to have fits.
Solution:
Turned out that the order of the active interfaces in the Uplink balancing screen is important. Once ISP2 was listed first, traffic started flowing again. To also be absolutely sure traffic stays on ISP2, after I adjusted my uplink order, I also set a multi-path rule to force IPSEC traffic over ISP2. It may well only need the multi-path rules but I noticed uplink balancing seemed to play a role as well.
Also as a side note, if you are setting up IPSEC where the central hub has multiple ISPs, make sure each remote IPSEC node uses an availability group with the preferred ISP in first place (in my case ISP2). Combined with the multipathing rules it should fail over to the backup ISP if the main ISP goes down.
This thread was automatically locked due to age.
