I think all those are anti-features on a network slug.
As I understand it, the device is intentionally simple because it is there to ensure some misconfiguration cannot expose some port that should not be exposed.
I have implemented firewalls similar to this in the past. They typically had three network interfaces. Two of them were configured as bridges and then I use ebtables/iptables to filter traffic flowing through. These two interfaces would have no IP address and would not be visible on a traceroute, etc.
The third interface would only be connected to a separate admin network. Or it might not even be plugged in. In the latter case, the admin needing to change anything on the device would have to be physically present and bring a "crossover" ethernet cable and plug their laptop directly into the third NIC of the firewall. From there, they would be able to ssh into the firewall and change config.
A network slug does not have an IP address. You cannot connect to it over the network. I'm not sure you understand what the device is and what it does.
Let me give you an example - I have a "port 22 slug" and what it does is block all traffic of all kinds except for TCP22. That's it. It does nothing else and it does it transparently without having an IP address of its own. If I wanted to reconfigure it, I would connect with a serial console.
It also does “waterfall” egress packet delaying.