Le ecureuil

It is a sort of redundancy and load balancing based on connection reply speed. Further communication performs with the server with the fastest reply.

The EULA states that it is required and cannot be disabled.

I still can't see any reasonable point for choosing DoT over DoH. Will disclosure some facts behind implementation. We discussed protocols selection and fallback with NextDNS team and they advised us to stuck on DoH only, as it provides best possible service over others with neglectible expense. That's the point from authors of the NextDNS, and I totally agree with them. Yes, they support many other protocols, but as legacy fallback with degradation of service quality. So I will ask you again: is there any reasonable point for DoT over DoH?

"Don't want" is not a valid reason. I don't want on the other hand, so what? Will any real considerations appear?

We don't support DoQ for now (as well as NextDNS). DNS-over-HTTP/3 is not supported as there is no final RFC for HTTP/3. Can you describe your needs in DoT over DoH? It seems that there is none.

It's rather strange to insert link just to login page. We are considering to add personal links to all profiles. Stay tuned )

Но в конфиге нет ничего про DoH и никаких фильтров. Тогда откуда там записи про DoH?

This is the QUIC transport layer itself, but there are extensions over this transport layer, such as HTTP/3, DNS-over-QUIC, etc. Neither of them are standartized nor supported by majority of vendors.

Unfortunately we have no moderators with knowlege of Turkish right now.

Keenetic ♂Right Version♂?

Plz provide logs after restart when device is unable to install connection.

https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-06

DNS-over-QUIC is not ratified as RFC standard yet. There are several drafts, incompatible with each other. On the other way, there are no real support in DNS providers, only in Adguard DNS. So, in summary: - we will definitely wait for final RFC standard - we will wait for support from at least two providers to test interoperability. DNS-over-HTTPS/3 is also is not ratified, but in general it's easier to support (and there are several services with preliminary suport). So after ratification of HTTP/3 as RFC standard we will probably include it.

I see no objections to do that. Probably UDP/500 and UDP/4500 should be excluded from DMZ, but worth to try.

It has some drawbacks, of course, but in the world of dynamic and multiple addresses it's the easiest way for user to open port without messing with static ip.

It's possible and works as expected. You need two rules: one per device mac.

We will pin in to feature request.

Input interface is set here as incoming direction for applying rules, no address from this interface will be used. Suppose you have ISP with addr 2::100, ISP2 with addr 3::100 and host in LAN with addrs 2::1 and 3::2. so after cmd ipv6 static tcpudp ISP <mac> 80 you will be able to get access from the internet to [2::1]:80 when connection comes from ISP. When connection comes from ISP2 it will be rejected, the separate rule is needed to allow traffic from ISP2. Just notice, that ISP and it's address 2::100 is never used.

Yes, you can. 'ipv6 stati'c doesn't perform any type of NAT/PAT, it is just about opening ports. So if your PC1 has addrs 2::1 and 3::1, and PC2 has addrs 2::2 and 3::2, you can host different services on PC1 on addresses 2::1 and 3::1, and access from Internet to [2::1]:80 an to [3::1]:80 will not be mixed, but delivered properly. Moreover, you can host another two services on PC2 on 2::2 and 3::2, and access to [2::2]:80 and [3::2]:80 will not be interleaved or confused with access to [2::1]:80 or [3::1]:80. All four {ip,port} combinations will be available from Internet directly without NAT or port forward.

Did you tried to connect to all IPv6 addresses on host from Internet? As far as I know port is forwarded for all addresses, so multiple connections are well supported.

We have plans for major update of NextDNS support in 3.8, so stay tuned and thanks for reports.

Right now IPv6 doesn't compatbile with policy routing. We know the issue and have plans to resolve it. You can vote for it by creation of ticket in official support.

Syslog sender in fw works on very low level and cannot resolve domain names when it starts (It's even connectionless, so UDP messages are being sent without knowlege of running interafces and availability of network addresses and connection). It is the known limitation, and we plan to resolve it in future. You can vote for it by creation of ticket in official support.

Any recognised IPv6 address on device will be forwarded, that's the reason to use MAC in command instead of explicit IPv6 address. By the way, IPv6 privacy extensions can be enabled on device, so effective IPv6 address will be changed every 3/6/12 hours by random. Router tracks current set of available IPv6 addresses for every host and update translation table automatically. Forward will be performed at L3, so there is no reason to worry about possible L2 leaks.

I can't help with mobile app.