Tous les types de paquets qui sont port-forward vers mon serveurs semblent poser problème.
Les paquets TCP (ssh, https, openvpn, etc…) mais aussi UDP (wireguard et openvpn-udp).

Les paquets qui s’arrêtent au routeur (je n’ai que de l’UDP wireguard sur un autre port), ne posent aucun problème.

Et cela ne concerne que la stack ipv4, les paquets IPv6 passent bien dans tous les cas.

Et cela ne se produit pas lorsque mon téléphone se situe dans la région où j’habite (Haute-Savoie). Cela doit provenir de l’implémentation régionale NAT64 / CLAT de Bouygues de mon lieu de vacances (Avignon).

J’ai remarqué ces params sysctl sur le serveur :
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 1

Je ne sais pas si ça doit être modifié
Très curieux cette histoire…

En fait j’ai des pbs avec les services exposés en direct (port forward) et via le VPN.
Des l’instant où le service termine sur le serveur et non le routeur, il y a problème.
Mais pourquoi faut il modifier le MSS et donc sur TCP alors qu’il y a aussi un pb sur UDP ?

En fait j’ai des pbs avec les services exposés en direct (port forward) et via le VPN.

Oui j'avais bien compris, j'ai bien précisé que j'avais le problème inverse (LAN vers Internet à travers le VPN WireGuard).

Mais pourquoi faut il modifier le MSS et donc sur TCP alors qu’il y a aussi un pb sur UDP ?

Voici les notes que j'ai gardé. Je ne sais plus d'où elles viennent malheureusement.

It is a known fact that VPN links have a smaller packet size due to encapsulation overhead. A large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to sending it via that kind of connection. However, if the packet has a Don't Fragment flag set, it cannot be fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD), it may lead to a number of problems, including problems with FTP and HTTP data transfer and e-mail services.

In the case of a link with broken PMTUD, a decrease of the MSS of the packets coming through the VPN link resolves the problem.

Donc a priori le problème provient de l'encapsulation et la fragmentation ce qui ne s'applique pas dans ton cas vu que dans ton sens, on décapsule et le packet est donc plus petit ...

Je viens d’essayer avec une VM que j’ai sur le cloud Azure en ipv4 only.
Et bien aucun problème à partir de mon iPhone pour y accéder en SSH, donc en TCP.
Aucun réglage particulier sur cette VM, qui possède en plus uniquement une IP privée. L’IP publique est donc portée par un routeur en amont (géré par Microsoft donc).
Les réglages nécessaires à faire sont donc sur le routeur plutôt que sur le serveur lui-même.
La question est qu’est-ce qu’à bien pu faire Microsoft pour que ça fonctionne ? Qu’ai je raté sur le Mikrotik ?

Je ne vois qu'une chose à faire : capturer les deux connexions et comparer le fonctionnement ça peut être tellement de chose...
Le fonctionnement des réseaux est tellement complexe qui même si tu fais ça au boulot toute la journée, tu auras besoin d'autres experts pour résoudre le problème...

Hello,

Voici les 2 traces tcpdump que j'avais prises.
Les 2 traces sont de simple requetes en HTTPS sur le port 444.

La premiere, lte.tcpdump est la trace lorsque j'étais en 5G (en APN full ipv6 only et donc NAT64 DNS64) et que cela ne fonctionnait MAL/PAS. Le fichier contient 2 requêtes qui chacune finit par répondre au bout de 12-13 secondes (chacune). 1ere requete -> 12s -> réponse ; 2eme requete -> 12s réponse.

La seconde, wifi.tcpdump est la trace lorsque j'étais en Wifi (IPv4 only) et que cela ne fonctionnait CORRECTEMENT. Il n'y a qu'une seule requête.

On peut voir que dans le cas lte.tcpdump, le mss est à 1390 et en Wifi mss de 1460.
A part ça, je ne vois pas grand chose.

J'ai pris d'autres traces, notamment des tentatives de montage de tunnel wireguard en UDP. Je posterais ici plus tard si besoin.

Comme prévu, sur le chemin du retour, j'ai pu constater que selon les lieux géographiques, parfois cela fonctionnait bien en 5G/4G. Puis à d'autres endroits, plus du tout. Cela confirme la config très localisée de Bouygues. Dans ma région, que je sois chez moi ou au travail (30km entre les 2), cela fonctionne dans les 2 cas.

Salut,

Merci bcp pour ta réponse.
Le problème est que je suis incapable de reproduire le problème, car il est très dépendant de la localisation...

Autour de chez moi/travail, je n'ai pas réussi à reproduire le pb. Bouygues semble vraiment avoir des configs différentes selon les endroits.

Si je parviens à reproduire le problème, je referais des captures pcap.

Tu n'aurais pas une piste des fois ?

Merci encore.