Dubbele NAT door Telenet zelf ?

[680x0]

Mogelijk is dit al langer zo maar het viel me daarnet pas op. Sinds wanneer zit je bij gewoon Telenet gebruik sowieso achter een dubbele NAT ?

Code: Selecteer alles

Tracing route to belnet.be [193.190.130.15]
over a maximum of 30 hops:

  1     2 ms     4 ms     3 ms  192.168.0.1
  2    13 ms    12 ms    14 ms  10.69.128.1
  3    14 ms    20 ms    20 ms  dD5E0CF19.access.telenet.be [213.224.207.25]
  4    17 ms    16 ms    16 ms  dD5E0FA66.access.telenet.be [213.224.250.102]
  5    19 ms    19 ms    20 ms  10ge.cr2.brueve.belnet.net [194.53.172.65]
  6    17 ms    17 ms    16 ms  10ge.r2.interconnect.belnet.net [193.191.17.26]
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9    19 ms    18 ms    17 ms  belnet-ict.ar1.brulou.belnet.net [193.191.2.146]
 10    21 ms    20 ms    18 ms  fiorano.belnet.be [193.190.130.15]

Ikzelf heb geen eigen router meer. Deze is een tijd geleden defect geraakt en tot hiertoe werk ik dan gewoon 'plain' achter de modem. Er zit dus niets van mezelf (meer) tussen en toch gaat mijn data na de modem eerst nog door een ander 10.* local network om dan na nog 2 stappen ergens 'buiten' gerouteerd te raken.

Iemand enig idee wat de reden hiervoor is of wat men daar mee van plan is ? Extra controle ? DPI ? Andere vorm van packet controle ?

[nickz]

Ik krijg dit als resultaat (eveneens zonder eigen router):

Code: Selecteer alles

Tracing route to belnet.be [2001:6a8:3c80:8300::15]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  2a02:1812:1532:a600:de53:7cff:fe85:d4e8
  2    10 ms    10 ms    10 ms  ptr-2hj4tenxl8x1dc96s5p0otmo1.ip6.access.telenet.be [2a02:181f:0:80a9::1]
  3     9 ms     8 ms     8 ms  2a02:1800:2:3088::2
  4    11 ms    14 ms    11 ms  2a02:1800:0:1:209:2102:0:3
  5    13 ms    14 ms    14 ms  belnet.bnix.net [2001:7f8:26::a500:2611:1]
  6    16 ms    15 ms    13 ms  10ge.cr1.brueve.belnet.net [2001:6a8:0:a001::1] 
  7    15 ms    17 ms    14 ms  r1.interconnect.brueve.belnet.net [2001:6a8:a00:3::2]
  8    14 ms    13 ms    12 ms  2001:6a8:0:e101::1
  9    13 ms    11 ms    12 ms  2001:6a8::4:2:8:2
 10    14 ms     *       13 ms  2001:6a8::4:2:8:2
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

EDIT: naar userbase.be krijg ik wel die extra tussenstap

Code: Selecteer alles

Tracing route to userbase.be [79.132.231.171]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2    12 ms     9 ms     7 ms  10.87.0.1
  3     *        *        *     Request timed out.
  4     8 ms     9 ms     9 ms  dD5E0FA12.access.telenet.be [213.224.250.18]
  5    19 ms    14 ms    13 ms  dD5E0FA66.access.telenet.be [213.224.250.102]
  6    15 ms    15 ms    12 ms  edpnet.bnix.net [194.53.172.89]
  7    15 ms    17 ms    13 ms  router01.sn.be.edpnet.net [212.71.1.61]
  8    15 ms    16 ms    15 ms  79.132.231.171.static.edpnet.net [79.132.231.171]

Trace complete.

EDIT 2:

als je een trace naar buiten toe doet zal je dit zien:

1 - het ip van je router
2 - het ip van je telenet-kabelmodem (het interne ip waarmee telenet
updates naar de modem kan sturen en de modem resetten)
3 tot xx - de verdere route naar de host.

zie http://be.providers.narkive.com/KmI7L0i ... verbinding

[krisken]

Die extra hop met dat 10.x.y.z ip is er al een tijdje (meer dan 4 maand).

[680x0]

