Adding WAN interface removes active WAN interface from Default SNAT rule, taking network down

I saw this same issue too, but in my case, the simple act of clicking the update interface button would remove all other WAN interfaces and leave only the updated one in the default SNAT rule. And I have to manually readd them.

We have experienced this issue as well.  But it's not a reproducible issue so we just work past it. You never know which firewall it will happen with so how do you ever engage support? The basic support folks will just add the interface back to the NAT policy and say it's fixed without ever digging down to the root cause.

If this happens, could we collect the logs of the firewall? Get applog.log and csc.log and tell us the time, you change it. 

If this happens, could we collect the logs of the firewall? Get applog.log and csc.log and tell us the time, you change it. 

The final fix for me was to disable/remove the "Default SNAT IPv4" which has a description of "Updated automatically with WAN interface changes." which sounds like a promise to break things and ruin your day, and create an identical NAT rule (I have it at the bottom of my NAT rules list) having the Outbound interface set to "Any" only this time updating interfaces won't change the Outbound interface in the manually created rule.

Setting Outbound interfaces to Any will cause problems for VPN traffic in my experience.  Unless you setup a NAT rule above the final SNAT policy for that VPN traffic.

Funny thing is, it's the opposite in my environment because setting the interfaces to only the WAN interfaces by hand would cause VPN issues as it won't translate requests for the hidden tun0 interface and only setting it to Any would make VPN usable.

Out of curiosity, what would the NAT rule you suggest for VPN traffic include in its settings.