What are you pinging from the Debian PC?
You have no ip addresses configured on the CRS510.
If that's because you removed it from the config, then I am not going to be able to help. No one can troubleshoot with bad information.
If you just take the default config, (if the CRS510 has one, I don't know since I don't have one. Some "advanced" devices don't provide one, as they expect the users to know how to configure it) However, since your config does have some lines with comment=defconf that appears those lines came from the default config.
Usually, the default config will configure ether1 as the WAN interface and all other ports as part of the bridge. and the bridge does not have vlan-filtering enabled. See this for the behavior when the bridge is not vlan-aware.
But in default config, the bridge will have an ip address of 192.168.88.1/24
When the bridge has vlan-filtering=no, then it is just passing ethernet frames as is. It will pass standard untagged ethenet frames as well as IEEE 802.1Q tagged frames; it just won't allow any tag processing, i.e. tags will not be added or removed by the "bridge" when it is not vlan-aware.
The vlan interfaces (in the linux kernel) will tag egress traffic and untag ingress traffic.
The point being, for the specific case you show in your diagram, ether1 (a bridge port due to this part of the config:
/interface bridge port
add bridge=bridgeLocal comment=Admin frame-types=\
admit-only-untagged-and-priority-tagged ingress-filtering=no interface=\
ether1 mvrp-applicant-state=non-participant mvrp-registrar-state=fixed \
pvid=4
Note that anything to do with vlans is ignored when vlan-filtering=no. In this part, that's the "frame-types=admit-only-tagged-and-priority-tagged", "ingress-filtering=no", and "pvid=4", and they are all ignored when the bridge/switch is operating in non-vlan-aware mode (vlan-filtering=no)
So what does all this mean? Before you turn on vlan-filtering, and you are using a non-vlan-aware device, then the only interface you can communicate with is the bridge interface itself. The only way to communicate with the vlan interfaces is with tagged traffic (which the vlan interface will recognize traffic to it (because it sees the tag) and the tag is then removed, and the untagged version is delivered to the linux ip stack and associated with the vlan-interface.
So before vlan-filtering was turned on, if you were getting a ping response, it was coming from the ip address associated with the bridgeLocal interface, not the MGMT-4 vlan interace associated with vlan 4.
As soon as you turn on vlan-filtering, then you will be connected to a different interface, MGMT-4 which needs a different ip address, and is probably in a different subnet (at least in most cases it should be).
If this still isn't enought to get you going, please follow the instructions to leave the ip addresses in. Just make sure that you keep ip addresses in the same networks, and that there is a one-to-one mapping between you obfuscated ip addresses and your "hidden" private ones. In my opinion, trying to mask private ip addresses is a bit of a waste of time. But if you want to, then replace the first 3 octets with 192.168.0, 192,168.1, and 192.168.
E.g. if your bridge currently has an ip address of 192.168.88.1/24 and you want to hide that fact, then use an editor to do a global replace of 192.168.88. with 192.168.0. etc. But at least then you can show us the complete config, (leave your sn redated, that has no effect on the local troubleshooting).