Die extra hop met dat 10.x.y.z ip is er al een tijdje (meer dan 4 maand).

Dat kan zeker, het valt me alleen nu net op.

Is er een (technische) reden waarom dat veranderd is ?

[680x0]

EDIT 2:

als je een trace naar buiten toe doet zal je dit zien:

1 - het ip van je router
2 - het ip van je telenet-kabelmodem (het interne ip waarmee telenet
updates naar de modem kan sturen en de modem resetten)
3 tot xx - de verdere route naar de host.

zie http://be.providers.narkive.com/KmI7L0i ... verbinding

Dat modem IP zou je niet mogen zien want dat heeft niets te maken met uw eigen internet verbinding. Dat die modem in een pool zit van TN is normaal, anders kan TN geen updates doen en kan je er via 'mijn telenet' niets aan veranderen, maar waarom was dit vroeger niet zichtbaar en nu wel ?

[krisken]

Ik hoor nu dat dit niet bij iedereen het geval is... Bizar!
Nu zien wij bvb al jaar en dag al die "xxxxxxxxxx.access.telenet.be" hops op een traceroute. Vroeger (10 jaar terug) zag je deze helemaal niet zelfs!

Voorbeeldje van een traceroute van Mobistar, die nochthans hetzelfde netwerk gebruiken als Telenet. Niet letten op de hoge latency : ik ben de upload op dit moment nogal stevig aan het dicht trekken

C:\WINDOWS\System32>tracert google.be

Tracing route to google.be [216.58.208.195]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 10.101.0.1
2 * * * Request timed out.
3 422 ms 439 ms 254 ms 212.65.36.203
4 415 ms 473 ms * 81.52.186.121
5 361 ms 388 ms 422 ms tengige0-14-0-0.auvtr4.Aubervilliers.opentransit.net [193.251.240.237]
6 527 ms 396 ms 435 ms 209.85.172.162
7 499 ms 431 ms 467 ms 216.239.57.35
8 465 ms 484 ms 492 ms 209.85.143.241
9 375 ms 387 ms 428 ms par10s21-in-f195.1e100.net [216.58.208.195]

Trace complete.

[Sinna]

Is mij ook al opgevallen. Toen ik inbelde bij Telenet Solutions (voor een andere case) wisten ze er ook niet meteen een antwoord op te geven.

Het wordt helemaal mooi als je volgende traceroute ziet:

Code: Selecteer alles

Tracing route to 81.82.199.24
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.x.x
  2    11 ms     8 ms     9 ms  10.50.64.1
  3    14 ms    11 ms    13 ms  dD5E0CAD9.access.telenet.be [213.224.202.217]
  4    12 ms     5 ms    11 ms  10.50.64.1
  5    17 ms    17 ms    14 ms  81.82.199.24

Trace complete.

Dit is een traceroute naar mijn andere modem op dezelfde node.
Dat lijkt mij korter te kunnen daar hop 2 en 4 schijnbaar hetzelfde IP-adres hebben waardoor 3 en 4 eigenlijk overbodig zijn...

[petzl]

