Publiek IP-adres via 4G extern te benaderen, via wifi niet

[Jorn23]

Mijn vraag
Ik heb een Teltonika RUTx11 LTE router met een SIM-kaart geconfigureerd. Dit werkt allemaal prima en stabiel. Verder een DDNS profiel aangemaakt. Dit werkt ook. Domein is via 4G op afstand te benaderen, ook portforwarding werkt via 4G (dus als ik op een andere plek via mijn mobiele 4G op mijn smartphone de domeinnaam bezoek dan werkt dit). Dit werkt zowel middels de domeinnaam als direct via IP-adres.

Schakel ik echter over op een wifi-verbinding op een extern adres dan werken beide manieren ineens niet meer. Zowel via de domeinnaam als via het IP-adres. Dit duidt er voor mij op dat het niet aan de DDNS configuratie ligt, maar eerder iets anders. Anders had ik hem wel gewoon via direct IP-adres kunnen benaderen.

Wie o wie heeft de (mogelijke) oplossing?

Relevante software en hardware die ik gebruik
Teltonika RUTx11

[Kaalus]

Even een trace route naar je IP draaien en kijken waar het verkeer vastloopt?
Waarschijnlijk wordt het ergens geblokkeerd en zolang je niet weet waar blijft het gissen.

[bregweb]

Kun je iets meer vertellen wat je bedoeld met wifi op een extern adres.

Via 4G zit je bijvoorbeeld op KPN en heb je te maken met KPN regels. Als je verbindt met mijn WIFI netwerk, heb je te maken met mijn regels en die verbieden misschien dat je naar jouw domein mag.

[Ben(V)]

Zit er geen firewall op de locatie waar je op wifi overgaat die (bepaald) uitgaand verkeer blokkeert?

[PhilipsFan]

Je 4G zit vermoedelijk achter carrier grade NAT. Daar is niks aan te doen, die IP's zijn niet van buitenaf te benaderen. Dat het eerder toch lukte via 4G zal te maken hebben met de provider. Klopt het dat je 4G die je wilt bereiken bij dezelfde provider zit als de 4G verbinding waar vanaf je dat probeerde? Dan kan het zijn dat die IP-adressen binnen de carrier wel openbaar zijn. Maar van buitenaf dus niet.

Ik denk dat je met je 4G provider om de tafel moet om een 'echt' extern IP-adres te krijgen. Dat is vast wel mogelijk, maar er zullen kosten aan verbonden zijn, ik heb het nog nooit geprobeerd.

[Lrrr]

Valt het IP in de range 100.64.0.0 t/m 100.127.255.255? Dan is het zoals @PhilipsFan zei gegarandeerd carrier-grade NAT (CGNAT).

Als het niet binnen die adresrange valt kan het trouwens alsnog CGNAT zijn, maar dan is de ISP wel raar bezig.

[jvanhambelgium]

"Schakel ik echter over op een wifi-verbinding op een extern adres dan werken beide manieren ineens niet meer. Zowel via de domeinnaam als via het IP-adres"

Zal denkelijk te maken hebben met de beperkingen op die Wifi-locatie. Heb je getest op een publieke Wifi-hotspot ? Bij de buren ? Overal hetzelfde fenomeen op "Wifi"

[powerboat]

Jorn23 schreef op woensdag 7 juli 2021 @ 07:38:
Mijn vraag
Ik heb een Teltonika RUTx11 LTE router met een SIM-kaart geconfigureerd. Dit werkt allemaal prima en stabiel. Verder een DDNS profiel aangemaakt. Dit werkt ook. Domein is via 4G op afstand te benaderen, ook portforwarding werkt via 4G (dus als ik op een andere plek via mijn mobiele 4G op mijn smartphone de domeinnaam bezoek dan werkt dit). Dit werkt zowel middels de domeinnaam als direct via IP-adres.

Schakel ik echter over op een wifi-verbinding op een extern adres dan werken beide manieren ineens niet meer. Zowel via de domeinnaam als via het IP-adres. Dit duidt er voor mij op dat het niet aan de DDNS configuratie ligt, maar eerder iets anders. Anders had ik hem wel gewoon via direct IP-adres kunnen benaderen.

Wie o wie heeft de (mogelijke) oplossing?

Relevante software en hardware die ik gebruik
Teltonika RUTx11

Schakelt je teltonika over op wlan of je smartphone/laptop?

[Jorn23]

Ben er inmiddels achter, het was ongeveer wat PhilipsFan suggereerde.

Het heeft niet te maken met het publieke IP, maar inderdaad wel met CGNAT en het feit dat zei veel poorten blokkeren waardoor je die niet kunt openzetten.

Ik heb hier inmiddels een oplossing voor.

