Syncing projectiles is a pretty frustrating topic for networking code. I've attempted to tackle similar problems a few different ways, each with their own issues.
One way I've tried is to have the actual synced projectile object invisible. Each peer will create their own visible sprite for the projectile locally, that is not synced but should behave synchronously. It can be accelerated towards the actual (invisible) synced projectile over time, to fudge latency. This is in effect putting a second layer of local input prediction and interpolation net code on top of the built in one, but you get a little more control over how you want it to appear for each peer. It is a tradeoff between "looking right" when network conditions are good and desync artifacts when network connections are bad.
Another way is to delay the destruction of the projectile. You can simulate its destruction with an animation or setting it invisible and disabling its behaviors/events, but this gives peers some time to catch up before it actually gets destroyed.
The last way I've tried is to simply not sync the projectile at all, only the input and the result. Let each peer display what it thinks should have happened to the projectile. This works best when you can fudge the visuals and precision isn't as important, so probably not the best for a top down tank game.
One fairly common method that doesn't work with the built multiplayer object's method of syncing is to run a lockstep simulation, where everything is deterministic and can be recreated accurately on each peer. There are pretty much always syncing issues that build up over time due to the differences in hardware though, so corrections are made periodically by peers checking in with the host. I think this works best when input lag is acceptable (no local input prediction).