net zoals voo is telenet blijkbaar begonnen met de klanten geen publiek ipv4 adres ip te geven.
is er iemand die dit kan bevestigen? (zijn dit de kleine lettertjes bij nieuwe abo's ?)

zou wel leuk zijn dat je ergens een optie hebt om toch via een eigen ip naar buiten te gaan.

die trace naar belnet is trouwens een ipv6 trace

kan natuurlijk ook zo zijn dat ze dit toepassen bij mensen welke geen porten open hebben gezet, in dat geval zal je er geen last mee hebben.

[AndRo555]

Code: Selecteer alles

traceroute to userbase.be (79.132.231.171), 64 hops max, 52 byte packets
 1  pandorabox (192.168.1.1)  1.870 ms  1.288 ms  1.284 ms
 2  * pandorabox (192.168.1.1)  2.384 ms *
 3  dd5e0cad1.access.telenet.be (213.224.202.209)  11.656 ms
    10.127.128.1 (10.127.128.1)  25.558 ms
    dd5e0cad1.access.telenet.be (213.224.202.209)  11.574 ms
 4  213-224-29-71.ifiber.telenet-ops.be (213.224.29.71)  12.887 ms  10.045 ms  11.333 ms
 5  10.47.0.36 (10.47.0.36)  10.988 ms  10.096 ms  13.595 ms
 6  10.47.30.34 (10.47.30.34)  30.849 ms
    lrswitch-access-1.kulnet.kuleuven.be (193.190.253.189)  12.766 ms  13.879 ms
 7  10ge.cr1.brueve.belnet.net (193.191.2.45)  19.416 ms  21.612 ms  23.793 ms
 8  193.191.16.26 (193.191.16.26)  20.563 ms
    dd5e0fd15.access.telenet.be (213.224.253.21)  26.643 ms
    10ge.cr2.brueve.belnet.net (193.191.16.26)  16.500 ms
 9  edpnet.bnix.net (194.53.172.89)  31.073 ms  28.389 ms  13.155 ms
10  router01.sn.be.edpnet.net (212.71.1.61)  17.555 ms  79.156 ms  14.172 ms

Hier staat die er ook tussen. (telenet => kuleuven => belnet)

[driesp]

Misschien zijn ze beetje bij beetje de interfaces van routers (verbindingen tussen routers) te hernummeren naar private adressen.
Dat wil niet rechtstreeks zeggen dat ze daarom NAT doen (of cgnat)
Het kan perfect gecombineerd worden met publiek routeerbare adressen.
Enkel nadeel is misschien cosmetisch dat je dan geen rdns ziet, of naam van de router bij een traceroute.

Redenen zouden kunnen zijn (ben daar uiteraard niet zeker van)
- dat ze zo meer publieke ipv4 kunnen recupereren
- om het netwerk beter te beveiligen in het algemeen (of tegen DDOS richting routers),
(=> misschien hebben ze minder capaciteit om bestand te zijn hiertegen op de network edge)

[680x0]

Misschien zijn ze beetje bij beetje de interfaces van routers (verbindingen tussen routers) te hernummeren naar private adressen.
Dat wil niet rechtstreeks zeggen dat ze daarom NAT doen (of cgnat)
Het kan perfect gecombineerd worden met publiek routeerbare adressen.
Enkel nadeel is misschien cosmetisch dat je dan geen rdns ziet, of naam van de router bij een traceroute.

Redenen zouden kunnen zijn (ben daar uiteraard niet zeker van)
- dat ze zo meer publieke ipv4 kunnen recupereren
- om het netwerk beter te beveiligen in het algemeen (of tegen DDOS richting routers),
(=> misschien hebben ze minder capaciteit om bestand te zijn hiertegen op de network edge)

U doelt op die *.access.* ip's die publieke ip's zijn en die ze nu (mogelijk) langzaam aan private adressen geven om zo wat ipv4 ip's te recupereren ?

Zelfs als dat het geval is dan lijkt het aantal ip's dat ze daarmee uitsparen minimaal. Mij lijkt dat er een andere (technische) reden achterzit. En als het voor intern gebruik is, dan kan en mag TN zelf toch een reverse dns server opzetten om hun intern netwerk van hostnames te voorzien ? Niet omdat het er dan mooier uitziet, maar het zou het duidelijker maken.

[driesp]

Ik ben maar wat aan het speculeren, echt zeker weten zal ik nooit.
Maar je hebt gelijk,
de adressen dat ze daarmee uitsparen is minimaal.
Ik heb er nog niet goed over nagedacht.

Normaal is het (volgens de RFC) de bedoeling dat er bij een TTL expire er gereplyed moet worden met het ipadres van de interface waarop het packet werd ontvangen.
Dus misschien heeft die interface verschillende IP adressen actief,
en wordt de TTL expire terug gestuurd met als source adres een ander IP adres dat actief is op die interface (in dit geval het 'laagste' IP adres actief op die interface).

[Tomsworld]

Stop even het is niet omdat je in een traceert een hop ziet met interne ip's dat je moet redeneren dat daar nat gebeurd, wat je ziet zijn idd routers die routeren via private ip's op de interfaces, op zich is dat goed nieuws, ze gebruiken geen dure public ip's puur voor routing taken. Het enige probleem is dat als je een omgekeerde traceroute gaat doen van internet naar jou dat we een hop gaan krijgen met * * *.