Het grote IPv6 topic

[Roetzen]

nero355 schreef op woensdag 5 april 2023 @ 14:54:
[...]

De eerste groep heeft echter wel gelijk in tegenstelling tot de tweede groep!

Inderdaad, corona is voorbij. IPv6 daarentegen, daarvoor bestaat geen vaccin, het gaat niet meer weg.

[nero355]

Roetzen schreef op woensdag 5 april 2023 @ 15:24:
IPv6 daarentegen, daarvoor bestaat geen vaccin, het gaat niet meer weg.

Over dat eerste zijn er twijfels, maar dat tweede staat inderdaad wel vast!

[RobertMe]

TIL: blijkbaar weigert Android IPv6 DNS servers (/rdnss) die zich in een ander subnet bevinden als die geen publiek (/GUA), neem ik aan, IP adres heeft. Ook niet als die wel route info ontvangt over dat subnet binnen zelfs letterlijk dezelfde router advertisement.

Scenario is dus wederom waar ik mee bezig ben met opzetten subnet waarbij verkeer via een VPN boer de deur uit gaat. Ik krijg daarvan (uiteraard) een intern/private IP dat geNAT wordt aan hun kant. Echter NAT ikzelf het subnet dan ook (omdat ik maar één IPv6 adres krijg). Het subnet van mijn VLAN is daarbij fd00:15::/64. Echter heb ik na lang discussiëren met mijzelf besloten om waar ik Docker gebruik dit per systeem (router, server, nas, ...) onder te verdelen in fd00:<vlan>:<systeemnummer>::/64. PiHole op mijn router staat nu dus op fd00:15:1::53 en dus een ander subnet. Maar Android weigert deze DNS server (staat niet gewoon in settings menu, en ook niet in een app als Net Analyzer). Echter had ik van vorige trial & error in de RA nog een fd00:15::54 staan, en die was wel overal mooi inzichtelijk. Ik zat al te tcpdump-en om te valideren dat het DNS IP wel, en correct, gecommuniceerd wordt, en daarna viel mij dus dat andere grote verschil op tussen mijn gewone VLAN en dit: het feit dat het gewone VLAN dus een GUA heeft en dit VLAN niet. Prefix delegation uit gezet op mijn gewone VLAN en hoppa, geen IPv6 DNS server meer.

Maar ik kan dus weer wel communiceren met IPs in dat andere subnet. Bv met de genoemde Net Analyzer kan ik wel DNS doen met handmatig opgegeven de IPv6 server (en met tcpdump gevalideerd dat die niet stiekem IPv4 fallback doet). Dus de extra route neemt die wel netjes over. En/maar de voorkeur lijkt dan weer wel naar IPv4 uit te gaan, als in: ipv6-test.com is nogal duidelijk in "je doet geen IPv6".

[Dreamvoid]

RobertMe schreef op donderdag 6 april 2023 @ 18:15:
TIL: blijkbaar weigert Android IPv6 DNS servers (/rdnss) die zich in een ander subnet bevinden als die geen publiek (/GUA), neem ik aan, IP adres heeft. Ook niet als die wel route info ontvangt over dat subnet binnen zelfs letterlijk dezelfde router advertisement.

Dat is raar inderdaad, dit is toch een behoorlijk veel voorkomend scenario. Is er iets in de Android bugtracker over te vinden?

Scenario is dus wederom waar ik mee bezig ben met opzetten subnet waarbij verkeer via een VPN boer de deur uit gaat. Ik krijg daarvan (uiteraard) een intern/private IP dat geNAT wordt aan hun kant.

Dit is niet standaard-conform, als die VPN server een route naar het internet biedt moet de VPN server een GUA subnet intern doorzetten, geen ULA range. ULA ranges zijn voor intranet toepassingen (dus zonder internet toegang, als je de VPN gebruikt om reizende werknemers toch toegang voor het interne bedrijfsnetwerk te geven, of om twee intranets aan elkaar te koppelen). Ik zou even contact opnemen met je VPN provider of ze geen GUA prefix kunnen delegeren naar je eigen router.

[ Voor 6% gewijzigd door Dreamvoid op 07-04-2023 12:56 ]

[RobertMe]

Dreamvoid schreef op vrijdag 7 april 2023 @ 12:55:
[...]

Dat is raar inderdaad, dit is toch een behoorlijk veel voorkomend scenario. Is er iets in de Android bugtracker over te vinden?

Valt dit niet semi onder wat je hieronder schrijft? "Je moet gewoon altijd een GUA hebben en anders is IPv6 niet 'volledig'". Vanuit dat punt kan ik in ieder geval volgen dat ze de IPv6 DNS server niet oppikken en ik neem aan DNS queries an zich (by default) ook A zijn en geen AAAA (dus een ipv6-test.com die helemaal uit komt op "geen IPv6", en als ik in Net Analyzer gewoon bv een ping naar tweakers.net doe gaat die ook voor IPv4, pas als ik vinkje "Prefer IPv6" zet gaat die ook IPv6 doen, want... heb natuurlijk geen GUA)

[...]

Dit is niet standaard-conform, als die VPN server een route naar het internet biedt moet de VPN server een GUA subnet intern doorzetten, geen ULA range. ULA ranges zijn voor intranet toepassingen (dus zonder internet toegang, als je de VPN gebruikt om reizende werknemers toch toegang voor het interne bedrijfsnetwerk te geven, of om twee intranets aan elkaar te koppelen). Ik zou even contact opnemen met je VPN provider of ze geen GUA prefix kunnen delegeren naar je eigen router.

Lijkt mij juist logisch dat ze geen GUA leveren? Ik wil anoniem internetten, met een GUA ben ik weer redelijk identificeerbaar Maar een volledig (ULA) subnet zou dan wel weer leuk zijn geweest. Heb overigens ook niet gekeken of/hoe de concurrentie dat doet (dus een NordVPN, Private Internet Access, ExpressVPN etc).

[Dreamvoid]

RobertMe schreef op vrijdag 7 april 2023 @ 13:41:
Lijkt mij juist logisch dat ze geen GUA leveren? Ik wil anoniem internetten, met een GUA ben ik weer redelijk identificeerbaar

Nee zo werkt de privacy niet - met een GUA uit de range van NordVPN zien mensen dat je van NordVPN afkomt. Als je geNAT wordt door NordVPN, dan zien ze dat ook.

[RobertMe]

Dreamvoid schreef op dinsdag 11 april 2023 @ 09:17:
[...]

Nee zo werkt de privacy niet - met een GUA uit de range van NordVPN zien mensen dat je van NordVPN afkomt. Als je geNAT wordt door NordVPN, dan zien ze dat ook.

Door die GUA zien ze wel een uniek IP de hele tijd? Of in ieder geval met Wireguard, omdat die op basis van fixed IPs werkt (en dus niet met DHCP / SLAAC / ...). Dus dan ben ik niet identificeerbaar tot een gebruiker van provider X en mogelijk op basis van GeoIP nog een regio, maar sites zien dan wel elke keer hetzelfde IP adres wat van 1 unieke gebruiker is. Daar waar bij NAT alle gebruikers (van dezelfde VPN server) ook achter hetzelfde IP adres zitten en een site dus moeilijker een unieke bezoeker kan identificeren. (Ja, op basis van cookies en zo, maar ik bezoek vaak genoeg bepaalde sites al in een private window via mijn gewone verbinding, laat staan sites die ik echt va VPN bezoek).

[Dreamvoid]

Je deelt wel een IP adres met anderen, maar je bent nog altijd identificeerbaar aan de port range die NordVPN naar je doorzet. Net zo anoniem als je bv met een mobiele telefoon bent.

[HollowGamer]

Vandaag eens IPv6 ge-enabled voor Ziggo op mijn ASUS router met Merlin, en het werkt gewoon lol.

Ik neem aan dat Native with DHCP-PD voldoende is?
De firewall staat aan, ook krijgen zo te zien al mijn LAN-clients een IPv6 adres.

[Snow_King]

HollowGamer schreef op vrijdag 14 april 2023 @ 12:00:
Vandaag eens IPv6 ge-enabled voor Ziggo op mijn ASUS router met Merlin, en het werkt gewoon lol.

Ik neem aan dat Native with DHCP-PD voldoende is?
De firewall staat aan, ook krijgen zo te zien al mijn LAN-clients een IPv6 adres.

Zo simpel is het ja. Nu vooral aan laten staan en lekker gebruiken :-)

[Dreamvoid]

Ja, prefix delegation is ondersteund op de ConnectBox, dus een downstream router kan gewoon een prefix vragen.

[HollowGamer]

Snow_King schreef op vrijdag 14 april 2023 @ 12:03:
[...]

Zo simpel is het ja. Nu vooral aan laten staan en lekker gebruiken :-)

https://ipv6test.google.com/ - Yes, looks like you’re using IPv6 already.

Nice! Zo te zien brengt IPv6 wel een aantal benefits, dus blij dat het werkt.
Kan mij herinneren dat het een aantal maanden geleden niet lukte, maar nu was het echt binnen 2min. geregeld.

[Snow_King]

HollowGamer schreef op vrijdag 14 april 2023 @ 12:05:
[...]

https://ipv6test.google.com/ - Yes, looks like you’re using IPv6 already.

Nice! Zo te zien brengt IPv6 wel een aantal benefits, dus blij dat het werkt.
Kan mij herinneren dat het een aantal maanden geleden niet lukte, maar nu was het echt binnen 2min. geregeld.

Je kan ook deze test nog even draaien op een paar clients: http://test-ipv6.com/

[RobertMe]

HollowGamer schreef op vrijdag 14 april 2023 @ 12:05:
Kan mij herinneren dat het een aantal maanden geleden niet lukte, maar nu was het echt binnen 2min. geregeld.

IPv6 in fZiggo gebied ondersteunen ze in bridge mode al sinds december '21, en in fUPC sinds voorjaar/zomer? Dus die "aantal maanden" is dan minimaal 3/4 jaar of het zat hem in de firmware.

Of ja, je moest wel een ConnectBox of Ubee UBC1318 hebben (kom je toentertijd gratis omruilen). Intussen hebben ze natuurlijk ook nog die zwarte Sagemcom. Mogelijk dat je dus een modem swap gehad hebt en het daardoor nu pas beschikbaar is?

[HollowGamer]

RobertMe schreef op vrijdag 14 april 2023 @ 12:54:
[...]

IPv6 in fZiggo gebied ondersteunen ze in bridge mode al sinds december '21, en in fUPC sinds voorjaar/zomer? Dus die "aantal maanden" is dan minimaal 3/4 jaar of het zat hem in de firmware.

Of ja, je moest wel een ConnectBox of Ubee UBC1318 hebben (kom je toentertijd gratis omruilen). Intussen hebben ze natuurlijk ook nog die zwarte Sagemcom. Mogelijk dat je dus een modem swap gehad hebt en het daardoor nu pas beschikbaar is?

Klopt, heb het destijds geprobeerd, maar het werkte niet (kreeg geen IPv6 WAN IP).
Daarna een half jaar leer weer.. en nu dus weer, met het verschil dat het nu wel werkt.

