C'est courant cette façon de faire en réseau? Le TTL de réponse = au TTL de la demande?

réponse courte : Non
réponse plus longue :
je n'ai jamais vu ça, il n'y a rien de ce genre dans le RFC 792 (je sais, c'est vieux).
Les systèmes Linux "modernes" permettent de fixer la valeur par défaut, tu peux vérifier par : $ sysctl -n net.ipv4.ip_default_ttl
64
Sans surprise c'est aussi cette valeur qu'utilise ma FreeBox :
$ ping -c 1 -4  _gateway
PING  (192.168.1.254) 56(84) bytes of data.
64 bytes from _gateway (192.168.1.254): icmp_seq=1 ttl=64 time=5.44 ms

---  ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.439/5.439/5.439/0.000 ms


J'ai jeté un œil sur le forum Netgear.
Il y a des gens qui ont le même problème de non accès à l'interface web à travers un VPN.

Seule réponse proposée : https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/GS308E-Refusing-Connection-while-on-VPN/m-p/2334492
"Here again, the very basic IP stack on the micro controller is not able to handle smaller MTU than the default, these switches don't understand PMTUD."

Ce qui me parait bien louche.

As-tu regardé si tu voyais des paquets ICMP "Destination Unreachable" / "Fragmentation Needed and Don't Fragment was Set" dans ta trace pour voir s'il s'agit bien de ce sujet Path MTU Discovery? (et si les paquets SYN envoyés par le PC contiennent le bit do not fragment positionné ?)
Pour moi, si c'était un cas lié à PMTUD, tu ne verrais même pas de TCP RST.

L'implémentation IP a l'air un peu fantaisiste sur cet équipement, ça pourrait être autre chose (ex : ne pas autoriser les connexions entrantes http d'une provenance hors du LAN).

Dans la doc : "Connect your computer to the same network as the switch."
Mais il ne parle pas des tunnels.
Et le GS305 répond correctement TCP SYN ACK contrairement au GS308 qui répond TCP RST pour une même situation.

Je comprends bien cette réponse sécuritaire TCP RST à des demandes hors du LAN de config du Switch.

it is not a bug, it is a feature (read the f...g manual) ... Implémentation à 2 balles d'une mesure de "sécurité"

Par contre je ne comprends pas bien la réponse ICMP Reply avec le TTL positionné à la valeur du TTL recu avec le ICMP Request.

implémentation à 2 balles de la couche IP, en répondant au paquet reçu en ne se donnant pas la peine de créer une nouvelle entête IP pour la réponse, mais juste reprise des champs du paquet IP reçu en inversant les adresses IP src et dst.

Et du coup, cela foire les traceroute, puisque le réponse n'arrive pas à  revenir.

Cette idée de positionner le TTL de la réponse à celui du paquet reçu n'a aucune justification et est une violation notamment du RFC 1700.
Extrait (ça a 30 ans) :
IP TIME TO LIVE PARAMETER

The current recommended default time to live (TTL) for the
Internet Protocol (IP) (...) is 64.
Ca partait du constat à l'époque que le "diamètre" d'Internet en nombre de hops était de quelques dizaines.

Il faut se rappeler qu'au départ (càd aux débuts d'Internet), le TTL dans l'en-tête IP vise à éviter qu'une circularité dans des tables de routage provoque un engorgement du réseau par des paquets qui y restent indéfiniment.
L'utilisation du TTL dans la commande traceroute (ou ses dérivés) est juste la programmation d'une "astuce" technique, pour exploiter les messages ICMP TTL Exceeded permettant de détecter les anomalies de routage.
Ca n'est en rien une "norme", d'ailleurs, par défaut, traceroute Windows envoie des messages ICMP alors que les versions Unix s'appuient sur UDP.

(désolé de faire encore mon ancien combattant)