Hello,

I am trying to setup Open VPN on a 2926 on 3.9.0 F/W

Following This Guide https://www.draytek.com/support/knowledge-base/5392#3 and filling in the blanks from this guide. I have been able to get everything down to this one error.

"Fri Mar 22 18:02:34 2019 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info."

Does anyone know what this means or how to fix it?

The guide is by no means intuitive and I've had trouble configuring it myself. Without additional info, the following are just a few possibles gotchas from a non-PKI expert:

Is the client node definitely resolving to the Vigor (seriously) ?
Is the CN (common name) the same in all the certs you've created (including the server cert you've made on the Vigor) ?
Did you apply the cert template to all 3 certificates when you created ? (I would question using the cert template for the client end-point cert, but I think the guide does use it)
Are both ca.cert, client.cert and client.key in the same directory as the openvpn config file ?

BTW, which client are you using ? I did get OpenVPN working on Android but iOS had a hissy fit which may have been caused by the ca cert extensions being applied to the client cert (as above). Have had to resort to SSL VPN\IPSec until I can get OpenVPN to work consistently.

Maybe a little more support for cert\key management on the box is something we might see in the future!

From what I have read it seems to do with the introduction of "Man in the Middle" prevention.

To avoid a possible Man-in-the-Middle attack where an authorized client tries to connect to another client by impersonating the server, make sure to enforce some kind of server certificate verification by clients. There are currently five different ways of accomplishing this, listed in the order of preference:

[OpenVPN 2.1 and above]Build your server certificates with specific key usage and extended key usage. The RFC3280 determine that the following attributes should be provided for TLS connections:

However I have no idea how to do this with xca... or how to disable this check....

My bad, I said ca cert extensions rather than key usage. The guide uses ca template for the root ca cert\key (check) but also for the but also for the server (router cert). Not sure if that creates the server cert\key as a sub-ca, which is ideally what you would want, but it then creates the client cert\key as a ca, which is what iOS client seemed to be throwing a fit about. I'm currently experimenting with the various usage options and will post when I have something to show for rebuilding CAs into the we small hours. Please yell if you get there first!

Hey,

The warning is because Draytek hasn't implemented the tls-auth method for server certificate verification. It's used to mitigate DDoS attacks and doesn't harden the encryption at all.

fishenchips wrote: My bad, I said ca cert extensions rather than key usage. The guide uses ca template for the root ca cert\key (check) but also for the but also for the server (router cert). Not sure if that creates the server cert\key as a sub-ca, which is ideally what you would want, but it then creates the client cert\key as a ca, which is what iOS client seemed to be throwing a fit about. I'm currently experimenting with the various usage options and will post when I have something to show for rebuilding CAs into we small hours. Please yell if you get there first!

I'm not sure if I've read this correctly but in this tutorial, you create the signing authority within XCA and then create the server certificate via the Draytek interface. Then you take the CSR and sign the certificate with the CA within XCA and import the signed certificate with the CA into the Draytek router. The reason you're doing it this way is so you can generate client certificates signed with the CA as you can't do that currently with the Draytek router.

IMHO, the OpenVPN integration is poor, there's little visibility when things go wrong, EasyRSA3 doesn't seem to be supported, no support for tls-auth and all that fun stuff. I spent the whole weekend dissecting this and once I had it figured out as far as the SSL side my router now dies every time I try to connect with no reason in the logs. After investing 10+ hours into setting this up it was a bit deflating to have it crash. It looks like the implementation was rushed or only a small amount of time was invested in integrating the service into the routers. I hope they fix this in the next firmware release as OpenVPN would be a great addition to their products.

Hey drgr33n,

Thanks for the Reply.

Do you know how I can fix the issue with the "No server certificate verification" so that I can get it to complete the connection?
Is it possible to disable this check?