Het klopt inderdaad dat ik de poort wel met 4G kon benaderen op afstand doordat dit hetzelfde mobiele 4G netwerk betrof, dezelfde provider. Je opereert dan een soort van binnen één netwerk, al is de publieke IP-reeks anders.

Buiten het netwerk van de provider ging het voor moeilijkheden zorgen...

Bedankt voor de reacties!

[Jorn23]

Toch nog een vraagje voor mijn beeldvorming:

Hoe kan ik een CGNAT voor me zien wanneer port forwarding wél mogelijk zou zijn vanuit je ISP (dus dat poorten toegankelijk zijn nadat je ze zelf openzet in je eigen router)?

Zet de provider dan een soort UPnP functie aan op hun systeem waardoor port forwarding regels bijvoorbeeld automatisch gecreëerd worden op aanvraag?

[To_Tall]

Je hebt te maken met een apn die verbindingen zijn private. Je kan niet zomaar diensten draaien op een apn. Dan zou je bij de provider een andere apn moeten aanvragen die zijn kostbaar.

[jvanhambelgium]

Het "NAT" stuk zal gedaan worden op een CGNAT "gateway" (firewall/router) en zaken als UPnP zijn hier niet van toepassing. (UPnP moet je echt vergeten, is iets voor thuisnetwerken dat al lang gekilled had moeten zijn door inherente onveiligheid)

Zoals aangegeven kan je dus echt als eindklant geen services "hosten" achter CGNAT, dan moet je echt naar een andere oplossing (business) gaan met ander kostplaatje.

[Jorn23]

Ik bedoelde meer van 'hoe werkt dat in de hardware van telefonie provider' gewoon om een beetje een beeld ervan te krijgen.

Maar het lijkt niet helemaal waar wat je zegt, want op de ene APN zijn de meeste poorten dicht, maar wel enkele open.
En op een andere APN staan alle poorten gewoon open.

Dus zo te zien heeft een provider wel degelijk invloed op wat zij openzetten en hoe dit te routeren/NAT'ten, etc.

[jvanhambelgium]

Jorn23 schreef op zondag 18 juli 2021 @ 11:24:
Maar het lijkt niet helemaal waar wat je zegt, want op de ene APN zijn de meeste poorten dicht, maar wel enkele open.
En op een andere APN staan alle poorten gewoon open.
Dus zo te zien heeft een provider wel degelijk invloed op wat zij openzetten en hoe dit te routeren/NAT'ten, etc.

De operator heeft volledige controle over de settings binnen een APN, dus ik ga er inderdaad van uit dat zaken als routings,CGNAT,firewalling mee in het model verwerkt zitten van de APN die ze aanbieden voor dienst X

Echter als "leidraad" kan je gewoon stellen, als je merkt dat er NAT/CGNAT in het spel is vergeet dan maar om services te hosten.

Eventueel niet iets met IPv6 te doen ? Je moet maar eens in de APN-settings kijken of IPv6 er mee in staat en of je een IPv6 krijgt ook.
Als je echt gaat roamen is het hier (proximus Belgie) enkel IPv4, maar lokaal IPv6 + IPv4

[Jorn23]

Exat.

Maar als een poort openstaat kun je toch gewoon een service hosten? Althans, dat werkt namelijk nu.

Wat is het voordeel van IPv6 in dit voorbeeld? En hoe zie je of je een IPv6 hebt of niet?

[jvanhambelgium]

Jorn23 schreef op zondag 18 juli 2021 @ 11:57:
Exat.

Maar als een poort openstaat kun je toch gewoon een service hosten? Althans, dat werkt namelijk nu.

Wat is het voordeel van IPv6 in dit voorbeeld? En hoe zie je of je een IPv6 hebt of niet?

Als je een IPv6 krijgt is de kans (groot) dat er geen CGNAT/NAT gebruikt is omdat de beschikbare IP-space zooooooooooooo groot is dat er nooit een tekort zal zijn.
Er is een reden dat je bij IPv4 met CGNAT te maken krijgt, operatoren hebben niet altijd genoeg IP-space om enkele miljoenen mobieltjes allemaal te voorzien van een eigen publiek IP.
Vb 5-10 jaar geleden was dat heel anders.

Ik heb geen hard bewijs dat CGNAT niet bij IPv6 gebruikt is, maar als ik effe een lookup doe van het IPv6 dat ik gekregen heb zit het netjes in een pool van "dynamic WAN IP's" bij RIPE.
Mogelijks is er natuurlijk nog inbound "filtering" zodat je geen services kan draaien.

Gewoon kijken bij je "status" op je phone, daar zie je het IPv4 en/of IPv6 dat je hebt gekregen van de operator. Als het hier een SIM-betreft op een router bestaan er denkelijk wel commando's voor, ALS IPv6 natuurlijk ondersteund is op zo'n mobiel routertje.