fix DTLS_OVERHEAD and GlobalProtect ESP overhead calculation

fix DTLS_OVERHEAD and GlobalProtect ESP overhead calculation

GlobalProtect doesn't try to calculate MTU until after it has information on
the ESP ciphersuite, so it can use the real HMAC/encryption key lengths when
calculating ESP overhead.  In practice, I have never seen or heard of a GP
VPN that uses anything other than AES128+SHA1, but both the clients and
servers appear to include support for AES256.

DTLS_OVERHEAD was not correctly accounting for possibility of AES256
(32-byte IV).

Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>