Hi there, I have a Vigor 2860n router using l2tp/ipsec but would like to change to IPSEC X509 authentication to use primarily with Android mobile devices etc. I have looked through the manual and asked the Draytek support but am still confused as to how to create the certs for use with the mobiles, what do to with them. If anyone could explain or direct me to a for dummies guide that would help a lot. I know how to create a Root CA and a local cert in the router options but apparently this isn't correct. If any apps are needed I use Windows.

Any help is greatly appreciated.

I don't think there is a "dummy's" guide ... it's a bleedin' complicated topic!

My status wrt to this, is 'enthusiastic novice' ... but your message prompted me to look at it, since I'm currently playing around with digital certificates and the like. (I set up a Microsoft Certificate Authority 5 years ago...and the Root Certificate just expired. Attempts to generate certificates that Chrome thinks are vaguely plausible resulted in it all having to be reinstalled. That caused mayhem )

Anyway, I digress.

From what I can make out, the key (excuse the pun) to using certificates for VPN authentication, lies with the 'IPSec Peer Id' functionality. This seems to provide the mechanism for mapping a certificate to a user. (It doesn't seem (to me) like it allows very fine granularity though - maybe more suited to mapping a group of users, to a single Teleworker profile. I could well be wrong!)

You need to decide where you're going to get your certificates from. (They won't be "self-signed" as such, they'll be signed by Certificate Authority of some description). A commercial site (whose Root Certificate is already trusted by Android) would be easiest. Also, I'd have a plan for handling expired certificates at the outset - 'cos they *will* come back to bite you!)

The 2860n has a rudimentary Certificate Authority built-in. Once enabled, you'd need to export the Root Certificate to your Android device (on my Huawei, the 'import from SD' option actually led me to Google Drive, which is a bit more convenient). Then on the 2860, you create a CSR (Certificate Signing Request?) for the Android client, and then 'sign' it using the 2860 itself. You'd then export the newly created certificate (via cut/paste/notepad/SD card) to the Android client and delete it from the 2860n (because there's only room for 3 certificates and one of them should be for Router itself).

In Peer Id you say which part of the certificate maps to a particular 'id'. In Teleworker setup, you set the Peer Id (number) and it makes the X509 certificate accessible. The drop down there, let's you select the Peer Id - this time by name. (I dont understand at the moment - why both Peer Id no. and name?) [I'd mis-remembered this - the actual option to make the X.509 section come to life, is "Specify Remote Node" - maybe you then use 'Remote Client IP' or 'Peer ID' or 'Digital Signature'?....or maybe that X.509 cert. is the one sent by the 2860. :? ]

(I've omitted to say how you get the Android VPN client to present the certificate - because at the moment, I'm not certain. I'm pretty sure SmartVPN can't do it. Glancing at the inbuilt VPN client on my Huawei P9 reveals lots of certificate-related options) [Re-reading your post, you're probably using the inbuilt client anyway, for L2TP/IPSec]

This might be enough to kick start your efforts

This piqued my curiousity - so I decided to follow it through and see what's involved...

First off - to correct some of what I speculated on above:-

• To Enable X.509 signature checking for a user, you simply tick the box - The subliminal flash from that side of the screen when you tick "Specify Remote Node" was confusing me
• You cannot use the 2860's built-in Root Certificate Authority (CA). Although you can create certificates, you cannot export their private keys. So these certificates are effectively issued only to the Router. (Higher spec routers, such as the 3900 can do this)

With that in mind, the first requirement is a tame Certificate Authority (CA) than can issue the required certificates - I chose to use my internal Windows 2008 Server R2's functionality. I did look at Letsencrypt, but it cannot/will not issue the correct type of certificate. The 2860 will, at the very least, validate if a certificate is 'trusted', so I can't see how any 'self-signed' variant will work.

The overall process is something along these lines :-

• Set up a SYSLOG server and enable logging to it from the 2860. Without its real-time VPN diagnostics, you'll be in the dark, as to why things aren't working).


• Ensure the 2860 trusts the CA that is issuing the certificates (by importing that CA's Root certificate)


• Ensure your mobile device trusts this CA too, by importing the CA Root certificate.


• Create a computer/device certificate for your mobile device; one that contains OID's 1.3.6.1.5.5.7.3.1 and/or 1.3.6.1.5.5.7.3.2 (Server and Client Authentication respectively). (In other words, the certificate is to be used for authenticating a device). Until I understood more about the Windows CA, I simply exported the local 'machine' certificate from my Windows 10 PC and used that. There are other OIDs (IPSec-related) that may be acceptable too, but I didn't check any further.


• Import this certificate (complete with its private key) into the mobile device (probably as a .PFX file).


• Create one or more Peer ID Accounts on the 2860. These perform checking of certificates and declare success, if the 'rules' within them match. I could not get the "Accept Subject Alternative Name" option to work (even after I learned what a Subject Alternative Name is :wink: ) - but the other options work. (Further explanation below).


• Now you connect one or more "Remote Dial-in User" account(s), to those Peer ID Accounts, in order to check the certificate. (Tick the "Digital Signature (X.509)" box and select the desired Peer ID from the list).


• Configure the mobile device to use the certificate you imported earlier. On my Huawei P9, the only type of VPN entry I could get working, was labelled as "L2TP/IPSec RSA".

I have overflowed the message length limit - so continued in next post

...cont'd

The Android options I configured, were :-

• Type = L2TP/IPSec/RSA


• Server address (obviously)


• IPSec user certificate. This is the previously imported 'machine/device' certificate. I don't follow why Android refers to it as 'user'.


• IPSec CA certificate (i.e. the certificate for the CA that issued that user/machine/device certificate).


• IPSec server certificate was left as 'received from server'. Maybe it can use this to check that you've connected to the server you were expecting?

You now need to configure the Peer ID Accounts - to do as much checking as you require. Note: the inbound certificate is effectively a replacement for the Pre-shared Key part of the configuration. A Username/Password will still be required to actually validate the user. Because the built-in list of "Remote Dial-in users" is now part of the mechanism, you can no longer use Radius for authentication (at least I can't see how).

If you just tick "Accept Any Peer ID", the only check that seems to be performed, is: "Is the certificate trusted?" - (I think!). To my mind, this makes it a straight replacement for a Pre-shared key. As mentioned earlier, I couldn't get validation against the "Subject Alternative Name" (SAN) to work - but the "Accept Subject Name" does.

In the case of "Accept Subject Name", everything the certificate contains, has to be entered for it to be declared a match. This can be problematic, if the certificate has multiple "CN" records, for example - I'm not clear how you concatenate them into a single field on the 2860.

Initially, I got a lot of "Certificate and ID not match" messages in Syslog - and that's as good as it gets!: it doesn't tell you what it received, or what it checked it against. I decided that the key to producing easy-to-match certificates, was to override the Windows CA templates and produce my own. The Windows CA does not make this easy ... but after cursing it for several days, I realised why. If anyone could just request a certificate, saying whatever they wanted, it wouldn't actually prove a lot! By default, Windows was filling in trusted Active Directory information - information that was difficult to enter into the 2860.

After much cursing (and googling) I finally managed to produce a 'machine' certificate, of the correct 'type', that contained simple information, that I could get the 2860 to validate 8)

Although it did eventually burst into life, I'm not entirely convinced that it's worthwhile. Personally, I would have thought the downside of losing Radius authentication outweighed any benefits...

This is a very in depth reply and I am hugely thankfull for you efforts hornbyp!

For a bit of background I wanted to use certs firstly because I thought it would be more secure, secondly I think it is faster due to the tunnelling with IPSEC being more efficient compared to ipsec/l2tp and lastly I thought it would be a great learning experience getting to grips with certs. I was not too concerned about the scalability as this is a home environment for me and and a few other people.

The part of the process that I am having trouble figuring out was cert creation (what certs are needed where and how to obtain). I think however, after reading your post, that I probably need to learn more about certs in general although I get the basics at a logical level.

I think I may experiment with certs another time due to lack of free time right now, I'm unfamiliar with Radius, would you mind elaborating on this a bit? To me it looks like a WiFi authentication protocol?

tekwipz wrote: ...secondly I think it is faster due to the tunnelling with IPSEC being more efficient compared to ipsec/l2tp

I don't believe it has any bearing on VPN throughput, but it could conceivably affect the time it takes to actually set-up the link. (But when it comes to the latter, have a look at XAUTH (which recently appeared on the 2860). That is blindingly fast at authenticating...)

and he wrote: I'm unfamiliar with Radius, would you mind elaborating on this a bit? To me it looks like a WiFi authentication protocol?

It can be used for Wifi authentication (though I've not actually figured that out yet :oops: ) ...

...in a nutshell, for the Windows world, it means a simple mechanism for disparate, non-windows devices to authenticate against your stable, secure, flexible, centrally managed Active Directory Domain (rather than each having to have its own list of usernames and passwords).