Devido aos comentários, você parece perceber que o netfilter é a ferramenta errada para o trabalho, então não vou reiterar isso aqui.
O que está acontecendo aqui?
O Google Chrome não está usando a extensão Indicação de nome de servidor TLS (SNI), portanto nenhum dos pacotes que está enviando está sendo correspondido pelas regras que você especificou, pois não contêm o nome do host de destino não criptografado e O roteador não pode ler o tráfego criptografado, a menos que você o configure como um proxy transparente e realize um ataque man-in-the-middle em cada conexão HTTPS feita através dele.
O TLS SNI é uma extensão do protocolo TLS comum usado para criptografar conexões HTTPS usadas para especificar a qual host o sistema está tentando se conectar. Em particular, essa parte do handshake TLS é enviada sem criptografia, porque a escolha do certificado TLS usada para criptografar a conexão depende do host que o cliente está tentando acessar. Diante disso, tudo isso parece sem sentido, até que você considere sites de hospedagem na Web que podem servir centenas ou milhares de nomes de host por meio do mesmo endereço IP.
O HTTP, na verdade, especifica (pelo menos nas versões 1.1 e 2.0) um cabeçalho de solicitação para essa finalidade, mas, como isso é enviado após o término do handshake TLS, ele não pode ser usado para determinar qual certificado TLS usar para a conexão e, portanto, é apenas uma opção se todos os sites hospedados estiverem no mesmo domínio e a conexão usar um certificado curinga para esse domínio.
De uma perspectiva prática, o TLS SNI geralmente não é necessário, simplesmente porque a maioria dos sites visitados regularmente (incluindo aqueles que você está tentando bloquear) é hospedada individualmente ou usa o cabeçalho HTTP e um certificado curinga, e em Na verdade, alguns sites raros não suportam nada (e o handshake pode falhar nesse caso se o cliente tentar usá-lo). Além disso, o TLS SNI apresenta um vazamento de informações se o usuário estiver obtendo informações de DNS localmente, pois é trivial ver qual serviço elas estão tentando acessar.
Como resultado disso, o Google Chrome (e o Chromium e a maioria de seus derivados) tentarão se conectar sem usar o SNI (que funcionará na maioria das vezes para a maioria das pessoas) e só voltarão a usar o SNI se conectar sem ele falha. A maioria dos outros navegadores adota a abordagem mais liberal (e menos segura e mais fácil de censurar) de se conectar primeiro com o SNI e depois tentar sem o SNI se isso falhar (o que geralmente não forma a maioria das pessoas).
Qual é a melhor maneira de corrigir isso?
Primeiro, simplesmente considere não fazer isso. Tentar impor rigidamente políticas como essa normalmente é contraproducente e é funcionalmente impossível, a menos que você vá para um nível draconiano de permitir serviços explicitamente aprovados (em vez de bloquear serviços explicitamente desautorizados), porque as pessoas ainda podem obtê-los usando conexões ou proxies VPN (e você não pode bloquear todos os métodos VPN e proxy).
Se você insistir particularmente em parar isso, mude as regras para combinar na porta UDP 53. Isso evitará que qualquer tráfego de DNS não encapsulado dos domínios atravesse seu roteador (note que é possível para criptografar e ofuscar o tráfego de DNS, e você não pode fazer nada facilmente sobre isso sem fazer uma inspeção profunda de pacotes e bloquear muitas outras coisas). Certifique-se também de tornar as regras simétricas (ou seja, não bloqueie apenas o tráfego de saída, mas também de entrada), pois isso evitará que algumas soluções alternativas para esse tipo de coisa funcionem corretamente.