I have a 2860, and until recently, I have been making use of its SSL VPN function. I obtained a signed certificate for the router's hostname.domainname from LetsEncrypt, using the HTTP on port 80 validation scheme (opening up a NAT port mapping just for the few seconds this takes). This works nicely. I administer the router over TLS/SSL on a non-standard port, currently on the LAN side only (but I may need remote admin one day). And therein lies the problem. When I access the router from the LAN side on https://myrouter.local (or https://192.168.x.y) I get a certificate error from the browser, because the host names don't match.

On the other hand, if I access the router from the LAN side using the valid hostname.domainname for the certificate, DNS resolves this to the WAN IP address of the router, which is not enabled for remote administration.

I can live with this, using Safari, manually entering a certificate exception every 90 days. However, when I create a certificate exception in Chrome, it appears to disable JavaScript, with no way to enable it again - so the admin pages don't work! I fear this situation will only get worse, as all the main browser developers are in the process of tightening up their SSL security configurations.

Once the current security panic is over, I suppose I could enable WAN administration, but I'd rather not if I don't have to. Is it possible for the router to be configured to handle DNS requests from the LAN side for its own hostname.domainname, and return the LAN address rather than the WAN? Or is it possible to use different certificates for web administration and SSL VPN?

Any other ideas?

I had a somewhat similar problem with split-DNS needed for my 3CX VoIP PBX - I needed a FQDN to resolve to local lan IP from inside the network and public IP for external access. In my case I'm running a Pi-Hole https://pi-hole.net/ on a Raspberry Pi which acts both as a DNS server and extremely good adblocker.

I'm using a DDNS FQDN (xxx.hopto.org), so this name now correctly points to external public IP or internal LAN depending on where the request comes from.

I thought that since the Drayteks acted as transparent DNS proxies, it would be possible to use the internal DNS server rather than having a separate DNS box. But then I have never seen any entries in the 'DNS Cache' diagnostic listing on my 2860.

These Drayteks are frustrating at times, very powerful facilities that nobody can use - because they aren't documented properly!

I don't think the Draytek's DNS proxy will help you in this respect, However, the eassiest fix is to enter your FQDN together with its LAN IP address into your HOSTS file, since this should resolve first, and will eliminate the need for a DNS search.

John.

On second thoughts I think you can do it here: Applications >> LAN DNS / DNS Forwarding

A quick test shows it seems to work as expected (though a bit slow to respond - possibly as I have another DNS server running which my 2860 also uses)

ChrisW wrote: On second thoughts I think you can do it here: Applications >> LAN DNS / DNS Forwarding

Yes, but what exactly does the 'it' comprise? I thought it ought to be something to do with this page but can't find any useful information on what I should enter!

Meanwhile, the /etc/hosts trick works OK. I'd forgotten all about that - a proper blast from the past! It has the disadvantage that MacOS upgrades usually overwrite the file without warning (or at least they used to)