pfSense

Hi there,

in working around bug #5705, I noticed that if I update NAT rules ip's such that they no longer reference a carp vip, but DO NOT APPLY THE CHAGES, that was sufficient to coerce the gui to delete a carp vip.

This could put an admin in a sticky spot.

It might be more least-surprise-y to also check to see if there are pending NAT changes, ( Bonus points if this only triggers if the changes are impactful to the CARP VIP in question, but I'd still assert that the default behavior should encourage quiescing changes in one section of the config before applying others. )

While I can see merit to making several changes "at once" by queueing up changes in different parts of the UI and applying them in unison with a series of tab switching and clicking 'apply', I'd think that changes performed like this are more likely to be done by admins who maintain their config xml in some form of version control system. I'd envision these changes deployed as a config as a restore in one go, where these guards wouldn't come into play.

So, I still think the current behavior could bite someone, and that it wouldn't be hard or expensive to nerf this behavior a bit.