Responding from my newer account since I previously commented in this thread.
@John, let support help I guess, but really, just check with whoever is managing your firewall(s) and look for IDS/IPS activity during your backup times. You can hunt this down with Wireshark sure, but I think it's overkill. Since Veeam will just repeatedly try the same block over and over, you should get a huge chunk in the logging about blocked activity. For clients of ours we catch this all the time just by checking the firewall logs.
And to be clear, my understanding of the issue is that there's no need for any changes to have happened to the firewall/av. The data going into a backup file ends up with more or less "random" looking blocks, but each time the same block that triggers IDS/IPS is resent until Veeam is instructed to send a different one (which is why Active Fulls fix this, since it's different data blocks then). Since signature based threat detection is always a ratio of speed:uniqueness, algorithms that favor speed inevitably have hash collisions between legitimate data and malicious data. And basic probability tells us that the likelihood of a collision happening multiple times is independent of the number of times in a period; you can get hot streaks of "luck" like this.
@Gostev; I suppose the way they probably do it is via monitoring TTL on the RSTs, as shown in this article:
https://medium.com/@pjperez/the-ttl-trick-c78f1279817d
tldr; - TTL value will tell you what sent the RST packet; windows typically uses 128, Linux typically 64, networking gear will have their own preferences. If you see RST with TTL of 128, it's local firewall. 127 would be some server in between, something like 255 is some network gear 1 hop away.