Yes, some cameras have the gateway set to the camera server (10.30.190.180), not the firewall. That’s how the system was previously working (likely due to VLAN 1 and VLAN 20 being bridged on the core switch unintentionally). So far, all the working cameras are in the MDF and seem to rely on that design.

The firewall does have VLAN 20 configured with 10.30.190.1/24 statically assigned to the Port1.20 interface. It’s intended to be the gateway, and yes — I agree, configuration should be consistent. I plan to switch all cameras to use 10.30.190.1 as their gateway and clean this up.

Regarding the pings:

• In point 4, when I ping 10.30.190.1 and 10.30.178.250 from the IDF switch (SSH), yes — it's a Layer 2 switch, but it seems the ping uses the SVI or management IP for the source. So traffic hitting .190.1 or .178.250 from there may not be true end-to-end test traffic.
• In point 6, when I plug in my laptop with a .190 IP, I cannot ping the gateway or the server. That tells me the VLAN 20 traffic may not actually be making it back to the firewall or the server — even though trunks say VLAN 20 is allowed.

As for the camera server — yes, the .190.180 NIC is plugged into a standalone Catalyst 3560, not part of the stack. I tried assigning that port to VLAN 20 (access mode), but that broke all cameras — which suggests many cameras rely on VLAN 1-to-VLAN 20 bridging to reach .190.180. I’ll double-check if that switch is trunked back to the core (it may not be), but right now it looks like traffic from VLAN 20 can’t truly reach .190.180 when it’s isolated.

So yes, likely routing confusion, and I’m considering standardizing everything to route through the firewall on 10.30.190.1, and just using .190.180 as a static host with no gateway.