Hallo Ronny,
On Tue, Apr 09, 2019 at 11:47:40 +0200, Ronny Seffner wrote:
ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich beziehen und an Clients dahinter verteilen.
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und die des anderen Netzes nicht.
Wohl eher mit grossen Paketen, die vom Server kommen.
[...]
Zusätzlich verteile ich die Netzinformation für die dahinterliegenden Clients mit radvd wie folgt:
interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; AdvDefaultPreference high; AdvLinkMTU 1280;
[...]
interface eth1 { AdvSendAdvert on; prefix 2a00:fda0:6:cd10::/64 {
Ohne radvd besonders gut zu kennen faellt mir auf, dass Du nur fuer eth0 (LAN) die Link-MTU der Clients auf 1280 senkst, bei eth1 (LAB) tust Du das nicht. Entsprechend setzen die Clients im LAN ihre Interface-MTU auf 1280, waehrend die Clients im LAB die Interface-MTU beim Default, also 1500 belassen.
Nennen wir das Netz hinter eth0 LAN und das hinter eth1 LAB. Auf mindestens einen Webserver im WAN mit IPv6 habe ich Zugriff. Daher hier mal die Paketmitschnitte aus Sicht dieses Webservers, wenn eine Anfrage aus dem LAN kommt und eine aus LAB.
TCP handelt beim Verbindungsaufbau die mss (maximum segment size) zwischen Client und Server aus.
Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der Interface-MTU 1280 abgeleitet, die Serverseite antwortet mit mss 1440. Damit muessen sie sich auf der kleineren Wert (1220) einigen, der dann fuer *beide* Richtungen der TCP-Verbindung benutzt wird.
Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich irgendeinem Router auf der Strecke vom Server zum Client zu gross werden.
Gruss, Christian