Geen idee waarom, misschien waren het settings op mijn router of had ik geen geduld.
Het duurde namelijk een paar min. voordat ik een IPv6 lease kreeg - het is een CB in bridge-mode.

[N8w8]

@RobertMe, ik zie vaker de veronderstelling dat als Ziggo IPv6 niet werkt, dat vooral aan een oud modem zou liggen.
Maar iig mijn ouders hebben geen IPv6, op een standaard Connectbox (CH7465LG) op ex-UPC, waar niks bijzonders mee is gebeurd (qua verzoeken aan klantenservice om IPv6 te blokkeren, of bridge modus oid).

Het "probleem" voor zover je dat zelf kan zien, is dat ie geen IPv6 firmware heeft. Info op het Ziggo forum suggereert dat dat ligt aan dat dat aan Ziggo's kant geblokkeerd is om historische redenen.
Als je dan IPv6 wilt, kan je dat gewoon tegen de klantenservice zeggen en halen ze die blokkering weg. Dus dat is snel opgelost, getuige de mensen die dat op het forum aanvragen.
Het gemak waarmee dit gaat, doet vermoeden dat Ziggo dit best wel zelf automatisch bij iedereen kan rechtzetten, maar dat hebben ze dus nog niet gedaan.

Geen idee hoe vaak dit het probleem is, maar het zou me niet verbazen als dit voor veel meer mensen geldt (nogmaals er is niks bijzonders aan ouders' abo/setup), dat er _enige_ klant actie vereist is. Hoe miniem ook, slechts een handjevol nerds zal dit uit zichzelf doen lijkt mij. Mijn ouders interesseert het ook geen reet bijvoorbeeld, en gelijk hebben ze.
Maar goed, dit zou dus ook wel een groot deel van de geen-IPv6 gevallen kunnen verklaren, ipv alleen maar oude modems.

[RobertMe]

N8w8 schreef op zaterdag 15 april 2023 @ 14:32:
@RobertMe, ik zie vaker de veronderstelling dat als Ziggo IPv6 niet werkt, dat vooral aan een oud modem zou liggen.
Maar iig mijn ouders hebben geen IPv6, op een standaard Connectbox (CH7465LG) op ex-UPC, waar niks bijzonders mee is gebeurd (qua verzoeken aan klantenservice om IPv6 te blokkeren, of bridge modus oid).

Het "probleem" voor zover je dat zelf kan zien, is dat ie geen IPv6 firmware heeft. Info op het Ziggo forum suggereert dat dat ligt aan dat dat aan Ziggo's kant geblokkeerd is om historische redenen.
Als je dan IPv6 wilt, kan je dat gewoon tegen de klantenservice zeggen en halen ze die blokkering weg. Dus dat is snel opgelost, getuige de mensen die dat op het forum aanvragen.
Het gemak waarmee dit gaat, doet vermoeden dat Ziggo dit best wel zelf automatisch bij iedereen kan rechtzetten, maar dat hebben ze dus nog niet gedaan.

Geen idee hoe vaak dit het probleem is, maar het zou me niet verbazen als dit voor veel meer mensen geldt (nogmaals er is niks bijzonders aan ouders' abo/setup), dat er _enige_ klant actie vereist is. Hoe miniem ook, slechts een handjevol nerds zal dit uit zichzelf doen lijkt mij. Mijn ouders interesseert het ook geen reet bijvoorbeeld, en gelijk hebben ze.
Maar goed, dit zou dus ook wel een groot deel van de geen-IPv6 gevallen kunnen verklaren, ipv alleen maar oude modems.

Daar durf ik verder geen uitspraken over te doen, zo goed volg ik de Ziggo ontwikkelingen ook niet. Ik weet alleen dat ze toentertijd met de "IPv6 in bridge" aankondiging dan alleen de CB & Ubee UBC1318 supporten. En op het moment dat je een ouder modem had (zoals ik een antieke Cisco modem only) kon je deze laten omruilen waarbij je ook de keuze had tussen de CB en Ubee. Waar ik toen gebruik van heb gemaakt om expliciet niet een CB met Puma te krijgen (achteraf was een jaartje afwachten en daarna de Sagemcom krijgen wellicht een leukere optie, maarja. Dat die Sagemcom er kwam wist ik niet en voor hetzelfde geldt was net in die periode de 10+ jaar oude Cisco overleden en had ik alsnog een CB gehad).

Kan mij overigens ook indenken dat Ziggo ook onderscheid maakt in wel of geen bridge. In het geval van bridge mode kan IPv6 "aan" omdat het niks doet, immers zal de router ervoor ingesteld moeten zijn etc. Dus dan is het de verantwoordelijkheid van de klant, die moet DHCP PD aan zetten om IPv6 te gebruiken. In router-mode betekent dat dus dat alle apparaten van de klant automatisch met IPv6 gaan werken, zonder dat de klant er iets vanaf weet. Dus als iets dan niet werkt is het meteen de schuld van Ziggo.

[Roetzen]

Ben ik de enige bij wie Firefox W32 tweakers.net alleen via IPv4 kan bereiken of zijn er meer die dit ervaren?

Edit: Het lag waarschijnlijk aan mij. Windows opnieuw opstarten geeft weer een IPv6 verbinding met Tweakers.

[ Voor 34% gewijzigd door Roetzen op 04-05-2023 08:53 ]

[RobertMe]

Gisteren maar eens op mijn VPS gefixt dat de webserver via IPv6 bereikbaar is. Is de Traefik reverse proxy die in Docker gedraaid.
Van de VPS provider krijg ik een /64 (per server). Daarbij maar de keuze gemaakt om een /72 aan de host te assignen en dan kan ik de Docker netwerken ook een /72 geven. Traefik uiteraard maar op de logische 8000::443 gezet (overige containers worden door Docker automatisch een IP toebedeeld en is dan gewoon ::2, ::3, ... in de ...:8000::/72).
Draait ook zakelijk websiteje van familie op (naast self hosted tooltjes/... voor prive gebruik), daarop heb ik Matomo toegevoegd voor analytics. Ding ondersteund blijkbaar geen filters op IPv4 / IPv6. Maar met de 10 bezoekers van vandaag blijkt toch 4/5e IPv6 te gebruiken (8x v6 dus), meer dan verwacht.

Daarnaast net eens op mijn laptop IPv4 "uit gezet". Werd ik toch niet blij van. GitHub doet geen IPv6, Reddit niet (/gek genoeg wel reddit.com, maar www.reddit.com niet en redirect altijd), Ziggo, mijn provider, niet. Dus zeg maar: Tweakers deed het. En verder zo snel geen sites gezien die echt werkten.

[Snow_King]

nieuws: Provider Delta bevestigt Cgnat toe te passen op netwerk voor gedeeld ...

Laat Delta maar eens opschieten met hun IPv6 uitrol. Gisteren graag!

[Snow_King]

RobertMe schreef op zondag 7 mei 2023 @ 20:37:
Gisteren maar eens op mijn VPS gefixt dat de webserver via IPv6 bereikbaar is. Is de Traefik reverse proxy die in Docker gedraaid.
Van de VPS provider krijg ik een /64 (per server). Daarbij maar de keuze gemaakt om een /72 aan de host te assignen en dan kan ik de Docker netwerken ook een /72 geven. Traefik uiteraard maar op de logische 8000::443 gezet (overige containers worden door Docker automatisch een IP toebedeeld en is dan gewoon ::2, ::3, ... in de ...:8000::/72).
Draait ook zakelijk websiteje van familie op (naast self hosted tooltjes/... voor prive gebruik), daarop heb ik Matomo toegevoegd voor analytics. Ding ondersteund blijkbaar geen filters op IPv4 / IPv6. Maar met de 10 bezoekers van vandaag blijkt toch 4/5e IPv6 te gebruiken (8x v6 dus), meer dan verwacht.

Daarnaast net eens op mijn laptop IPv4 "uit gezet". Werd ik toch niet blij van. GitHub doet geen IPv6, Reddit niet (/gek genoeg wel reddit.com, maar www.reddit.com niet en redirect altijd), Ziggo, mijn provider, niet. Dus zeg maar: Tweakers deed het. En verder zo snel geen sites gezien die echt werkten.

Ziggo doet wel IPv6, je moet wellicht even vragen om een nieuw modem.

Als ik kijk op mijn telefoon dan werkt het volgende allemaal prima:

- WhatsApp
- Telegram
- YouTube
- Google Search
- Gmail
- Netflix
- LinkedIn
- Office365
- Tweakers
- Mijn eigen servers

Het is verder vaak wel huilen inderdaad....

[RobertMe]

Snow_King schreef op maandag 8 mei 2023 @ 11:30:
[...]

Ziggo doet wel IPv6, je moet wellicht even vragen om een nieuw modem.

Ik bedoelde de website van Ziggo Heb gewoon IPv6 in bridge verder en dat is ook waarmee ik dus getest heb. Waarbij bv ziggo.nl dus niet bereikbaar is en www.ziggo.nl wel iets doet maar de assets niet geladen kunnen worden, dus ongestylde pagina van witte achtergrond met zwarte tekst (dat Internet Explorer niet meer ondersteund wordt).

[Raven]

Snow_King schreef op maandag 8 mei 2023 @ 11:30:
- Telegram

Die werkt hier niet via IPv6, zowel bij website als python-script dat gebruik maakt van een Telegram-bot krijg ik een timeout via IPv6. In 't script gebruik ik

Python:

requests.packages.urllib3.util.connection.HAS_IPV6 = False

in Firefox is er network.dns.ipv4OnlyDomains.

Oorzaak nog niet gevonden, heb een tijdje terug Telegram hier over gemaild, geen reactie.

[Newjersey]

Nadat ik mijn router heb geüpdated met OpnSense erop werkt ipv6 intern niet meer. Sommige sites wel, sommige niet. Lijkt hem dus in de MTU te zitten, dacht ik.

Als ik een curl naar tweakers.net doe vanaf mijn opnsense box lijkt alles te werken over ipv6. Doe ik dat vanaf iets in mijn lan dan krijg ik een connection timed out. Reverten naar de oude versie heeft ook niet geholpen.

Ik heb de mtu van de fysieke interface op 1512 staan, de mtu op de vlan6 op 1508 en de mtu op de pppoe op 1500. Dit werkte totdat ik een reboot deed. Vreemd ,heel vreemd. Geen touw aan vast te knopen. Het feit dat alles consequent werkt direct vanaf de opnsense box maakt het alsmaar vreemder.

Iemand enig idee waar ik moet beginnen met troubleshooten?

[duvekot]

Newjersey schreef op zaterdag 13 mei 2023 @ 17:04:
Iemand enig idee waar ik moet beginnen met troubleshooten?

Klinkt alsof MTU Path Discovery niet werkt ... En dat kan dan te maken hebben met ICMP die niet doorgelaten wordt vanaf je router naar je clients.

[Newjersey]

duvekot schreef op zaterdag 13 mei 2023 @ 17:26:
[...]

Klinkt alsof MTU Path Discovery niet werkt ... En dat kan dan te maken hebben met ICMP die niet doorgelaten wordt vanaf je router naar je clients.

Ik zal eens even mijn firewall regels checken. Zal wellicht wel daarmee te maken hebben. Ik ga er morgen wel ff mee aan de slag. Thanks voor de tip en ik laat de uitkomst nog wel even weten.

[nero355]

Newjersey schreef op zaterdag 13 mei 2023 @ 17:04:
Nadat ik mijn router heb geüpdated met OpnSense erop werkt ipv6 intern niet meer.

Wat heb je precies gedaan

Reverten naar de oude versie heeft ook niet geholpen.

Welke versies praten we dan over
Welke software ?!

[Newjersey]

nero355 schreef op zaterdag 13 mei 2023 @ 18:23:
[...]

Wat heb je precies gedaan


[...]

Welke versies praten we dan over
Welke software ?!

Upgrade Opnsense van versie 23.1.4 naar 23.1.7

[Newjersey]

duvekot schreef op zaterdag 13 mei 2023 @ 17:26:
[...]

Klinkt alsof MTU Path Discovery niet werkt ... En dat kan dan te maken hebben met ICMP die niet doorgelaten wordt vanaf je router naar je clients.

ICMP voor IPv6 stond blijkbaar al open. Nog even snel een any -> any rule IPv66 vanaf wan aangemaakt ter test, maar dit werkt ook niet. Tweakers.net blijft onbereikbaar via IPv6. ipv6.google.com is gekgenoeg wel bereikbaar. Ook mijn VPS is bereikbaar via IPv6. Het lijkt zich dus niet structureel op elk IPv6 adres voor te doen.

Het vreemde is overigens wel dat de connectie wel geïnitieerd lijkt te worden.

code:

❯ curl -v https://tweakers.net -6
* Rebuilt URL to: https://tweakers.net/
*   Trying 2001:9a8:0:e:1337:0:80:2...
* TCP_NODELAY set
* Connected to tweakers.net (2001:9a8:0:e:1337:0:80:2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Alleen krijg ik geen gegevens terug.

edit 2: mss clamping vastgezet op 1440 en dit lijkt te werken. Bizar... Geen idee wat het exact doet maar las het ergens op reddit.

[ Voor 41% gewijzigd door Newjersey op 13-05-2023 19:10 ]

[Nakebod]

Een stukje voor het archief Onbegrepen Stukken.

2 weken terug gedowngrade van XS4ALL/KPN naar T-Mobile. Bij gebrek aan IPv6 (Welkom in 2023..) mijn oude HE account eens afgestoft.
Config in OPNSense was zo gedaan en ik was weer online met IPv6. Tenminste, gedeeltelijk.
Via bekabeld netwerk geen problemen. Via WiFi... Afhankelijk van het gebruikte SSID.
Op mijn primaire SSID kreeg ik het niet werkend, terwijl het op andere SSID's wel werkte.

Apparaten kregen wel netjes een IPv6 adres toegewezen maar al het verkeer leek wel in een zwart gat te verdwijnen. In de firewall logs zag ik het verkeer doorgelaten worden, maar verder niets.

In de UniFi controller instellingen van de verschillende SSID's vergeleken en ik kon geen verschil vinden.
Uiteindelijk mijn primaire SSID eens helemaal verwijderd, opnieuw aangemaakt en... werkend.

Kan je best lang naar zoeken zo.

[nero355]

@Nakebod
Typisch gevalletje #JustUbiquitiUniFiThings

[stormfly]

Nakebod schreef op zondag 14 mei 2023 @ 20:10:
Een stukje voor het archief Onbegrepen Stukken.

2 weken terug gedowngrade van XS4ALL/KPN naar T-Mobile. Bij gebrek aan IPv6 (Welkom in 2023..) mijn oude HE account eens afgestoft.
Config in OPNSense was zo gedaan en ik was weer online met IPv6. Tenminste, gedeeltelijk.
Via bekabeld netwerk geen problemen. Via WiFi... Afhankelijk van het gebruikte SSID.
Op mijn primaire SSID kreeg ik het niet werkend, terwijl het op andere SSID's wel werkte.

Apparaten kregen wel netjes een IPv6 adres toegewezen maar al het verkeer leek wel in een zwart gat te verdwijnen. In de firewall logs zag ik het verkeer doorgelaten worden, maar verder niets.

In de UniFi controller instellingen van de verschillende SSID's vergeleken en ik kon geen verschil vinden.
Uiteindelijk mijn primaire SSID eens helemaal verwijderd, opnieuw aangemaakt en... werkend.

Kan je best lang naar zoeken zo.

IPv6 gaat stuk zodra je "network isolation" inschakelt, dan blocken ze de noodzakelijke ICMPv6 data.

[RobertMe]

stormfly schreef op zondag 14 mei 2023 @ 22:39:
[...]


IPv6 gaat stuk zodra je "network isolation" inschakelt, dan blocken ze de noodzakelijke ICMPv6 data.

Network isolation als in gast netwerk? Toen ik nog de UniFi Security Gateway gebruikte werkte IPv6 niet op het gast netwerk. Nu ik een zelfbouw router heb wel, met verder dus dezelfde configuratie. Gezien @Nakebod OpnSense heeft zal hij dus geen unifi router hebben.

[stormfly]

RobertMe schreef op zondag 14 mei 2023 @ 23:07:
[...]

Network isolation als in gast netwerk? Toen ik nog de UniFi Security Gateway gebruikte werkte IPv6 niet op het gast netwerk. Nu ik een zelfbouw router heb wel, met verder dus dezelfde configuratie. Gezien @Nakebod OpnSense heeft zal hij dus geen unifi router hebben.

Je kunt isolation op het SSID of op het netwerk segment inschakelen.

[RobertMe]

stormfly schreef op maandag 15 mei 2023 @ 07:40:
[...]


Je kunt isolation op het SSID of op het netwerk segment inschakelen.

En ik heb dat uiteraard ook aan staan op het gast netwerk (wifi/SSID dus) En sinds ik de USG niet meer gebruik werkt IPv6 prima op het gast netwerk.

[Nakebod]

stormfly schreef op zondag 14 mei 2023 @ 22:39:
[...]
IPv6 gaat stuk zodra je "network isolation" inschakelt, dan blocken ze de noodzakelijke ICMPv6 data.

Isolation stond niet aan. Alle instellingen, zichtbaar via de webinterface tenminste, stonden exact hetzelfde als op mijn andere SSID's. Ook na het opnieuw aanmaken.
Dus zichtbaar geen verschil in de instellingen, behalve dat het nu wel werkt.

[stormfly]

RobertMe schreef op maandag 15 mei 2023 @ 07:52:
[...]

En ik heb dat uiteraard ook aan staan op het gast netwerk (wifi/SSID dus) En sinds ik de USG niet meer gebruik werkt IPv6 prima op het gast netwerk.

Okey goede conclusie, ik zal het ook eens testen als er tijd is.

[St00mwals]

nieuws: Delta gaat vanaf vierde kwartaal IPv6-adressen geven aan glasvezelkla...

[Snow_King]

Ik zette vorige week een IPv6-only Grafana en InfluxDB server voor mijzelf op om wat home automation data in op te slaan. Energieverbruik thuis, wat temperatuur sensoren, etc.

Nu was ik net op de Grafana server bezig en zag ik dat 2001:470:1:c84::12 een SSH poging had gedaan tot deze server.

De whois laat mij zien dat deze van https://www.shadowserver.org/ is, opzich prima dat ze die scan doen.

Ik vind het alleen heel interessant dat men een SLAAC gegenereert adres wat vorige week online is gekomen nu al weet te vinden.

Overigens zie ik inmiddels op mijn router al wel vaker wat IPv6 'scans' voorbij komen. Nu is het adres van de router makkelijker omdat deze ::1 in de subnets heeft, maar deze van het SLAAC adres vond ik wel erg interessant.

[RobertMe]

Snow_King schreef op woensdag 5 juli 2023 @ 16:37:
Ik zette vorige week een IPv6-only Grafana en InfluxDB server voor mijzelf op om wat home automation data in op te slaan. Energieverbruik thuis, wat temperatuur sensoren, etc.

Nu was ik net op de Grafana server bezig en zag ik dat 2001:470:1:c84::12 een SSH poging had gedaan tot deze server.

De whois laat mij zien dat deze van https://www.shadowserver.org/ is, opzich prima dat ze die scan doen.

Ik vind het alleen heel interessant dat men een SLAAC gegenereert adres wat vorige week online is gekomen nu al weet te vinden.

Overigens zie ik inmiddels op mijn router al wel vaker wat IPv6 'scans' voorbij komen. Nu is het adres van de router makkelijker omdat deze ::1 in de subnets heeft, maar deze van het SLAAC adres vond ik wel erg interessant.

Maar waarom heb je uberhaupt SSH open staan thuis?

In mijn zelfbouw router staat IIRC alleen Wireguard open en voor de rest "niks" (wat IPv6 ICMP verkeer en DHCPv6 voor prefix delegation).

[Snow_King]

RobertMe schreef op woensdag 5 juli 2023 @ 16:45:
[...]

Maar waarom heb je uberhaupt SSH open staan thuis?

In mijn zelfbouw router staat IIRC alleen Wireguard open en voor de rest "niks" (wat IPv6 ICMP verkeer en DHCPv6 voor prefix delegation).

Deze servers draaien op een public cloud, maar zijn IPv6-only. Ik stuur alleen de data die kant op via IPv6 en bezoek de systemen ook enkel via IPv6.

De discussie over SSH wel of niet open is niet direct nodig, maar goed. SSH staat gewoon open, maar alleen key authentication. Vind ik veilig genoeg.

[RobertMe]

Snow_King schreef op woensdag 5 juli 2023 @ 17:12:
[...]

Deze servers draaien op een public cloud, maar zijn IPv6-only. Ik stuur alleen de data die kant op via IPv6 en bezoek de systemen ook enkel via IPv6.

De discussie over SSH wel of niet open is niet direct nodig, maar goed. SSH staat gewoon open, maar alleen key authentication. Vind ik veilig genoeg.

Ah nee, ik ging uit van thuis iets draaien, IPv6 only. En ging er van uit dat je in de (thuis)router dus dat IPv6 adres + poort open had gezet.
Dat je op een server "rechtstreeks aan internet" (/public cloud/VPS dus) SSH open hebt staan is redelijk logisch.

Oftewel: assumpion is the mother of all fuckups Dat ik die stuff in LAN draai betekent niet dat anderen dat ook doen. En de opmerking m.b.t. router die op ::1 ook gescand wordt zette me helemaal op verkeerde been.

[Dreamvoid]

Nou ja, je kan bv ervoor kiezen om SSH alleen over een mesh-VPN als ZeroTier te laten lopen. Grootste probleem dat je dan wel hebt, is dat je eventuele problemen met Zerotier niet kan oplossen, want je kan je server dan niet in

Je kan natuurlijk SSH op meer manieren verder afschermen, bv alleen de IP ranges waarover je inlogt whitelisten in de firewall. Er is geen enkele reden te bedenken waarom je elk willekeurig netwerk ter wereld zelfs maar de gelegenheid moet geven om een login te proberen.

[Muis666]

Dreamvoid schreef op donderdag 6 juli 2023 @ 10:16:
Je kan natuurlijk SSH op meer manieren verder afschermen, bv alleen de IP ranges waarover je inlogt whitelisten in de firewall. Er is geen enkele reden te bedenken waarom je elk willekeurig netwerk ter wereld zelfs maar de gelegenheid moet geven om een login te proberen.

Volgens mij is het toch wel gebruikelijk om ssh open te zetten naar het internet. Maar dan wel met alleen key based authentication, geen username/password.

[Snow_King]

Muis666 schreef op donderdag 6 juli 2023 @ 11:48:
[...]

Volgens mij is het toch wel gebruikelijk om ssh open te zetten naar het internet. Maar dan wel met alleen key based authentication, geen username/password.

Exact. Als er een stukje software is waar ik wel vertrouwen in heb is dat OpenSSH wel.

Wel enkel keybased auth, password auth moet uit staan.

Al jaren heb ik op voldoende servers SSH gewoon open staan voor de wereld op deze manier.

[Dreamvoid]

Nou ja, het is toch wel best-practice om in de firewall niet de hele wereld toegang te geven tot je SSH.

[Snow_King]

Dreamvoid schreef op vrijdag 7 juli 2023 @ 09:12:
Nou ja, het is toch wel best-practice om in de firewall niet de hele wereld toegang te geven tot je SSH.

Om het on-topic te houden: Ik vind het op IPv6 prima te doen om SSH open te zetten voor de wereld. Op IPv4 vind ik al die scans gewoon irritant veel.

Of het echt best-practice is: Dat is een mening wat mij betreft, geen feit. Ik vind het prima om SSH open te zetten naar de wereld, maar wel enkel met keys.

Op IPv6 vinden de scanners je gewoon net wat minder snel, dat is handig. Je moet echter wel gewoon je updates draaien, maar dat moet je sowieso al.

[Dreamvoid]

Oh absoluut, je bent al die random driveby's kwijt. Maar alsnog is firewalling een vrij simpele actie die een hoop potentieel risico wegneemt.

[RobertMe]

Dreamvoid schreef op vrijdag 7 juli 2023 @ 10:26:
Oh absoluut, je bent al die random driveby's kwijt. Maar alsnog is firewalling een vrij simpele actie die een hoop potentieel risico wegneemt.

Daarvoor terug krijg je wel het risico dat het IP adres van de "client" wijzigt en je helemaal niet meer naar de server kunt SSHen. Als in: als ik dat zou doen met het IP adres van mijn Ziggo lijntje thuis weet ik ook direct zeker dat ik niet merr in mijn server kan komen via SSH op het moment dat ik een ander IP adres krijg.

@Snow_King, security by obscurity werkt natuurlijk ook weer slecht als het een publieke server is. Als je een (publieke) website (/mailserver/...) er op host is het IP adres immers bekend/terug te vinden. Tenzij... ontopic, je van de provider een /64 of groter krijgt en de diensten luisteren op verschillende IP adressen. Dus bv SSH die alleen luistert op ::22 en de webserver die luistert op ::80.

[Snow_King]

RobertMe schreef op vrijdag 7 juli 2023 @ 10:41:
[...]

Daarvoor terug krijg je wel het risico dat het IP adres van de "client" wijzigt en je helemaal niet meer naar de server kunt SSHen. Als in: als ik dat zou doen met het IP adres van mijn Ziggo lijntje thuis weet ik ook direct zeker dat ik niet merr in mijn server kan komen via SSH op het moment dat ik een ander IP adres krijg.

@Snow_King, security by obscurity werkt natuurlijk ook weer slecht als het een publieke server is. Als je een (publieke) website (/mailserver/...) er op host is het IP adres immers bekend/terug te vinden. Tenzij... ontopic, je van de provider een /64 of groter krijgt en de diensten luisteren op verschillende IP adressen. Dus bv SSH die alleen luistert op ::22 en de webserver die luistert op ::80.

Ik zou het op IPv6 geen "security by obscurity" noemen, want ook op IPv4 vind ik het prima om SSH open te zetten voor de wereld (key based!).

Het irritante met IPv4 vind ik de /var/log/auth.log (Ubuntu) die helemaal vol staat met al die scans de hele dag door. Die zijn er met IPv6 amper en dat maakt de server gewoon wat stiller.

Ik kan nu gewoon met CloudFlare WARP (met IPv6!) of andere IPv6-enabled VPN aanzetten op een plek waar ik geen IPv6 heb en kan bij mijn servers. Vanaf huis en kantoor kan ik er direct bij zonder tussenkomst van een VPN.

De OpenSSH server is toch echt wel een stukje software waar ik na 20 jaar gebruik echt heel veel vertrouwen in heb.

[Dreamvoid]

RobertMe schreef op vrijdag 7 juli 2023 @ 10:41:
[...]
Daarvoor terug krijg je wel het risico dat het IP adres van de "client" wijzigt en je helemaal niet meer naar de server kunt SSHen. Als in: als ik dat zou doen met het IP adres van mijn Ziggo lijntje thuis weet ik ook direct zeker dat ik niet merr in mijn server kan komen via SSH op het moment dat ik een ander IP adres krijg.

Je whitelist in dat geval natuurlijk geen individueel adres, maar bv het hele Ziggo netwerk, samen met een aantal andere (die van je mobiele telco, etc).

[RobertMe]

Dreamvoid schreef op vrijdag 7 juli 2023 @ 14:56:
[...]

Je whitelist in dat geval natuurlijk geen individueel adres, maar bv het hele Ziggo netwerk, samen met een aantal andere (die van je mobiele telco, etc).

Hoe achterhaal je die ranges?

[Dreamvoid]

Dit bv: https://www.ip2location.com/as33915

AS33915 is Ziggo+Vodafone, er is ook nog AS15480 (voor Vodafone zakelijk geloof ik)
AS1136 is KPN
AS50266 en AS31615 zijn T-Mobile Thuis en mobiel
AS15435 en AS15542 is Delta

dan heb je zo'n beetje heel consumenten-Nederland (er zijn natuurlijk ook nog kleintjes als Solcon, Lyca Mobile, Freedom Internet, Starlink etc)

[ Voor 77% gewijzigd door Dreamvoid op 07-07-2023 15:49 ]

[nero355]

Snow_King schreef op vrijdag 7 juli 2023 @ 11:08:
Het irritante met IPv4 vind ik de /var/log/auth.log (Ubuntu) die helemaal vol staat met al die scans de hele dag door. Die zijn er met IPv6 amper en dat maakt de server gewoon wat stiller.

Fail2Ban + SysLogNG draaien en dan op zo'n manier dat je daar niet zoveel last van hebt

/Brainfart...

[Raven]

Zijn er tegenwoordig manieren om op basis van domeinnaam erachter te komen welke geo-IP database er op de achtergrond gebruikt wordt?

Vandaag de overstap van Rtl Gemist naar Videoland meegemaakt, bij de eerste was er nooit wat aan de hand, bij de 2e moet IPv6 uitgeschakeld worden om toegang te krijgen tot de content

Vermoedelijk maken ze daar gebruik van een database die aangeeft dat mijn /48 uitkomt in een ander land en dat land zal waarschijnlijk de USA zijn, specifiek Fremont, CA.

[Snow_King]

Raven schreef op dinsdag 25 juli 2023 @ 17:37:
Zijn er tegenwoordig manieren om op basis van domeinnaam erachter te komen welke geo-IP database er op de achtergrond gebruikt wordt?

Vandaag de overstap van Rtl Gemist naar Videoland meegemaakt, bij de eerste was er nooit wat aan de hand, bij de 2e moet IPv6 uitgeschakeld worden om toegang te krijgen tot de content

Vermoedelijk maken ze daar gebruik van een database die aangeeft dat mijn /48 uitkomt in een ander land en dat land zal waarschijnlijk de USA zijn, specifiek Fremont, CA.

Wij hebben Videoland met IPv6 (Ziggo) en nergens last van.

Gebruik je een Tunnel van HE voor je IPv6?

[Raven]

Snow_King schreef op dinsdag 25 juli 2023 @ 18:25:
Gebruik je een Tunnel van HE voor je IPv6?

Jup, had ik als abbr/tooltip toegevoegd achter "Fremont, CA"

[Snow_King]

Ik kom net op de Ziggo en Vodafone website en zie ineens dat beide sites IPv6 hebben. Dit hadden ze een tijdje terug nog niet.

Ziggo.nl lijkt op AWS EC2 te draaien:

code:

www.ziggo.nl has address 13.227.219.83
www.ziggo.nl has address 13.227.219.15
www.ziggo.nl has address 13.227.219.74
www.ziggo.nl has address 13.227.219.79
www.ziggo.nl has IPv6 address 2600:9000:21c7:5e00:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:1a00:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:c200:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:3e00:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:d000:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:2e00:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:b800:10:1a2a:7a00:93a1
www.ziggo.nl has IPv6 address 2600:9000:21c7:3c00:10:1a2a:7a00:93a1

En Vodafone.nl via een Anti-DDoS oplossing van Imperva:

code:

www.vodafone.nl is an alias for 4o9qpig.impervadns.net.
4o9qpig.impervadns.net has address 45.223.138.71
4o9qpig.impervadns.net has IPv6 address 2a02:e980:163::47

Hun mailservers zijn beide helaas nog IPv4-only....

KPN doet dit wel het beste

code:

kpn.com has address 99.83.136.155
kpn.com has address 75.2.72.204
kpn.com has IPv6 address 2600:9000:a504:9080:40c0:d138:ca59:2e3d
kpn.com has IPv6 address 2600:9000:a400:dede:1a1c:a23f:9ae6:7bbc

code:

kpn-com.mail.protection.outlook.com has address 52.101.68.21
kpn-com.mail.protection.outlook.com has address 52.101.68.3
kpn-com.mail.protection.outlook.com has address 52.101.68.5
kpn-com.mail.protection.outlook.com has address 52.101.68.0
kpn-com.mail.protection.outlook.com has address 52.101.73.2
kpn-com.mail.protection.outlook.com has address 52.101.73.6
kpn-com.mail.protection.outlook.com has address 52.101.73.1
kpn-com.mail.protection.outlook.com has address 52.101.73.4
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::1
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::1
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::2
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::2
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::3
kpn-com.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::4

Ze hebben bij Microsoft dus om de opt-in gevraagd voor IPv6 op KPN.com

NOS.nl heeft dit eindelijk ook gedaan, tijdje achteraan gezeten:

code:

nos-nl.mail.protection.outlook.com has address 104.47.1.36
nos-nl.mail.protection.outlook.com has address 104.47.2.36
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::1
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::3
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca09::2
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::4
nos-nl.mail.protection.outlook.com has IPv6 address 2a01:111:f403:ca04::1

[valkenier]

Edit: nevermind


Ziggo heeft recent zijn hele mail omgeving voor de klant in een LG cluster ondergebracht, maar idd nog geen IPv6 daarop.

[ Voor 97% gewijzigd door valkenier op 31-07-2023 14:20 ]

[Snow_King]

nieuws: AWS gaat geld vragen voor gebruik van publieke IPv4-adressen

Dit is dan weer leuk nieuws! Die prijs mag nog wel wat hoger (ook bij Azure) om men nog eens wat harder te laten nadenken.

[Raven]

Weet iemand hoe je timeouts via IPv6 bij een specifieke domeinnaam kunt troubleshooten?

Een tijd terug viel het mij op dat de website van Telegram niet wilde openen, tenzij ik IPv4 forceerde (sindsdien ingesteld in Firefox), later liep ik tegen hetzelfde aan toen ik een python-script berichten via een Telegram-bot wilde laten versturen (code toegevoegd om IPv4 te forceren) en gisteren kwam Home Assistant erbij. Die heb ik ook gekoppeld aan een bot, maar berichten komen (meestal) niet aan en resulteren in foutmeldingen wanneer IPv6 aanstaat, helaas is het bij Home Assistant in het geval van IPv6 een alles of niets verhaal.

Home Assistant geeft dit als fout:

Error sending message: urllib3 HTTPError HTTPSConnectionPool(host='api.telegram.org', port=443): Max retries exceeded with url: /bot*api:key*/sendMessage (Caused by ConnectTimeoutError(<telegram.vendor.ptb_urllib3.urllib3.connectionpool.HTTPSConnectionPool object at 0x7f390aa9d570>, 'Connect timed out. (connect timeout=5.0)')). Args: (*chatID*, 'Hello Dave.'), kwargs: {'parse_mode': 'Markdown', 'disable_web_page_preview': None, 'disable_notification': False, 'reply_to_message_id': None, 'reply_markup': None, 'timeout': None}

Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after connection broken by 'ConnectTimeoutError(<telegram.vendor.ptb_urllib3.urllib3.connectionpool.HTTPSConnectionPool object at 0x7f390aa9d570>, 'Connect timed out. (connect timeout=5.0)')': /bot*api:key*/sendMessage

desktop browsers een timeout melding en de support van Telegram heeft nooit gereageerd op mijn probleem

Het enige wat ik met Google heb kunnen vinden is Telegram (and some others) have a weird TCP timeout during the TLS handshake over IPv6 wat overeen lijkt te komen, al kan ik die exacte situatie met curl in Cygwin niet reproduceren.

edit: Ubuntu:

curl https://telegram.org -v
* Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

curl https://web.telegram.org -v
* Trying [2001:67c:4e8:f004::9]:443...
* Connected to web.telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to web.telegram.org:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

curl https://api.telegram.org -v
* Trying [2001:67c:4e8:f004::9]:443...
* Connected to api.telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to api.telegram.org:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

[ Voor 27% gewijzigd door Raven op 01-08-2023 11:38 ]

[valkenier]

@Raven Ik kan het niet reproduceren. Kan je het eens vanuit een ander IPv6 blok proberen?

code:

curl https://www.telegram.org -v
*   Trying 2001:67c:4e8:f004::9:443...
* Connected to www.telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.telegram.org
*  start date: Aug 10 15:56:28 2022 GMT
*  expire date: Sep 11 15:56:28 2023 GMT
*  subjectAltName: host "www.telegram.org" matched cert's "*.telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x559f8cf7bb60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: www.telegram.org
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
< server: nginx/1.18.0
< date: Tue, 01 Aug 2023 12:18:29 GMT
< content-type: text/html; charset=utf-8
< content-length: 19649
< set-cookie: stel_ssid=1489ac13f8e20616e1_11622807519326643616; expires=Tue, 01 Aug 2023 23:25:09 GMT; path=/; samesite=None; secure; HttpOnly
< pragma: no-cache
< cache-control: no-store
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
<!DOCTYPE html>
html meuk
</html>
<!-- page generated in 8.52ms -->
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host www.telegram.org left intact

code:

curl https://web.telegram.org -v
*   Trying 2001:67c:4e8:f004::9:443...
* Connected to web.telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.web.telegram.org
*  start date: Aug 29 00:39:34 2022 GMT
*  expire date: Sep 30 00:39:34 2023 GMT
*  subjectAltName: host "web.telegram.org" matched cert's "web.telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x5572fff55b60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: web.telegram.org
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
< HTTP/2 200 
< server: nginx/1.18.0
< date: Tue, 01 Aug 2023 12:29:23 GMT
< content-type: text/html
< content-length: 1672
< last-modified: Fri, 18 Dec 2020 13:53:22 GMT
< etag: "5fdcb452-688"
< expires: Tue, 01 Aug 2023 13:29:23 GMT
< cache-control: max-age=3600
< x-frame-options: deny
< accept-ranges: bytes
< 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
<!doctype html>
blabla

code:

curl https://api.telegram.org -v
*   Trying 2001:67c:4e8:f004::9:443...
* Connected to api.telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.telegram.org
*  start date: Mar 26 07:39:18 2023 GMT
*  expire date: Apr 26 07:39:18 2024 GMT
*  subjectAltName: host "api.telegram.org" matched cert's "api.telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x55f8754e4b60)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: api.telegram.org
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
< HTTP/2 302 
< server: nginx/1.18.0
< date: Tue, 01 Aug 2023 12:30:46 GMT
< content-type: text/html
< content-length: 145
< location: https://core.telegram.org/bots
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, OPTIONS
< access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection
< 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

[ Voor 48% gewijzigd door valkenier op 01-08-2023 14:33 ]

[Raven]

valkenier schreef op dinsdag 1 augustus 2023 @ 14:20:
@Raven Ik kan het niet reproduceren. Kan je het eens vanuit een ander IPv6 blok proberen?

Indien ik het vanaf een PineTab (in ander VLAN en /64) probeer, dan krijg ik dezelfde output als jij, doe ik hetzelfde in de default VLAN (waar o.a. Home Assistant in zit) dan krijg ik

code:

$ curl https://telegram.org -v
* STATE: INIT => CONNECT handle 0x80008f028; line 1834 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => RESOLVING handle 0x80008f028; line 1880 (connection #0)
* family0 == v6, family1 == v4
*   Trying 2001:67c:4e8:f004::9:443...
* STATE: RESOLVING => CONNECTING handle 0x80008f028; line 1964 (connection #0)
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* STATE: CONNECTING => PROTOCONNECT handle 0x80008f028; line 2027 (connection #0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* Didn't find Session ID in cache for host HTTPS://telegram.org:443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* STATE: PROTOCONNECT => PROTOCONNECTING handle 0x80008f028; line 2047 (connection #0)
* OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443
* multi_done: status: 35 prem: 1 done: 0
* The cache now contains 0 members
* Closing connection 0
* Expire cleared (transfer 0x80008f028)
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443

in Cygwin of eerder geposte output in Ubuntu.

[valkenier]

@Raven Dat riekt naar een blokkade bij telegram op je /64. Doe telegram dat uberhaupt? Misschien bij teveel logins/mislukte logins? maximum api gebruik?

[Raven]

valkenier schreef op dinsdag 1 augustus 2023 @ 18:28:
@Raven Dat riekt naar een blokkade bij telegram op je /64. Doe telegram dat uberhaupt? Misschien bij teveel logins/mislukte logins? maximum api gebruik?

De desktop app doet het prima in de default VLAN, nou weet ik echter niet in hoeverre die een fallback naar IPv4 doet.

Maar dan nog, het is niet alleen api.telegram.org die niet werkt, ook de hoofdsite en web.telegram.org geven timeouts. Bij een ban/blokkade verwacht ik een melding daarover, ik ken geen enkele site die bij een ban/blokkade een timeout geeft en in het geval van API-overschrijding zou ik ook een (fout)melding verwachten en alleen bij api.telegram.org.

M.b.t. API: "The Telegram API has a limitation to send only 30 messages per second"
Daar kom ik niet eens in de buurt, toen ik nog bij Binance zat en een dust-cleanup scriptje liet Telegrammen, waren dat er op zijn hoogst 30 per dag.

[valkenier]

api, web, en www is allemaal 2001:67c:4e8:f004::9 zoals je ziet. Ik kan het niet goed verklaren verder. de server geeft een tcp reset terug bij jou. itt bij mij. dan denk ik aan een ban.

[Raven]

valkenier schreef op dinsdag 1 augustus 2023 @ 18:37:
api, web, en www is allemaal 2001:67c:4e8:f004::9 zoals je ziet. Ik kan het niet goed verklaren verder. de server geeft een tcp reset terug bij jou. itt bij mij. dan denk ik aan een ban.

Via curl een reset, in de browsers, python scripts en Home Assistant timeout, zit blijkbaar verschil in

edit: @valkenier
Met http geen tcp-reset met curl:

curl http://web.telegram.org -v
* STATE: INIT => CONNECT handle 0x80008f028; line 1834 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => RESOLVING handle 0x80008f028; line 1880 (connection #0)
* family0 == v6, family1 == v4
* Trying 2001:67c:4e8:f004::9:80...
* STATE: RESOLVING => CONNECTING handle 0x80008f028; line 1964 (connection #0)
* Connected to web.telegram.org (2001:67c:4e8:f004::9) port 80 (#0)
* STATE: CONNECTING => PROTOCONNECT handle 0x80008f028; line 2027 (connection #0)
* STATE: PROTOCONNECT => DO handle 0x80008f028; line 2050 (connection #0)
> GET / HTTP/1.1
> Host: web.telegram.org
> User-Agent: curl/7.82.0
> Accept: */*
>
* STATE: DO => DID handle 0x80008f028; line 2146 (connection #0)
* STATE: DID => PERFORMING handle 0x80008f028; line 2265 (connection #0)
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.18.0
< Date: Tue, 01 Aug 2023 16:48:27 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
< Location: https://web.telegram.org/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
* STATE: PERFORMING => DONE handle 0x80008f028; line 2464 (connection #0)
* multi_done: status: 0 prem: 0 done: 0
* Connection #0 to host web.telegram.org left intact
* Expire cleared (transfer 0x80008f028)

Zelfde als bij https://estada.ch/2023/2/...-tls-handshake-over-ipv6/
"The routing works and since HTTP without encryption works I suspect at least one middle box doing something weird with TLS 1.3 instead of just forwarding the data."

[ Voor 76% gewijzigd door Raven op 01-08-2023 18:50 ]

[valkenier]

Hmm ja, ik kan de TLS handshake niet helemaal interpreteren, maar uit wat ik terug rijg zie ik zowel communicatie over TLS 1.3 en TLS 1.2. Dat vond ik merkwaardifg. Jouw verbinding krijgt een reset onmiddelijk na:

* ALPN, offering http/1.1
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none o

Ik zie het hier misgaan, maar vat niet waarom...

De post die je aanhaalt vraagt zich ook af: Is the source network the cause? Net als ik...
Welke provider heb je?

[Raven]

valkenier schreef op dinsdag 1 augustus 2023 @ 23:42:
Hmm ja, ik kan de TLS handshake niet helemaal interpreteren, maar uit wat ik terug rijg zie ik zowel communicatie over TLS 1.3 en TLS 1.2. Dat vond ik merkwaardifg. Jouw verbinding krijgt een reset onmiddelijk na:

* ALPN, offering http/1.1
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none o

Ik zie het hier misgaan, maar vat niet waarom...

Mijn 1e gedachte bij TLS issues was ESET Internet Security, maar de instelling die SSL/TLS controle doet staat al jaren uit omdat die nog wel eens voor problemen zorgde, plus Home Assistant en browsers in o.a. Ubuntu vertonen hetzelfde probleem (zei het met timeout i.p.v. connection reset) en die zijn niet voorzien van ESET Internet Security.

Daarna firewall op de router-pc: De regels m.b.t. internettoegang zijn voor alle VLAN's hetzelfde, verkeer van achter de router naar internet toestaan, van buiten naar binnen alleen related/established.

De enige verschillen die ik tussen beide VLAN's kan bedenken is dat de werkende om draadloos gaat en Pi-Hole zit ertussen, verder geen verschillen die ik zo kan bedenken.

valkenier schreef op dinsdag 1 augustus 2023 @ 23:42:
Welke provider heb je?

Voor IPv6 Hurricane Electric, voor IPv4 Tweak, zou bij HE wel een topic aan kunnen maken, misschien dat iemand daar het weet.

[Snow_King]

Raven schreef op dinsdag 1 augustus 2023 @ 11:15:
Weet iemand hoe je timeouts via IPv6 bij een specifieke domeinnaam kunt troubleshooten?

Een tijd terug viel het mij op dat de website van Telegram niet wilde openen, tenzij ik IPv4 forceerde (sindsdien ingesteld in Firefox), later liep ik tegen hetzelfde aan toen ik een python-script berichten via een Telegram-bot wilde laten versturen (code toegevoegd om IPv4 te forceren) en gisteren kwam Home Assistant erbij. Die heb ik ook gekoppeld aan een bot, maar berichten komen (meestal) niet aan en resulteren in foutmeldingen wanneer IPv6 aanstaat, helaas is het bij Home Assistant in het geval van IPv6 een alles of niets verhaal.

Home Assistant geeft dit als fout:

[...]

desktop browsers een timeout melding en de support van Telegram heeft nooit gereageerd op mijn probleem

Het enige wat ik met Google heb kunnen vinden is Telegram (and some others) have a weird TCP timeout during the TLS handshake over IPv6 wat overeen lijkt te komen, al kan ik die exacte situatie met curl in Cygwin niet reproduceren.

edit: Ubuntu:

[...]

Puur een FYI, bij mij werkt dit prima. Vanaf MacOS met een verbinding met native IPv6:

code:

curl https://telegram.org -v -I
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.telegram.org
*  start date: Aug 10 15:56:28 2022 GMT
*  expire date: Sep 11 15:56:28 2023 GMT
*  subjectAltName: host "telegram.org" matched cert's "telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: telegram.org]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x123012e00)
> HEAD / HTTP/2
> Host: telegram.org
> user-agent: curl/7.88.1
> accept: */*
> 
< HTTP/2 200 
HTTP/2 200 
< server: nginx/1.18.0
server: nginx/1.18.0
< date: Wed, 02 Aug 2023 06:58:27 GMT
date: Wed, 02 Aug 2023 06:58:27 GMT
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8
< content-length: 19649
content-length: 19649
< set-cookie: stel_ssid=e12d2c0e76de005a83_997227742449489484; expires=Wed, 02 Aug 2023 18:05:07 GMT; path=/; samesite=None; secure; HttpOnly
set-cookie: stel_ssid=e12d2c0e76de005a83_997227742449489484; expires=Wed, 02 Aug 2023 18:05:07 GMT; path=/; samesite=None; secure; HttpOnly
< pragma: no-cache
pragma: no-cache
< cache-control: no-store
cache-control: no-store
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
strict-transport-security: max-age=31536000; includeSubDomains; preload

< 
* Connection #0 to host telegram.org left intact

[valkenier]

@Raven aha een IPv6 tunnel. Nogmaals ik kan de vinger er niet opleggen, maar vanaf mijn native IPv6 werkt het gewoon. Ondersteunt tweak geen native IPv6? Op hun website:

IPv6
De IPv4-adressen zijn op en om die uitdaging het hoofd te bieden wordt IPv6 het nieuwe protocol waarop ons internet van de toekomst zal blijven werken. Helaas is nog niet iedereen zo ver dat een overstap op 'native IPv6' gesneden koek is. Ook wij zijn nog niet klaar om alle klanten op grote schaal met IPv6 te bedienen. Wel kun je in de meeste gebieden native IPv6 activeren in je router als je IPv6 wilt gebruiken.

Nou, ik zou maar proberen om het te activeren dan. Lekker scheutig met info zijn ze wel.

Maar ik zou toch kijken of die tunnel eruit kan en native aan.

Edit: Ik zie dat je nogal aan die tunnel gehecht bent :
Raven in "[Tweak Glasvezel] Ervaringen & Discussie - Deel 5"

[ Voor 9% gewijzigd door valkenier op 02-08-2023 09:50 ]

[Raven]

valkenier schreef op woensdag 2 augustus 2023 @ 09:41:
Nou, ik zou maar proberen om het te activeren dan. Lekker scheutig met info zijn ze wel.

Ik merkte de niet aangekondigde poging van Tweak om IPv6 aan te zetten toen de routingtabel erdoor verkloot werd en mijn tunnel daardoor niet meer werkte

valkenier schreef op woensdag 2 augustus 2023 @ 09:41:
Edit: Ik zie dat je nogal aan die tunnel gehecht bent :
Raven in "[Tweak Glasvezel] Ervaringen & Discussie - Deel 5"

Heb geen zin om alles qua IPv6 om te gooien , daarbij zie ik die overgang (als Tweak IPv6 goed geïmplementeerd heeft) als een workaround, wil eerst weten wat hier nu aan de hand is voor het geval het weer gebeurt.

Over weer gesproken, Telegram is/was niet het enige probleemgeval, tijdens het Googlen kwam ik ook https://github.com/pypi/support/issues/2103 tegen, dat deed mij eraan herinneren dat ik met een Python-gerelateerde repository ook dit probleem heb gehad, maar dat probleem verdween uit het niets

[valkenier]

Een IPv6 tunnel is een workaround, native niet. Waarom is het lastig dat om te gooien?

[Raven]

valkenier schreef op donderdag 3 augustus 2023 @ 07:09:
Een IPv6 tunnel is een workaround, native niet.

Een essentiële workaround, daar ISP's maar achter blijven lopen....

valkenier schreef op donderdag 3 augustus 2023 @ 07:09:
Waarom is het lastig dat om te gooien?

Teveel configs aan moeten passen en firewall moeten herschrijven , maar nogmaals, wat als dit probleem ook dan weer optreed?

[Snow_King]

Raven schreef op donderdag 3 augustus 2023 @ 09:57:
[...]

Een essentiële workaround, daar ISP's maar achter blijven lopen....


[...]

Teveel configs aan moeten passen en firewall moeten herschrijven , maar nogmaals, wat als dit probleem ook dan weer optreed?

Native is toch echt fijner dan een tunnel ;-)

Heb je als eens een tracepath gedaan naar Telegram om te kijken welke MTU je richting hen hebt? En of je MTU path detection wel werkt?

[Raven]

Snow_King schreef op donderdag 3 augustus 2023 @ 09:58:
[...]

Native is toch echt fijner dan een tunnel ;-)

* Raven is de tunnel gewend

Snow_King schreef op donderdag 3 augustus 2023 @ 09:58:
Heb je als eens een tracepath gedaan naar Telegram om te kijken welke MTU je richting hen hebt? En of je MTU path detection wel werkt?

http://ipv6-test.com/pmtud/ -> Result: no PMTUD problems detected

Gezien Windows geen tracepath prog lijkt te hebben, Ubuntu:

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.017ms pmtu 1500
 1:  2001:470:*:1:*:*:*:1fad                   0.792ms 
 1:  2001:470:*:1:*:*:*:1fad                   2.308ms 
 2:  2001:470:*:1:*:*:*:1fad                   1.112ms pmtu 1480
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  2001:7f8:1::a506:2041:1                               5.605ms !A
     Resume: pmtu 1480 

Na aansluiten aan ander VLAN en /64 via wifi-adapter (bedraad uit):

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.022ms pmtu 1460
 1:  2001:470:*:*:*:*:*:cad4                  2.396ms 
 1:  2001:470:*:*:*:*:*:cad4                  2.013ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  2001:7f8:1::a506:2041:1                              83.988ms !A
     Resume: pmtu 1460 

Huh, de MTU is anders?

En ter vergelijking via het standaard VLAN

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443 
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

en na aansluiten wifi-adapter en disconnecten bedrade interface:

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.telegram.org
*  start date: Aug 10 15:56:28 2022 GMT
*  expire date: Sep 11 15:56:28 2023 GMT
*  subjectAltName: host "telegram.org" matched cert's "telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: telegram.org]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x558f835bf270)
> GET / HTTP/2
> Host: telegram.org
> user-agent: curl/7.88.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx/1.18.0
< date: Thu, 03 Aug 2023 09:56:31 GMT
< content-type: text/html; charset=utf-8
< content-length: 19649
< set-cookie: stel_ssid=57646d4ad4928319f8_5388082198254796336; expires=Thu, 03 Aug 2023 21:03:11 GMT; path=/; samesite=None; secure; HttpOnly
< pragma: no-cache
< cache-control: no-store
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
<!DOCTYPE html>
*shitload aan html*
</html>
<!-- page generated in 7.99ms -->
* Connection #0 to host telegram.org left intact

Beide testen zonder reboots tussendoor, de enige verandering is de netwerkinterface en daarmee de VLAN en /64.

[Snow_King]

Raven schreef op donderdag 3 augustus 2023 @ 12:25:
[...]

* Raven is de tunnel gewend


[...]

http://ipv6-test.com/pmtud/ -> Result: no PMTUD problems detected

Gezien Windows geen tracepath prog lijkt te hebben, Ubuntu:

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.017ms pmtu 1500
 1:  2001:470:*:1:*:*:*:1fad                   0.792ms 
 1:  2001:470:*:1:*:*:*:1fad                   2.308ms 
 2:  2001:470:*:1:*:*:*:1fad                   1.112ms pmtu 1480
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  2001:7f8:1::a506:2041:1                               5.605ms !A
     Resume: pmtu 1480 

Na aansluiten aan ander VLAN en /64 via wifi-adapter (bedraad uit):

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.022ms pmtu 1460
 1:  2001:470:*:*:*:*:*:cad4                  2.396ms 
 1:  2001:470:*:*:*:*:*:cad4                  2.013ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  2001:7f8:1::a506:2041:1                              83.988ms !A
     Resume: pmtu 1460 

Huh, de MTU is anders?

En ter vergelijking via het standaard VLAN

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443 
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

en na aansluiten wifi-adapter en disconnecten bedrade interface:

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.telegram.org
*  start date: Aug 10 15:56:28 2022 GMT
*  expire date: Sep 11 15:56:28 2023 GMT
*  subjectAltName: host "telegram.org" matched cert's "telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: telegram.org]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x558f835bf270)
> GET / HTTP/2
> Host: telegram.org
> user-agent: curl/7.88.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx/1.18.0
< date: Thu, 03 Aug 2023 09:56:31 GMT
< content-type: text/html; charset=utf-8
< content-length: 19649
< set-cookie: stel_ssid=57646d4ad4928319f8_5388082198254796336; expires=Thu, 03 Aug 2023 21:03:11 GMT; path=/; samesite=None; secure; HttpOnly
< pragma: no-cache
< cache-control: no-store
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
<!DOCTYPE html>
*shitload aan html*
</html>
<!-- page generated in 7.99ms -->
* Connection #0 to host telegram.org left intact

Beide testen zonder reboots tussendoor, de enige verandering is de netwerkinterface en daarmee de VLAN en /64.

Dat is wel echt heel vreemd. WiFi zou je MTU niet met 20 bytes naar beneden moeten brengen. Maar ook raar dat het daar dan wel weer wel werkt.

Ik twijfel of dit echt een IPv6 probleem is en of dit niet gewoon een 'IP' danwel 'TCP' probleem ergens is.

[Charlie_Root]

Raven schreef op donderdag 3 augustus 2023 @ 12:25:
[...]

* Raven is de tunnel gewend


[...]

http://ipv6-test.com/pmtud/ -> Result: no PMTUD problems detected

Gezien Windows geen tracepath prog lijkt te hebben, Ubuntu:

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.017ms pmtu 1500
 1:  2001:470:*:1:*:*:*:1fad                   0.792ms 
 1:  2001:470:*:1:*:*:*:1fad                   2.308ms 
 2:  2001:470:*:1:*:*:*:1fad                   1.112ms pmtu 1480
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  2001:7f8:1::a506:2041:1                               5.605ms !A
     Resume: pmtu 1480 

Na aansluiten aan ander VLAN en /64 via wifi-adapter (bedraad uit):

Bash:

tracepath -6 telegram.org
 1?: [LOCALHOST]                        0.022ms pmtu 1460
 1:  2001:470:*:*:*:*:*:cad4                  2.396ms 
 1:  2001:470:*:*:*:*:*:cad4                  2.013ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  2001:7f8:1::a506:2041:1                              83.988ms !A
     Resume: pmtu 1460 

Huh, de MTU is anders?

En ter vergelijking via het standaard VLAN

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to telegram.org:443 
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

en na aansluiten wifi-adapter en disconnecten bedrade interface:

Bash:

curl https://telegram.org -v
*   Trying [2001:67c:4e8:f004::9]:443...
* Connected to telegram.org (2001:67c:4e8:f004::9) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.telegram.org
*  start date: Aug 10 15:56:28 2022 GMT
*  expire date: Sep 11 15:56:28 2023 GMT
*  subjectAltName: host "telegram.org" matched cert's "telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: telegram.org]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x558f835bf270)
> GET / HTTP/2
> Host: telegram.org
> user-agent: curl/7.88.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx/1.18.0
< date: Thu, 03 Aug 2023 09:56:31 GMT
< content-type: text/html; charset=utf-8
< content-length: 19649
< set-cookie: stel_ssid=57646d4ad4928319f8_5388082198254796336; expires=Thu, 03 Aug 2023 21:03:11 GMT; path=/; samesite=None; secure; HttpOnly
< pragma: no-cache
< cache-control: no-store
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
<!DOCTYPE html>
*shitload aan html*
</html>
<!-- page generated in 7.99ms -->
* Connection #0 to host telegram.org left intact

Beide testen zonder reboots tussendoor, de enige verandering is de netwerkinterface en daarmee de VLAN en /64.

Wat voor router heb je en heb je hierop MSS Clamping ingesteld? Dat is nodig omdat het een tunnel interface is.

[Raven]

Snow_King schreef op donderdag 3 augustus 2023 @ 13:43:
[...]
Dat is wel echt heel vreemd. WiFi zou je MTU niet met 20 bytes naar beneden moeten brengen. Maar ook raar dat het daar dan wel weer wel werkt.

Bedoel je die daling van 1500 naar 1480 (de bedrade niet werkende situatie) of die wat start met 1460 (wat 20 lager is dan default MTU) en daar blijft?

De daling van 1500 naar 1480 lijkt op Ubuntu zelf te gebeuren, maar waarom Ubuntu in het geval van de wifi-adapter meteen met 1460 begint (wat een werkende situatie oplevert) snap ik dan even niet.

Heb de radvd-config ff gechecked, daar staat niets m.b.t. MTU, dus daar kan het niet vandaan komen.

Snow_King schreef op donderdag 3 augustus 2023 @ 13:43:
Ik twijfel of dit echt een IPv6 probleem is en of dit niet gewoon een 'IP' danwel 'TCP' probleem ergens is.

Heb met support van HE zitten mailen, het is vrijwel zeker iets aan mijn kant, maar wat is nog niet duidelijk. Gezien het bij https misgaat (en http wel gewoon connect met cURL), lijkt het richting MTU te gaan.

Maar waar waarom alleen deze domeinnaam en waarom alleen deze /64 weten ze daar niet, ik heb nooit iets qua MTU ingesteld, bij radvd en ook bij het opzetten van de tunnel niet:

Bash:

nmcli connection add type ip-tunnel con-name he-ipv6 ifname he-ipv6 mode sit remote $IPv4Endpoint -- ipv4.method disabled ipv6.method manual ipv6.address $IPv6Address ipv6.gateway $IPv6Gateway

Bij de tunneleigenschappen op tunnelbroker.net staat de MTU op default (1480).

Charlie_Root schreef op donderdag 3 augustus 2023 @ 14:11:
[...]

Wat voor router heb je en heb je hierop MSS Clamping ingesteld? Dat is nodig omdat het een tunnel interface is.

Een pc met Debian en MSS Clamping heb ik nooit iets mee gedaan, mijn problemen met IPv6 waren in de loop der jaren beperkt tot ICMPv6 blocks aan de serverkant en incorrecte Geo-IP databases (nog steeds het geval, weet alleen niet welke) .... en dan nu dit dus.

[Charlie_Root]

Raven schreef op donderdag 3 augustus 2023 @ 17:56:
[...]
Bedoel je die daling van 1500 naar 1480 (de bedrade niet werkende situatie) of die wat start met 1460 (wat 20 lager is dan default MTU) en daar blijft?

De daling van 1500 naar 1480 lijkt op Ubuntu zelf te gebeuren, maar waarom Ubuntu in het geval van de wifi-adapter meteen met 1460 begint (wat een werkende situatie oplevert) snap ik dan even niet.

Heb de radvd-config ff gechecked, daar staat niets m.b.t. MTU, dus daar kan het niet vandaan komen.


[...]

Heb met support van HE zitten mailen, het is vrijwel zeker iets aan mijn kant, maar wat is nog niet duidelijk. Gezien het bij https misgaat (en http wel gewoon connect met cURL), lijkt het richting MTU te gaan.

Maar waar waarom alleen deze domeinnaam en waarom alleen deze /64 weten ze daar niet, ik heb nooit iets qua MTU ingesteld, bij radvd en ook bij het opzetten van de tunnel niet:

Bash:

nmcli connection add type ip-tunnel con-name he-ipv6 ifname he-ipv6 mode sit remote $IPv4Endpoint -- ipv4.method disabled ipv6.method manual ipv6.address $IPv6Address ipv6.gateway $IPv6Gateway

Bij de tunneleigenschappen op tunnelbroker.net staat de MTU op default (1480).


[...]

Een pc met Debian en MSS Clamping heb ik nooit iets mee gedaan, mijn problemen met IPv6 waren in de loop der jaren beperkt tot ICMPv6 blocks aan de serverkant en incorrecte Geo-IP databases (nog steeds het geval, weet alleen niet welke) .... en dan nu dit dus.

Lijkt wel iets te maken daarmee, wat voor router heb je? Op mijn Edgerouter heb ik mss clamping staan op 1422 (ook he.net).

[Raven]

Charlie_Root schreef op donderdag 3 augustus 2023 @ 19:25:
wat voor router heb je?

Dat staat in de quote -> "Een pc met Debian"

[Charlie_Root]

Raven schreef op vrijdag 4 augustus 2023 @ 14:10:
[...]

Dat staat in de quote -> "Een pc met Debian"

My bad, overheen gelezen. Probeer je MTU op de tunnel eens te verlagen naar 1422?

Uit mijn hoofd;

code:

ip link set he-ipv6 mtu 1422

[ Voor 10% gewijzigd door Charlie_Root op 04-08-2023 17:35 ]

[Plofkotje]

Je kan in je route advertisements aan de v6 kant ook een max MTU opgeven die door vrijwel elk OS gerespecteerd wordt, in radvd is dat de AdvLinkMTU waarde. Als je die op de max MTU zet die door de tunnel naar HE gaat, 1480, kan dat evt ook helpen.

Het klinkt wel heel erg als een MTU dingetje, met iets aan de kant van Telegram wat path mtu discovery niet snapt.

[Raven]

Charlie_Root schreef op vrijdag 4 augustus 2023 @ 17:34:
[...]


My bad, overheen gelezen. Probeer je MTU op de tunnel eens te verlagen naar 1422?

Uit mijn hoofd;

code:

ip link set he-ipv6 mtu 1422

Plofkotje schreef op vrijdag 4 augustus 2023 @ 17:41:
Je kan in je route advertisements aan de v6 kant ook een max MTU opgeven die door vrijwel elk OS gerespecteerd wordt, in radvd is dat de AdvLinkMTU waarde. Als je die op de max MTU zet die door de tunnel naar HE gaat, 1480, kan dat evt ook helpen.

Het klinkt wel heel erg als een MTU dingetje, met iets aan de kant van Telegram wat path mtu discovery niet snapt.

Ff radvd config van het problematische VLAN aanpassen.

.....

Euh, what the F, in het wifi-subnet deel van radvd.conf (die wat wel kan connecten met Telegram.org) staat AdvLinkMTU 1460, waar komt dat nou vandaan Ik heb een kopie van de radvd-conf die ik ooit heb aangemaakt en daar staat die niet in. Dan zou ik dat achteraf moeten hebben toegevoegd, maar buiten dat ik dat mij niet kan herinneren, ik kan geen enkele txt-file vinden waar ik daar een notitie over heb ingezet (doe ik normaal wel).

Regel gecopypasted naar de default VLAN, Telegram werkt, ook in Home Assistant.

[ Voor 3% gewijzigd door Raven op 04-08-2023 18:20 ]

[valkenier]

Mooi dat je het issue hebt getackeld, maar met native IPv6 had je dit niet nodig gehad……

[Raven]

valkenier schreef op maandag 7 augustus 2023 @ 14:09:
Mooi dat je het issue hebt getackeld, maar met native IPv6 had je dit niet nodig gehad……

Mwah, getackeld, het is in ieder geval duidelijk dat het MTU-gerelateerd is, maar waarom specifiek telegram.org is nog niet duidelijk. Valt er op afstand te zien of een willekeurige webserver geen issues heeft m.b.t. MTU?

[Plofkotje]

Raven schreef op maandag 7 augustus 2023 @ 14:43:
[...]

Mwah, getackeld, het is in ieder geval duidelijk dat het MTU-gerelateerd is, maar waarom specifiek telegram.org is nog niet duidelijk. Valt er op afstand te zien of een willekeurige webserver geen issues heeft m.b.t. MTU?

Met iets van Tracepath zou je dit moeten kunnen zien, maar dat had je al gedaan Het debuggen van path mtu discovery issues op een host die je niet zelf in beheer hebt is lastiger, anders dan verschillende waardes proberen en kijken welke werkt.

Het lijkt er heel erg op dat er gewoon iets in het pad zit bij Telegram richting sommige diensten die er vanuit gaat dat alles op 1500 ingesteld staat en geen rekening houdt met mogelijke tunnels, mogelijk ivm iets van ECMP routing aan hun kant voor loadbalancing. Cloudflare heeft hier een mooi artikel over geschreven lang geleden over de MTU issues waar ze tegenaan liepen nadat ze ECMP geimpementeerd hadden: https://blog.cloudflare.com/increasing-ipv6-mtu/

[Raven]

Plofkotje schreef op maandag 7 augustus 2023 @ 14:57:
[...]


Met iets van Tracepath zou je dit moeten kunnen zien, maar dat had je al gedaan Het debuggen van path mtu discovery issues op een host die je niet zelf in beheer hebt is lastiger, anders dan verschillende waardes proberen en kijken welke werkt.

Jup, daar kwam ik dus de 1460 tegen waarvan ik nog steeds niet weet waarom ik die bij 1 specifiek subnet in de radvd config had gezet Heb uiteindelijk zelfs hier op het forum zitten zoeken in mijn posthistorie, kijken of daar iets was terug te vinden waarom ik dat had gedaan

Plofkotje schreef op maandag 7 augustus 2023 @ 14:57:
Het lijkt er heel erg op dat er gewoon iets in het pad zit bij Telegram richting sommige diensten die er vanuit gaat dat alles op 1500 ingesteld staat en geen rekening houdt met mogelijke tunnels, mogelijk ivm iets van ECMP routing aan hun kant voor loadbalancing.

Hmm...

Plofkotje schreef op maandag 7 augustus 2023 @ 14:57:
Cloudflare heeft hier een mooi artikel over geschreven lang geleden over de MTU issues waar ze tegenaan liepen nadat ze ECMP geimpementeerd hadden: https://blog.cloudflare.com/increasing-ipv6-mtu/

* Raven doet bij bookmarks zetten
Dank voor de tip

[Snow_King]

Interessant IPv6 presentatie van RIPE: "IPv6 Security Myths"


PDF: https://www.ripe.net/supp...v6security-2hrs-part3.pdf

[Dutch-gabber]

Hallo,

Ik heb sinds kort een UDM pro icm een KPN(voorheen XS4all) abbonement, en zou graag via de interface IPv6 configureren.

Nu heb ik dit eerst via DHCPv6 geprobeerd, maar dit zou volgens een post op het KPN forum niet werken.
In plaats daarvan geprobeerd via een static ip (opgehaald uit MijnKPN), maar nu moet ik een Gateway IP opgeven.

Zou iemand mij kunnen helpen met dit werkend te krijgen?
Bvd.

[stormfly]

Dutch-gabber schreef op zaterdag 12 augustus 2023 @ 14:22:
Hallo,

Ik heb sinds kort een UDM pro icm een KPN(voorheen XS4all) abbonement, en zou graag via de interface IPv6 configureren.

Nu heb ik dit eerst via DHCPv6 geprobeerd, maar dit zou volgens een post op het KPN forum niet werken.
In plaats daarvan geprobeerd via een static ip (opgehaald uit MijnKPN), maar nu moet ik een Gateway IP opgeven.

Zou iemand mij kunnen helpen met dit werkend te krijgen?
Bvd.

[Afbeelding]

Dan moet je het FE80 adres van de overzijde opzoeken. Staat dat niet in de post die je op het KPN forum hebt gevonden?

Als je DHCPv6 aanzet. Kan je dan vanaf je UI router pingen naar ipv6.google.com?

[Dutch-gabber]

stormfly schreef op zaterdag 12 augustus 2023 @ 14:35:
[...]


Dan moet je het FE80 adres van de overzijde opzoeken. Staat dat niet in de post die je op het KPN forum hebt gevonden?

Hier kon ik dus helaas niks over vinden in de forumpost
helaas weet ik de terminologie niet om tot een goede google search te komen.

Als je DHCPv6 aanzet. Kan je dan vanaf je UI router pingen naar ipv6.google.com?

Deze mislukt

code:

ping ipv6.google.com
PING ipv6.google.com(ams15s48-in-x0e.1e100.net (2a00:1450:400e:811::200e)) 56 da                                          ta bytes
^C
--- ipv6.google.com ping statistics ---
71 packets transmitted, 0 received, 100% packet loss, time 72810ms

[stormfly]

Dutch-gabber schreef op zaterdag 12 augustus 2023 @ 15:25:
[...]


Hier kon ik dus helaas niks over vinden in de forumpost
helaas weet ik de terminologie niet om tot een goede google search te komen.


[...]


Deze mislukt

code:

ping ipv6.google.com
PING ipv6.google.com(ams15s48-in-x0e.1e100.net (2a00:1450:400e:811::200e)) 56 da                                          ta bytes
^C
--- ipv6.google.com ping statistics ---
71 packets transmitted, 0 received, 100% packet loss, time 72810ms

Aha in die post gaan ze er vanuit dat er nog een ExperiaBox voor zit, is dat bij jou ook het geval?

[Dutch-gabber]

stormfly schreef op zaterdag 12 augustus 2023 @ 16:09:
[...]


Aha in die post gaan ze er vanuit dat er nog een ExperiaBox voor zit, is dat bij jou ook het geval?

Nee, ik heb hem direct achter de NTU hangen.

[stormfly]

Dutch-gabber schreef op zaterdag 12 augustus 2023 @ 16:29:
[...]


Nee, ik heb hem direct achter de NTU hangen.

Dan gaat het niet werken met die gateway en statisch adresseren. Ik heb de UXG pro ook ooit direct op de KPN aansluiting gezet, en toen kreeg ik geen IPv6. Heb de moeite niet genomen om een heel bugreport te schrijven op hun community. Mijn primaire router is pfSense die handelt het IPv6 verkeer af, daarachter een UXG pro die nat achter nat staa voor IPv4. En statisch gerouteerd voor IPv6.

Owh wacht het nat achter nat (is slecht) fabeltje dat verdampt, want steeds meer verkeer is IPv6 en dat is fully routed. Zie hier een illustratie van de verhoudingen, links in beeld.

[Charlie_Root]

Dutch-gabber schreef op zaterdag 12 augustus 2023 @ 15:25:
[...]


Hier kon ik dus helaas niks over vinden in de forumpost
helaas weet ik de terminologie niet om tot een goede google search te komen.


[...]


Deze mislukt

code:

ping ipv6.google.com
PING ipv6.google.com(ams15s48-in-x0e.1e100.net (2a00:1450:400e:811::200e)) 56 da                                          ta bytes
^C
--- ipv6.google.com ping statistics ---
71 packets transmitted, 0 received, 100% packet loss, time 72810ms

Volgens mij moet het gewoon werken;
- WAN zijde ipv6 connection op DHCPv6
- Prefix Delegation Size op /48
- Lan zijde IPv6 Interface Type op PD
- IPv6 RA aanzetten met prio High
- DHCPv6 DNS adressen opgeven (google bijv)
- Vaste DHCPv6 range opgeven
- Firewall regel aanmaken die inbound/outbound ICMPv6 (RA) geheel toestaat.

[Raven]

Wat een incompetente *pieeeeeeeep* bij Videoland.

Ik heb nu meerdere keren melding gedaan van een verbindingsprobleem (geo-IP gedoe) en ze willen mijn IPv4 adres hebben terwijl ik meerdere keren heb aangegeven dat het probleem IPv6 specifiek is

Zijn er anno 2023 nog steeds geen manieren om als bezoeker van een streamingdienst te achterhalen welke geo-IP database daar gebruikt wordt? Ik kan er nog steeds geen vinden die iets anders dan Nederland aangeeft en Videoland weigert dit probleem te snappen.

[stormfly]

Raven schreef op zondag 10 september 2023 @ 12:10:
Wat een incompetente *pieeeeeeeep* bij Videoland.

Ik heb nu meerdere keren melding gedaan van een verbindingsprobleem (geo-IP gedoe) en ze willen mijn IPv4 adres hebben terwijl ik meerdere keren heb aangegeven dat het probleem IPv6 specifiek is

Zijn er anno 2023 nog steeds geen manieren om als bezoeker van een streamingdienst te achterhalen welke geo-IP database daar gebruikt wordt? Ik kan er nog steeds geen vinden die iets anders dan Nederland aangeeft en Videoland weigert dit probleem te snappen.

Aai dat is wel vervelend. Welke provider?

https://www.maxmind.com/en/geoip-demo Dit is volgens mij een veel gebruikte?

[Raven]

stormfly schreef op zondag 10 september 2023 @ 13:01:
[...]


Aai dat is wel vervelend. Welke provider?

Hurricane Electric, oftewel IPv6-tunnel.

stormfly schreef op zondag 10 september 2023 @ 13:01:
https://www.maxmind.com/en/geoip-demo Dit is volgens mij een veel gebruikte?

Netherlands, Europe, dit is een van de vele die Google vond en die had ik al eerder getest, geeft nog steeds NL aan.

Ik probeer de klantenservice al een tijdje zover te krijgen de naam van de door Videoland gebruikte te geven, zodat ik er zelf achteraan kan, alleen kennen ze daar het bestaan van IPv6 en geo-IP databases niet

[stormfly]

Raven schreef op zondag 10 september 2023 @ 13:06:
[...]

Hurricane Electric, oftewel IPv6-tunnel.


[...]

Netherlands, Europe, dit is een van de vele die Google vond en die had ik al eerder getest, geeft nog steeds NL aan.

Ik probeer de klantenservice al een tijdje zover te krijgen de naam van de door Videoland gebruikte te geven, zodat ik er zelf achteraan kan, alleen kennen ze daar het bestaan van IPv6 en geo-IP databases niet

Aai ja met tunnels is mijn ervaring dat nog wat lastiger is. RipeDB is ook een veelgebruikte bron voor IP segmenten.