You cannot use a certificate without the Extended Key Usage attribute.
Well, that's not *strictly* true. It used to be that we didn't bother with these things because there were so many poorly-implemented, old, etc., versions of SSL out there that would be made unhappy by "newfangled" things. SSL has been supporting this very well for many years at this point, however, and any VPN service that isn't bothering with it ... well, it can be assumed that they do not give a crap about security, or are simply incompetent.
Part of the point of EKU is to prevent man-in-the-middle attacks.
If I want to compromise your VPN, and I can get in your transit path, then all I need to do is to sign up as an IncompetentVPN customer, and I get a certificate that isn't restricted to being a client. I then use my certificate to pretend to be a server facing you, crack open the SSL, and then use the same certificate as a client certificate into the IncompetentVPN service to relay the traffic. This is a very low cost attack.
All because someone was too lazy or incompetent to add a few bytes to a certificate.
Anyways, if this is the case,
it is possible to tell OpenVPN to ignore EKU, but that's a really bad idea, and it isn't clear to me where the message quoted in the first post is originating. I suspect it is a FreeNAS middleware sanity check of the certificate, and because this is not only a best practice but also an important factor in SSL security, I wouldn't hold high hopes of the developers removing the check, and even if they did, OpenVPN would still need to be tweaked.
It would be better to prevail upon the VPN provider to secure their stuff properly, or find a better vendor.
And it's still a bad idea to expose your NAS to the Internet, so maybe you should be thanking them instead.