Ik heb behalve mijn eigen aansluitingen (1 x Freedom 1 x KPN4all) ook het remote beheer van een 4tal andere aansluitingen alle 6 dmv een VPN-verbinding tussen 2 Fritzboxen.
In totaal 9 VPN-verbindingen: 1 tussen mijn beide eigen aansluitingen (glas-glas)
4 vanuit mijn KPNall Fritzbox naar elk van de 4 remote Fritzboxen en (2 x glas-glas, 1 x glas-VDSL, 1 x glas-LTE)
4 vanuit mijn Freedom Fritzbox naar elk van de 4 remote Fritzboxen. (2 x glas-glas, 1 x glas-VDSL, 1 x glas-LTE)
Helaas lukt het mij niet om 2 van de 9 verbindingen actief te krijgen, nl.
de verbinding tussen Freedom en T-mobile VDSL (glas-VDSL) en de verbinding tussen Freedom en mobiel internet (glas-LTE)
Waarom lukt dat niet met Freedom en wel met KPN4all, terwijl de andere verbindingen zowel met Freedom als met KPN4all prima werken.
De wel werkende verbindingen hebben alle aan weerszijden een vast IP-adres.
T-mobile en LTE hebben wisselende IP-adressen, (T-mobile in de praktijk alleen na een stroomstoring, de LTE verbinding telkens als je door een andere mast wordt aangestraald).
T-mobile en LTE ondersteunen alleen IPv4. Alle andere hebben zowel IPv4 als IPv6. Ik heb zowel voor mijn Freedom als mijn KPN4all aansluiting zowel een subdomein met een eigen A-record (IPv4) en een AAAA-record (IPv6). Kan dat de oorzaak zijn? Zo ja, waarom is dat bij KPN4all geen probleem en bij Freedom wel? Voor de T-mobile en LTE aansluitingen gebruik ik de MyFritz account. Waarom werkt dit wel bij KPN4all en niet bij Freedom?
Wat maakt de Freedom-aansluiting anders dan de KPN4all aansluiting. Ik kan de Freedom aansluiting ook niet pingen van buitenaf. Wie o wie kan mij uitleggen wat ik over het hoofd heb gezien?
Zijn er - welke - indicaties/symptomen wat er meer specifiek niet zou werken ?
Met de auto v/d buren is stuk is het lastig iets te zeggen.
Ik neem aan dat jijzelf de VPN initieert en de versies van betrokken FB’s elkaar niet in de weg zitten. Ik zou ook alles op IPv4 te forceren. Werkt dat, kan je verder kijken. Kan soms helpen van scratch te beginnen.
Kan mij niet goed voorstellen dat hier het merk/delivery/belichter van invloed is. Zo je dat weet/kunt, probeer een packetrace te volgen (te initieren op de FB: http://fritz.box/support.lua → http://fritz.box/capture.lua en zo mogelijk dit in combi bij/met de andere partij. Wellicht zie je ergens een afwijkende error/wait die op iets kan duiden.
Complotgedachte is dat de geadreseerde (netwerk)partij je simpelweg blokkeert, iets dat dan vanuit de packettrace weer zichtbaar kan worden.
Grote kans dat de T-mobile adressen gebruik maken van Carrier Grade NAT … dat is niet een betere soort NAT oid, maar 2 maal NAT achter elkaar. een maal op de Carrier Gateway tussen het interne ISP net en internet en eenmaal tussen jouw LAN en het internet ISP net.
Je zul dan zien dat het adres wat jij als publiek adres ziet verschillend is met wat je als antwoord terug krijgt op een STUN request.
(adres reeks kan ook een give away zijn)
RFC 6598 noemt deze reeks: 100.64.0.0/10
Het maken van een verbinding van BUITEN CGNAT naar een adres binnen CGNAT is niet mogelijk omdat Port Forwarding daar niet bestaat.
De omgekeerde kant kan wel, dus je zou de tunnel vanuit een mobiel systeem naar een vast systeem kunnen maken.
En vergelijkbaar probleem is er met VOIP, het is niet mogelijk om zonder meer van buiten verbinding te maken met een VOIP systeem binnen een CGNAT omgeving…, maar de ISP’s zijn ook vaak telefoon boeren, dus dat is niet hun probleem, ze leveren toch ook VOIP …?
Check eens of je bij T-Mobile last hebt van CGNAT (de kans hierop is groot), de oplossing is dan om vanuit die verbinding naar je freedom de tunnel op te bouwen.
Ik gebruik zelf een tunnel die vanaf mijn mobiel naar een vast punt wordt opgebouwd en ook VOIP kan uitstekend over die tunnel ook de VOIP van die provider zelf … (ivm. dekkings problemen met LTE rond mijn woning wordt op mobieltjes binnenshuis vaak VOIP ipv VoLTE gebruikt, en die gaat ook over die tunnel)
Beste NOCI, een prachtig verhaal maar ik kan het niet helemaal begrijpen.
VPN tussen Fritzbox aan T-mobile VDSL en KPN4all glas werkt wel.
VPN tussen dezelfde Fritzbox aan dezelfde T-mobile VDSL en Freedom glas werkt niet.
Idem voor mobiele LTE Fritzbox
Daarentegen:
VPN tussen Fritzbox aan KPN4-all en KPN4all werkt wel
VPN tussen dezelfde Fritzbox aan dezelfde KPN4-all en Freedom glas werkt ook wel.
Als er sprake is van carriergrade NAT, waarom heeft dan de Freedom aansluiting daar last van en de KPN4all aansluiting niet?
Ik denk niet dat een STUN request is wanneer er geen VOIP gebruikt wordt.
Alle 6 Fritzboxen in mijn verhaal draaien op FritzOS 7.29
Lijkt mij dan kandidaat om die specifiek combinatie(s) te gaan onderzoeken op hun merites met een packettrace of support analyse.
Ten overvloede, dezelfde versie wil niet zeggen dan dus ook dezelfde (resulterende) software.
Praktische oplossing - zakelijk gezien - is ms zaken te vervangen door wat wel werkt.
Dit soort uitzoekzaken blijft een hoooibergspeld, ook omdat het onmogelijk is toegang te hebben tot de interne werking van gebruikte hard/software.
Aiii… die vraag stellen kan een indicatie zijn dat je mogelijk niet goed weet met hoe of wat (verder) daarmee aan te vangen.
Niettemin, je gaat naar support pagina van de Fritz… http://fritz.box/support.lua en dan → naar packet-trace (onderin) gaat om uit te komen op een pagina waar je een packet trace kan straten voor (verschillende) interfaces:
Na het starten maakt de FB een packettrace-bestand aan dat je kunt bewaren, na gestopt te zijn dan met bv WireShark-tools kunt uitlezen en inspecteren.
Het interpreteren van de zooi* vraagt wat woelwater/kennis maar mogelijk zie je dan ergens in de berg van data iets dat afwijkt.
NB: probeer, indien mogelijk al het andere verkeer dat niets te maken heeft met VPN, stil te leggen cq af te schakelen. Desnoods door LAN kabel (natuurlijk niet met die waarmee je het data/bestand verzameld) los te nemen. Op een drukke omgeving komt er een flinke berg data dat je moet doorakkeren.
Ik weet niet welke interfaces allemaal bij de FB-VPN zijn betrokken maar ik zou beginnen aan de uiteinde daarvan dwz bij 1. Internet Connectie.
Om wat te vergelijken en gevoel te krijgen, hoe het hoort te zijn, kan je ook een trace doen waar VPN wel lukt. In die packet-seriea zul je dan al snel een patroon ontdekken van o.a. de IP/adressen zien die betrokken zijn in de VPN-opbouw. Dat “schema” projecteer je vervolgens op waar de VPN mislukt.
Mogelijk krijg je dan een indicatie. Kan ook zijn dat de FB, anders dan de 7590, simpelweg een “bug” bevat en dan tegen conflicten aanloopt die vervat zijn in de (netwerk)configuratie.
Bijv. een eigen VPN opstarten naar andermans VPN waar beiden hetzelfde (VPN) IP-segment lokaal-LAN gebruiken. Het vice-versa routeren van VPN packets lukt dan niet meer omdat de packets niet kunnen worden gerouteerd over/naar de VPN interface.
Ik weet niet of dfit bij Fritz zo is maar ik ken situaties uit een verleden waar een routerfabrikant specifieke “VPN” of “IPSEC” functie in consumenten modellen blokkeerden omdat ze dat zagen als professioneel gebruik.
CGNAT is een one way street…, je kan wel naar buiten (naar internet) maar niet de andere kant op.
Dus het is van belang welk systeem met de tunnel begint. Bij een aansluiting achter een CGNAT moet die de tunnel starten.
Als dat bij toeval gebeurt zal er een tunnel ontstaan, als er vanuit de andere kant (bv. een sneller systeem) de tunnel gestart wordt kan het zijn dat altijd de verkeerde kant de tunnel begint. Daarnaast kan het zijn dat de CGNAT installatie ook nog filters bevat… (niet alle ISP’s laten alle verkeer door).
Om hardware uit te sluiten zou je de routers van KPN4ALL & Freedom evt. kunnen verwisselen.
Wanneer je de boel op Fritz (op)start, zal FB je vragen waar het trace bestand kan worden opgeslagen en geplaatst.
In tegenstelling tot wat iemand zou kunnen denken, is de trace op/van FB geen live/realtime maar komt pas beschikbaar nadat de trace op de FB wordt gestopt.
) en freedom aansluiting, beide vdsl. Ik schat in dat er ergens een mismatch zit in een instelling, ik zou huidige instellingen documenteren (beide kanten) en dan alles opnieuw instellen (beide kanten) dat heb ik ook gedaan toen mijn ene aansluiting overging van xs4all naar freedom en ik alle instellingen had aangepast maar de vpn maar vanaf één kant kon worden opgebouwd. Ik heb in de instellingen uiteindelijk geen verschillen kunnen vinden, maar na het opnieuw instellen (best een … klusje) werkte het weer als vanouds.
… (ivm. dekkings problemen met LTE rond mijn woning wordt op mobieltjes binnenshuis vaak VOIP ipv VoLTE gebruikt, en die gaat ook over die tunnel)