(I allow the required ICMPv6 packets.)
EDIT - because I use DROP.
No, if you mean the 3 dropdowns, those are "global" rules (i.e. applying only to traffic not defined in any listed zone).
If you create a rule, they are processed in order, beginning with the bad allow rule you had; and ending with the drop rule you created - that was never reached.
Glad you got it fixed!
Well I also have the ICMPv6 default forward and input rules, strange...
Ah, just for curiosity: can you use LUCI over IPv6 (from LAN)? Mine got the (in)famouse XHR timeout that is fixed for ipv4 setting to 0 the uHTTPd "reuse connection" option
AAAH, I [think I] know why!
Try changing from REJECT to DROPand check.
With REJECT you're sending a reply from OpenWrt that you don't permit traffic.
Tried but I still get "closed"
Can you check LUCI on ipv6 when you have time?
I tested...
On a client I still get FILTERED (maybe they only record replies from the host IP 
).
If I change input to REJECT and use the IP assigned to the router, it now shows CLOSED.
They may also do tracrouting and use TTLs to determine filtering.
I do not test ip on wan, but on lan device (including router itself).
I reach LUCI from the LAN via IPv6 (of the router) and I have the problem, I do not think is https related honestly
Internally (on LAN) or...from the Internet (on WAN)???
You are aware that 443/tcp DIDN'T show as open in your scan:
What problem?
You are aware you can access LuCI from LAN, correct?
...as you allow INPUT on the LAN Zone.
After all these problems I'd strongly suggest to start over with a clean default config again, to rule out other hidden gems like the ones above to lurk in the shadows.
I only allow ipv4 access on port 443 now (which is then DNAT to the actual openvpn server port), this is a ipv6 scan 
and it is on wan side 
Regarding LUCI problem I am talking access from LAN, to be more precise from a laptop or android phone connected in my lan network to the LUCI running on server.
I can access it but it does not work smoothly, the problem are similar to the ones starting to happen in 19.07 concerning XHR timeouts (if you Google you will find plenty of reports) that are fixed with a particular option in uhttpd but apparently only for ipv4
Perhaps you should make a different thread for this problem. I'm not sure how this relates to your title; nor the description of devices exposed on WAN.
