1 Like
You used upstream 1.1.1.1 with tls.
Can’t to test any dns over tls.
Compare adguard test showing connected dns over tls, but 1.1.1.1 showing not connected dns over tls.
You could test next Dns over tls and you will see no
yes? Are you using upstream 1.1.1.1 with TLS (DoH, DoT, etc)
Mine not but Adguard is connected
Do you understand how to test with TLS?
TLS itself server router
TLS Cloudfrlare server
TLS Adguard server
TLS NextDNS server
etc…
you are right, using adguard for me shows as DoH. I got DoT alert when using GL script from router:
Guys, this is getting off topic here, maybe you can create a new thread or discuss via PM instead?
1 Like
Looks nice.
An idea: If I want DDNS and a LE cert, I think a HTTPS will work within the network (LAN).
So why not add an acme client on the Webserver and let handle everything within the httpd?
Because it’s nginx using lua scripts for the GL stuff.
And webroot is deprecated as an option for acme.sh 
You could make raspberry pi server. Turn off ddns router and turn on another server ddns from raspberry pi.
It didn’t work for me, could you check?
I know that my ISP blocks http and https ports, that’s why I always say DNS certificates
root@GL-MT6000:~# sh enable-acme.sh
Warning: This script could potentially harm your router!
This script will disable HTTP-only access to the router.
Do you want to continue? (y/N)
Y
Running opkg update ...
Installing luci-app-acme ...
Detected DDNS domain name: pm6ee86.glddns.com
Prefix of the DDNS domain name: pm6ee86
Deleting old ACME configuration file for pm6ee86 ...
Creating ACME configuration file ...
Disabling HTTP access to the router ...
Creating firewall rule to open port 80 on WAN ...
Restarting firewall ...
Warning: Section @zone[1] (wan) cannot resolve device of network 'wan6'
Warning: Section @zone[1] (wan) cannot resolve device of network 'wwan'
Warning: Section @zone[1] (wan) cannot resolve device of network 'secondwan'
Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
Warning: Option 'wgserver'.masq6 is unknown
Warning: Section 'wgserver' has no forward policy specified, using default
Warning: Option 'sambasharewan'.dest_proto is unknown
Warning: Section 'sambasharewan' does not specify a protocol, assuming TCP+UDP
Warning: Option 'sambasharelan'.dest_proto is unknown
Warning: Section 'sambasharelan' does not specify a protocol, assuming TCP+UDP
Warning: Option 'glnas_ser'.dest_proto is unknown
Warning: Section 'glnas_ser' does not specify a protocol, assuming TCP+UDP
Warning: Option 'webdav_wan'.dest_proto is unknown
Warning: Section 'webdav_wan' does not specify a protocol, assuming TCP+UDP
Warning: Section 'adguard_home' has no target specified, defaulting to DNAT
Warning: Section 'adguard_home_guest' has no target specified, defaulting to DNAT
Warning: Section @zone[2] (guest) has no device, network, subnet or extra options
* Flushing IPv4 filter table
* Flushing IPv4 nat table
* Flushing IPv4 mangle table
* Flushing IPv4 raw table
* Flushing IPv6 filter table
* Flushing IPv6 nat table
* Flushing IPv6 mangle table
* Flushing conntrack table ...
* Populating IPv4 filter table
* Rule 'Allow-DHCP-Renew'
* Rule 'Allow-IGMP'
* Rule 'Allow-IPSec-ESP'
* Rule 'Allow-ISAKMP'
* Rule 'Allow-DHCP'
* Rule 'Allow-DNS'
* Rule 'wgserver_allow'
* Rule #12
* Rule #13
* Rule #14
* Rule #15
* Rule 'GL-ACME'
* Redirect 'Adguard Home'
* Redirect 'Adguard Home guest'
* Forward 'lan' -> 'wan'
* Forward 'guest' -> 'wan'
* Forward 'wgserver' -> 'lan'
* Forward 'wgserver' -> 'wan'
* Forward 'lan' -> 'wgserver'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Populating IPv4 nat table
* Redirect 'Adguard Home'
* Redirect 'Adguard Home guest'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Populating IPv4 mangle table
* Rule 'process_mark'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Populating IPv4 raw table
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
* Zone 'guest'
- Using automatic conntrack helper attachment
* Zone 'wgserver'
* Populating IPv6 filter table
* Rule 'Allow-DHCPv6'
* Rule 'Allow-MLD'
* Rule 'Allow-ICMPv6-Input'
* Rule 'Allow-ICMPv6-Forward'
* Rule 'Allow-IPSec-ESP'
* Rule 'Allow-ISAKMP'
* Rule 'Allow-DHCP'
* Rule 'Allow-DNS'
* Rule #12
* Rule #13
* Rule #14
* Rule #15
* Rule 'GL-ACME'
* Forward 'lan' -> 'wan'
* Forward 'guest' -> 'wan'
* Forward 'wgserver' -> 'lan'
* Forward 'wgserver' -> 'wan'
* Forward 'lan' -> 'wgserver'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Populating IPv6 nat table
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_guest_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_guest_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wgserver_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wgserver_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Populating IPv6 mangle table
* Rule 'process_mark'
* Zone 'lan'
* Zone 'wan'
* Zone 'guest'
* Zone 'wgserver'
* Set tcp_ecn to off
* Set tcp_syncookies to on
* Set tcp_window_scaling to on
* Running script '/etc/firewall.user'
* Running script '/etc/firewall.nat6'
* Running script '/var/etc/gls2s.include'
! Skipping due to path error: No such file or directory
* Running script '/usr/bin/gl_block.sh'
* Running script '/etc/firewall.vpn_server_policy.sh'
iptables v1.8.7 (legacy): Couldn't load target `VPN_SER_POLICY':No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
Restarting nginx ...
Restarting acme ...
Due to some unkown reasons, we need to restart acme again ...
Checking if certificate was issued ...
Certificate was not issued. Please check the log file /var/log/acme/acme.log.
That’s not possible so far.
1 Like
This is an important topic of late. The current DDNS for Wireguard is in Hong Kong. If you're self hosting with a LE cert or wildcard cert after connecting to VPN you cannot hit any of your self hosted domains without the browsers returning an error on the cert, marking it as unsafe. Of course IP addresses work while on the VPN but for travelers bookmarking URL's this is an issue.
I am not sure what you are trying to say because it does not make any sense 
hmm are you talking about a unsigned certificate generated by the router?
to be honest, I never understood why one want a signed certificate like LE for local purposes, between a public cert and a unsigned cert it exactly does the same including the encryption.
the only difference is that LE is stored as a trusted publisher in your certificates, you can easily do the same with the unsigned certificate and then you have exactly the same behaviour as LE.
if you really want a LE cert, you should look up for ACME and letsencrypt in the past I was able to spoof a local domain like that but I don't remember anymore what I did to accomplish this, likely I also had access to a real domain then, but I still stand correct on my above sentence you don't really need a public certificate. 
I'll reply to both you and @admon , I'm running Nginx Proxy Manager using a LE cert for our sub domains. Works fine as it is... Before using the router to run WireGuard we ran it on a docker instance, all worked well.
Now we enabled Wireguard in the router and shut down the Wireguard docker container. Figured for maintenance purposes we were now not going to shut down the VPN when we needed to work on our host server in the background.
If we connect to the VPN through the router any subdomains URL's prompt a self signed cert error and do not allow us to bypass it. Of course direct IP & port mappings (ie xxx.xxx.xxx.xxx:xxx) work, but if you try to resolve using subdomain.domain.com the browser throws a self signed cert that resolves to a server for gl.net in Hong Kong... maybe we're missing something???
This does not happen if we reenable the Docker WireGuard instance and connect using that instance, only on the router version.
This issue is more a configuration issue than some GL issue.
You need to check if LE still works (depending on the Challenge you chose) and if the certificates are valid. For better understanding you need to provide way more information like the DNS names, how you renew the LE certs and so on.
Hi, our certs are valid, domain valid, here are the screen shots. DDNS is handled by our provider.
What is console.gl-inet.com resolving to?
console.gl-inet.com is resolving to the WAN address of the router itself. It will show if you use the local nginx to access something.
So my guess would be that your nginx configuration does not fit.
But that config is built into the router, how can that be changed?
And why would it be 'invalid'?
It's invalid because it is self-signed.
You are obviously connecting to the wrong server. You need to figure out what your plan is, because right now, you access the router itself - which will cause this message. So what is your goal?