okoun Moje MTU je kvůli PPPoE 1492 (jestli si dobře pamatuji) a možná právě to je ten problém. Příkaz curl mi vypsal následující:

  • Rebuilt URL to: https://sbazar.cz/
  • Trying 2a02:598:a::78:23...
  • TCP_NODELAY set
  • Connected to sbazar.cz (2a02:598:a::78:23) port 443 (#0)
  • schannel: SSL/TLS connection with sbazar.cz port 443 (step 1/3)
  • schannel: checking server certificate revocation
  • schannel: sending initial handshake data: sending 174 bytes...
  • schannel: sent initial handshake data: sent 174 bytes
  • schannel: SSL/TLS connection with sbazar.cz port 443 (step 2/3)
  • schannel: failed to receive handshake, need more data

Taky se mi podařilo zjistit, že ty problémy jsou hlavně na protokolu https, takže např. http://mapy.cz projde, ale https://mapy.cz už ne a to i přesto, že při http se to automaticky přesměruje na https.
Co může být špatně? ICMPv6 mám průchozí, ale v IPv6 firewallu mi na DROPu vypadává hodně spojení jako invalid.

      U mne je CURL takto:
      `Microsoft Windows [Version 10.0.18363.836]
      (c) 2019 Microsoft Corporation. Všechna práva vyhrazena.

      C:\Users\Mirek>curl -v http://mapy.cz

      • Rebuilt URL to: http://mapy.cz/
      • Trying 2a02:598:a::79:138...
      • TCP_NODELAY set
      • Connected to mapy.cz (2a02:598:a::79:138) port 80 (#0)

      GET / HTTP/1.1
      Host: mapy.cz
      User-Agent: curl/7.55.1
      Accept: /

      < HTTP/1.1 301 Moved Permanently
      < Server: nginx
      < Date: Mon, 18 May 2020 08:38:42 GMT
      < Content-Type: text/html
      < Content-Length: 162
      < Connection: keep-alive
      < Keep-Alive: timeout=60
      < Location: https://mapy.cz/
      <
      <html>
      <head><title>301 Moved Permanently</title></head>
      <body>
      <center><h1>301 Moved Permanently</h1></center>
      <hr><center>nginx</center>
      </body>
      </html>

      • Connection #0 to host mapy.cz left intact
        `

      Pro HTTPS to bypíše asi celý HTML kód.

      radek_kovacik jasný ale všech lidí co mají VDSL také a ipv6 mají že 😃

        Tak jsem se na to díval a MTU je automatikou nastavené na 1480, omlouvám se za chybný údaj. Konfiguraci toho PPPoE mám takto:
        /interface pppoe-client
        add ac-name="" add-default-route=yes allow=pap,chap,mschap1,mschap2 default-route-distance=1 dial-on-demand=no disabled=no interface=Port1 keepalive-timeout=10 max-mru=auto max-mtu=auto mrru=disabled name=WAN-PPPoE password=TO2 profile=PPPoE service-name=Data use-peer-dns=yes user=TO2
        Proč ty zabezpečený stránky nefungují a proč jen na některých serverech?

          jcltm Já musel nastavit u ND také MTU na 1460, ale PPPoE MTU mám na 1480. Pohrál bych si s tím, ale není to moje přípojka a takhle to momentálně funguje.
          /interface pppoe-client add add-default-route=yes comment=WAN disabled=no interface=vlan848_ether1 max-mru=1480 max-mtu=1480 name=pppoe848_vlan848_ether1 password=O2 use-peer-dns=yes user=O2
          /ipv6 dhcp-client add add-default-route=yes interface=pppoe848_vlan848_ether1 pool-name=IPv6_WAN request=prefix
          /ipv6 nd set [ find default=yes ] advertise-dns=yes managed-address-configuration=yes mtu=1460 other-configuration=yes
          E: Myslím si, že jako modem tam je ASUS DSL-N16, ale nejsem si jistý.

              kmotrik Ve firewallu není nic

              Není výchozí pravidlo firewallu DROP, tj. že by zahodil všechen provoz? Případně co je to za router (jaká platforma a software)? Pokud je to Linux/x86, je povolený forwarding?

              mirek_k Z Routeru se přidělují prefixy pro AP /51 a ty přidělené pak AP přiděluje klientům /56

              Tzn. AP jsou taky v režimu router?

              okoun k tomu MTU 1500 by mě tedy zajímalo jak to dělá PPFka a ostatní VDSLkaři když jejich MTU určitě není 1500 🙂

              Buď pomocí clamp-mss-to-pmtu nebo prostou úpravou MSS podle maximálního MTU PPPoE (1492). Samozřejmě nesmí blokovat ICMPv6, je to jen takový hack, který ovlivní downstream, problémy na upstreamu nezachrání. Základem je nefiltrovat na cestě klíčové ICMPv6 zprávy.

              sidi k tomu je ještě potřeba snížít MTU u ND na IPv6

              Je to tak, tohle pomůže stanicím zjistit IPv6 MTU a podle toho náležitě sekají pakety.

              xjxM5qHeN Já musel nastavit u ND také MTU na 1460, ale PPPoE MTU mám na 1480

              Teď jsem překonfiguroval jednu DSL přípojku - zrušil clamp-mss-to-pmtu a ověřil, že PPPoE MTU je 1492 (to posílám v RA do LAN). Pokud do LAN pošlu RA MTU 1493, mapy.cz se zaseknou. Pokud pošlu 1492, tak běží. (Zkouším pomocí curl -6 -v https://mapy.cz/.) Může se to samozřejmě lišit podle operátora a opět to narazí na situace, kdy někdo v Internetu bude blokovat ICMPv6 (např. pokud se ke mně připojí zvenku a nedorazí mu ICMPv6 Packet Too Big, takže nesníží velikost paketu tak, aby se mi vešel do MTU). Na tyhle situace ostatně ani MSS clamping nemusí vždycky pomoct (a navíc se cesty ode mě k někomu a od někoho ke mně mohou lišit, tj. mohou mít i různá MTU).

                          jcltm A máš to nastavený ručně natvrdo nebo automatikou? Já mám modem taky v bridge (je to asi 10 let starý typ) a hlavní router je Mikrotik.

                          sidi Na ND nemám MTU definováno (slovy RouterOS "unspecified").

                          zajdee Dá se tedy říct, jaká hodnota MTU je pro DSL přípojky na PPPoE rozhraní správná? Je to těch 1480 nebo 1492? Já vím na beton, že někdy předtím (při starším RouterOS) jsem tam měl tu hodnotu 1492, ale v té době jsem nepoužíval IPv6 a v4 jela normálně a po nějakým update (nebo možná i při výměně hw) zřejmě došlo ke změně na 1480.

                                  radek_kovacik Mikrotik nepoužívám, na té přípojce mám ASUS RT-AX56U s Merlinem. MTU a MRU jsem nastavoval ručně podle dat od poskytovatele. Pokud si dobře vzpomínám tak když jsem na jiné, konkrétně O2 VDSL přípojce rozjížděl IPv6, dával jsem tam ručně taky na PPPoE MTU a MRU 1492 a fungovalo to OK. Jako modem tam byl starý Comtrend v bridge.

                                    Mám v IPv6 firewallu hodně invalid forward packetů - za pár dnů 400 000. Za sekundu skoro 10.
                                    Všechno to vypadá jako odpovědi web serverů (z portů 443 a 80) TCP (RST), či TCP (SYN,ACK).
                                    Nemyslím, že by to mělo takto fungovat. Můžu mít někde chybu?
                                    Pravidlo je
                                    add action=drop chain=forward comment="drop invalid" connection-state=invalid

                                    Díky
                                    Mirek

                                      mirek_k U mne je to podobné a zatím jsem na ten důvod, proč se to tak děje, nepřišel. Pravidlo mám stejné.
                                      Jinak MTU na PPPoE rozhraní jsem nastavil na hodnotu 1492 dle doporučení T-Mobile a můžu říct, že se tím odstranilo více různých problémů, než které jsem tomu původně připisoval včetně těch výše zmiňovaných webů, které běžely pomalu nebo vůbec. Původně jsem doufal, že to odstraní i ty invalidní spojení, ale ty zůstaly.

                                        📡 Telekomunikace.cz