I hope you understand that you still have a basic chicken and egg problem:
Whichever solution you choose for encryption, you must also solve the startup problem - how do you supply the key at startup? Do you assume that someone is always available to unlock the encryption?
Imagine that you are on a business trip, but the power failed and you want to establish a VPN connection. If your system is able to startup on its own, it means that the key is accessible somewhere, obviating your encryption scheme.
If you have a way to supply the key remotely, you would need a backdoor to your network, since the UTM is down, waiting for someone to supply the key.
You could assume that the UTM and local power are sufficiently reliable that the need to unlock when nobody is there is a small risk.
( or ... if you are away and your UTM is down, call the NSA and ask them to enter the key for you. [:P] )
Even if the CPU has the Intel AES instruction set, there WILL be a measurable difference in performance; how much depends on the power of the CPU, and disk subsystem speed.
Correct, any kind of disk encryption is going to add overhead to the resources for encryption and decryption.
Frankly I don't see the need for this -- none of the other commercial vendors that are commonly used have such a feature.
Also correct, if I ran disk encryption on our enterprise Internet facing firewalls, they would stop working because of the amount of data flowing through them. It would probably do the same for my home UTM since I am running more services than just firewall, routing, and switching.
Some appliances have the means to protect the appliance from recovering the password and configuration, and then offload the syslog for a more complete security. Perhaps, an appliance is better suited for your physical security problems with a no service password-recovery type feature?
Or install your own encryption, make sure you have a resource capable computer to handle encryption overhead and all of the services you want to run?
