kan sommige sites niet bezoeken.

[Ofloo]

Iemand enig idee, waarom ik het ip 62.93.192.11 niet kan bereiken. Wel ik kan het tracen, scannen, maar niet pingen en/of connecteren naar tcp port 80

Code: Selecteer alles

narf# traceroute 62.93.192.11
traceroute to 62.93.192.11 (62.93.192.11), 64 hops max, 40 byte packets
 1  83-217-95-81.adsl.realdsl.be (83.217.95.xx)  1.085 ms  7.372 ms  1.289 ms
 2  loopback0.dr1.bebru1.realroute.net (193.27.64.26)  12.221 ms  11.106 ms  10.281 ms
 3  at1-3-0-2.br0.bebru1.realroute.net (193.27.64.77)  11.273 ms  11.437 ms  10.537 ms
 4  so0-1-1.br0.bebru1.realroute.net (193.27.64.150)  11.536 ms  12.194 ms  11.723 ms
 5  ge2-0-0-32.br0.uklon1.realroute.net (193.27.64.178)  22.870 ms  22.758 ms  24.103 ms
 6  pos3-0.mpr2.lhr1.uk.above.net (208.184.231.73)  30.225 ms  31.285 ms  32.135 ms
 7  so-4-1-0.cr2.lhr3.uk.above.net (208.185.156.2)  25.575 ms  24.167 ms  26.148 ms
 8  so-0-2-0.cr2.fra1.de.above.net (64.125.29.150)  31.354 ms  34.525 ms  30.495 ms
 9  pos0-0.mpr1.fra2.de.above.net (216.200.115.246)  29.714 ms  30.579 ms  30.755 ms
10  62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11)  32.398 ms  30.629 ms  30.220 ms
narf# ping 62.93.192.11
PING 62.93.192.11 (62.93.192.11): 56 data bytes
92 bytes from 62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6cd2   0 0000  37  01 6543 83.217.95.xx  62.93.192.11

92 bytes from 62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6ce1   0 0000  37  01 6534 83.217.95.xx  62.93.192.11

92 bytes from 62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6ceb   0 0000  37  01 652a 83.217.95.xx  62.93.192.11

^C
--- 62.93.192.11 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
narf# ping www.google.be
PING www.l.google.com (66.249.93.99): 56 data bytes
64 bytes from 66.249.93.99: icmp_seq=0 ttl=244 time=34.537 ms
64 bytes from 66.249.93.99: icmp_seq=1 ttl=244 time=35.499 ms
64 bytes from 66.249.93.99: icmp_seq=2 ttl=244 time=35.707 ms
^C
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 34.537/35.248/35.707/0.510 ms
narf# nmap -sS -P0 -p80 62.93.192.11

Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-12-03 16:44 CET
Interesting ports on 62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11):
PORT   STATE SERVICE
80/tcp open  http

Nmap finished: 1 IP address (1 host up) scanned in 0.054 seconds
narf#

het rare is dat ik ze kan tracen can scannen en eigenlijk connecteren maar de connectie is er en dat is het.. geen timeout.. browser blijft de pagina laden maar er komt niks op het scherm.

[meon]

Als ik dat IP ingeef in m'n browser kom ik bij nero.com uit.
Dat IP resolven geeft 62.93.192.11.insoft.fra2.de.mfnx.net
Ik kan het niet pingen.
De hops zijn bij mij:

Code: Selecteer alles

  2  1-134.247.81.adsl.skynet.be [81.247.134.1]
  3  229.237-201-80.adsl.skynet.be [80.201.237.229]
  4  ge1-0.intlstr1.isp.belgacom.be [194.78.0.146]
  5  cbu-pcbru11-skynet-pos20.car.belbone.be [195.13.13.6]
  6  cbu-pecams22-pcams11-pos20.car.belbone.be [80.84.18.74]
  7  mpr2.ams1.if-6-3.above.net [82.98.253.213]
  8  so-1-1-0.cr2.fra1.de.above.net [64.125.23.249]
  9  pos0-0.mpr1.fra2.de.above.net [216.200.115.246]
 10     *        *        *

Allemaal skynet.

[netdata]

een server hoef je niet te kunnen pingen he.

Als de firewall of server zelf ICMP tegenhoud ga je geen tracert kunnen doen noch pingen.

maar ik kom MET realDSL ook op nero uit

[Ofloo]

het rare is dat ik kan tracen maar dat als ik telnet naar poort 80 dat ik geen header reply krijg.. de poort word gewoon gesloten. of blijft open en wachten.. voor een reply.

[ubremoved_539]

het rare is dat ik kan tracen maar dat als ik telnet naar poort 80 dat ik geen header reply krijg.. de poort word gewoon gesloten. of blijft open en wachten.. voor een reply.

Tracen en TELNET hebben niets met elkaar te maken... het eerste is ICMP verkeer, het tweede TCP. Trouwens een TELNET naar een webserver hoeft geen header reply te geven... maar probeer eens gewoon "GET / HTTP/1.1<enter><enter>" (of open de URL in je browser)

[Ofloo]

het rare is dat ik kan tracen maar dat als ik telnet naar poort 80 dat ik geen header reply krijg.. de poort word gewoon gesloten. of blijft open en wachten.. voor een reply.

Tracen en TELNET hebben niets met elkaar te maken... het eerste is ICMP verkeer, het tweede TCP. Trouwens een TELNET naar een webserver hoeft geen header reply te geven... maar probeer eens gewoon "GET / HTTP/1.1<enter><enter>" (of open de URL in je browser)

Ik weet heel goed dat icmp niet tcp is en andersom ook, dat het niks met elkaar te maken heeft. Ook weet ik dat sommige servers geen icmp aanvaarden heb het lang zelf geblokked..

'k Had het al gedaan wat je voorstelde.. een telnet (netcat) naar poort 80 en een get gedaan.

narf# netcat www.nero.com 80
GET / HTTP/1.1
Host: www.nero.com
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Wed, 07 Dec 2005 06:45:00 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
X-Powered-By: PHP/4.3.10
Location: http://www.nero.com/eng/index.html
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

0

met weinig resultaat, na een goede minuut sluit get gewoon terug

[Ofloo]

ik heb het getest op 4 systemen freebsd4.11, freebsd5.4, linux debian, windows xp sp2

verscheidene browsers: mozilla, netscape, lynx, internet explorer, Epiphany

het enige wat ik kan constateren is dat het niet laadt. de browsers connecteren en ze laden gewoon niet als ik een proxy gebruik werkt het wel. ..

'k heb ook 6 verschillende ip's geprobeerd dus nee het is geen blacklist of firewall block het moet een route probleem zijn.. maar 'k zie niet goed in hoe dat dit kan.

[ubremoved_539]

narf# netcat www.nero.com 80
GET / HTTP/1.1
Host: www.nero.com
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Wed, 07 Dec 2005 06:45:00 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
X-Powered-By: PHP/4.3.10
Location: http://www.nero.com/eng/index.html
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

0

met weinig resultaat, na een goede minuut sluit get gewoon terug

Weinig resultaat... de HTTP server geeft je toch een response (zo kan je zien dat het een Apache/1.3.33 (Unix) PHP/4.3.10 is oa.)

[Ofloo]

narf# netcat www.nero.com 80
GET / HTTP/1.1
Host: www.nero.com
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 302 Found
Date: Wed, 07 Dec 2005 06:45:00 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
X-Powered-By: PHP/4.3.10
Location: http://www.nero.com/eng/index.html
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

0

met weinig resultaat, na een goede minuut sluit get gewoon terug

Weinig resultaat... de HTTP server geeft je toch een response (zo kan je zien dat het een Apache/1.3.33 (Unix) PHP/4.3.10 is oa.)

daar ben ik niks mee als ik de pagina gewoon niet krijg.. normaal is een 302 een forward.. maar dan als ik manueel een forward doe dus gewoon de pagina neem en .. wil bekijken komt er niks te voorschijn.

daarom weinig resultaat ..

Location: http://www.nero.com/eng/index.html laadt niet..

[airzimmy]

je hebt geen squid proxy of linux based router?
Al eens tcpdumps ed bekeken?

[Patje]

het rare is dat ik kan tracen maar dat als ik telnet naar poort 80 dat ik geen header reply krijg.. de poort word gewoon gesloten. of blijft open en wachten.. voor een reply.

Port 80 = Web Server
If you have Windows, make sure you aren't infected with the Code Red virus !!!
doe mss es een test op deze LINK poortscan test

[Ofloo]

het rare is dat ik kan tracen maar dat als ik telnet naar poort 80 dat ik geen header reply krijg.. de poort word gewoon gesloten. of blijft open en wachten.. voor een reply.

Port 80 = Web Server
If you have Windows, make sure you aren't infected with the Code Red virus !!!
doe mss es een test op deze LINK poortscan test

op 4 verschillende systemen of wat en 3 operating systems..

[netdata]

op 4 verschillende systemen of wat en 3 operating systems..

Als jij zo getest hebt en met proxy werkt et wel dan zie ik maar een ding en dat is een firewall... dan dat?

[ubremoved_539]

Als jij zo getest hebt en met proxy werkt et wel dan zie ik maar een ding en dat is een firewall... dan dat?

Als een firewall voor problemen zou zorgen zou hij ook de headers van de webserver niet terugkrijgen. Het lijkt er op alsof het fout gaat zodra de effectieve HTML moet volgen.

Denk dat je best eens snift om te kijken wat er precies gaande is.

[netdata]

Als jij zo getest hebt en met proxy werkt et wel dan zie ik maar een ding en dat is een firewall... dan dat?

Als een firewall voor problemen zou zorgen zou hij ook de headers van de webserver niet terugkrijgen. Het lijkt er op alsof het fout gaat zodra de effectieve HTML moet volgen.

Denk dat je best eens snift om te kijken wat er precies gaande is.

Je hebt een punt.
Maar als je SPI doet op de firewall (Statefull Packet Inspection) krijg je altijd een Header reply maar dropt de firewall de volgende packets omdat hij het niet herkent.
Dus als jou router SPI ondersteunt (of firewall) zet dit even uit.

Lijkt me de enige kans...

[Ofloo]

Als jij zo getest hebt en met proxy werkt et wel dan zie ik maar een ding en dat is een firewall... dan dat?

Als een firewall voor problemen zou zorgen zou hij ook de headers van de webserver niet terugkrijgen. Het lijkt er op alsof het fout gaat zodra de effectieve HTML moet volgen.

Denk dat je best eens snift om te kijken wat er precies gaande is.

Je hebt een punt.
Maar als je SPI doet op de firewall (Statefull Packet Inspection) krijg je altijd een Header reply maar dropt de firewall de volgende packets omdat hij het niet herkent.
Dus als jou router SPI ondersteunt (of firewall) zet dit even uit.

Lijkt me de enige kans...

Heb spi niet aanstaan.., 'k veronderstel toch dat het uitstaat als ik de firewall uitzet .. en alles uncheck

[ubremoved_539]

Je hebt een punt.
Maar als je SPI doet op de firewall (Statefull Packet Inspection) krijg je altijd een Header reply maar dropt de firewall de volgende packets omdat hij het niet herkent.
Dus als jou router SPI ondersteunt (of firewall) zet dit even uit.

Lijkt me de enige kans...

De HTTP header die voor ieder request zit heeft niets te maken met TCP/IP headers... trouwens de HTTP header en data zitten in hetzelfde packet en op dat moment is de ganse setup van een TCP verbinding reeds opgezet.

[netdata]

Je hebt een punt.
Maar als je SPI doet op de firewall (Statefull Packet Inspection) krijg je altijd een Header reply maar dropt de firewall de volgende packets omdat hij het niet herkent.
Dus als jou router SPI ondersteunt (of firewall) zet dit even uit.

Lijkt me de enige kans...

De HTTP header die voor ieder request zit heeft niets te maken met TCP/IP headers... trouwens de HTTP header en data zitten in hetzelfde packet en op dat moment is de ganse setup van een TCP verbinding reeds opgezet.

Hier ben je fout hoor.
SPI is net een systeem dat ook de data headers van een TCP packet gaat lezen.
Bij mij is SPI opgezet met de bedoelding dat er enkel HTTP 1.1 trafiek door poort 80 geraakt, zo is het bijvb niet mogelijk een SSH tunnel op te starten van die poort.

De check gebeurd op een geldige HTTP header (en zit dus in het datapacket van uw TCP stream)
Merkt de firewall dat hij geen geldige Headers krijgt dan dropt hij de verbinding.
En SPI is veel meer dan header checking, zo kan hij ook session spoofing (hijacking) tegen gaan en kan hij DDOS aavallen herkennen en stoppen.

en SPI bevint zicht zo wat tussen een firewall en een proxy server.

[ubremoved_539]

Hier ben je fout hoor.

Nope... lees het nog maar eens... trouwens de reply van de webserver is een reeks bytes waarbij eerst de HTTP header zit, twee linefeeds, en dan de HTML. Ofwel komt dergelijk packet erdoor, ofwel niet.

[netdata]

Nope... lees het nog maar eens... trouwens de reply van de webserver is een reeks bytes waarbij eerst de HTTP header zit, twee linefeeds, en dan de HTML. Ofwel komt dergelijk packet erdoor, ofwel niet.

Als ik fout ben geef ik graag toe, maar hier ben je echt mis hoor... (wat SPI betreft, al de rest heb je correct)

http://www.wyae.de/docs/gateways.php

kijk naar Stateful Inspection Packet Filters

Alsook hier: http://www.webopedia.com/TERM/S/statefu ... ction.html

Maar swat

Indien je een Telnet opstart naar een webserver (snif het maar )
dan ga je allereest andere optie's onderhandelen dan dat een browers een TCP sessie opstart zoals aantal buffer tekenes enzo (typische dingen aan een telnet) vervogens 'verwacht' de webserver een HTTP GET hierop gaat de webserver een antwoord geven.

Waarschijnlijk zal bovenstaande probleem geen SPI probleem zijn omdat gewone firewalls met SPI niet zo geavanceerd zijn.
Overigens als je SPI verkeerd instelt (wat wel kan met het probleem hieboven)
hoeven niet alle packets gedropt worden.

Ikzelf heb erg veel ervaring met Checkpoint FW-1 zij waren de uitvinders en koplopers van SPI ik weet dus tamelijk goed waarover ik het heb hoor

en het zou de eerste niet zijn die niet kan surfen omwille van een foutieve SPI.

but hey, no hard feelings hoor

EDIT:

trouwens de reply van de webserver is een reeks bytes waarbij eerst de HTTP header zit

Foei, je moet je layers uit elkaar halen een webserver stuurt evengoed een ethernetframe...
SPI speelt zich af tussen layer 3 en layer 6 soms zelfs 7

[ubremoved_539]

Indien je een Telnet opstart naar een webserver (snif het maar ) dan ga je allereest andere optie's onderhandelen dan dat een browers een TCP sessie opstart zoals aantal buffer tekenes enzo (typische dingen aan een telnet) vervogens 'verwacht' de webserver een HTTP GET hierop gaat de webserver een antwoord geven.

Nope... die TELNET client doet niets... die wacht netjes op de server voor zo'n onderhandelingen. In het geval van een webserver gebeurd er dus niets... en zal je bij een GET vanuit je TN client ook dat en alléén dat maar sturen (snig het inderdaad maar eens). Puur op TCP/IP niveau zie je niet dat de client voor je webserver een TN client is, dan wel een browser !

Waarschijnlijk zal bovenstaande probleem geen SPI probleem zijn omdat gewone firewalls met SPI niet zo geavanceerd zijn. Overigens als je SPI verkeerd instelt (wat wel kan met het probleem hieboven) hoeven niet alle packets gedropt worden.

Dit is inderdaad geen SPI... die zit namelijk op de requests, en in dit geval is het request goed gegaan en is het de reply die er ook doorkomt... zij het dat er blijkbaar maar een stuk van de reply zichtbaar is (iets wat bij SPI ook nooit het geval zou zijn... daar zou het packet volledig gedropt worden).

but hey, no hard feelings hoor

Geen probleem hoor... iedereen maakt fouten... en ik zal ze dan ook altijd toegeven, maar volgens mij ben je nog steeds fout (denk dat je het concept van de HTTP header verward met een TCP/IP header).

[BungaMan]

...

Location: http://www.nero.com/eng/index.html laadt niet..

Je enige punt is het niet kunnen openen van /eng/index.html. Voor de rest is er niks mis. Probeer nog eens telnet maar ipv "GET / HTTP/1.1" doe je "GET /eng/index.html HTTP/1.1" of "GET http://www.nero.com/eng/index.html HTTP/1.1". Wat bedoel je met manueel een forward doen, Copy en paste in browser? Als het werkt met telnet moet je toch maar eens naar je browser kijken dan.

[Ofloo]

hmm, 'k kan mijn spi niet instellen... is een wag54gv2

[Ofloo]

nu ben ik bepaalde zaken gaan uitsluiten.. en dus .. heb ik het volgende:


als ik de gewone header vraag via telnet

netcat 62.93.193.29 80

GET / HTTP/1.1
Host: www.nero.com
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

krijg ik responds:

HTTP/1.1 302 Found
Date: Fri, 23 Dec 2005 20:15:05 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
X-Powered-By: PHP/4.3.10
Location: http://www.nero.com/eng/index.html
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

als ik dan manueel de forward doe.. krijg ik gewoon geen antwoord meer ..

netcat 62.93.193.29 80
GET /eng/index.html HTTP/1.1
Host: www.nero.com
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

en een traceroute werkt perfect

traceroute -v www.nero.com
traceroute: Warning: www.nero.com has multiple addresses; using 62.93.192.11
traceroute to www.nero.com (62.93.192.11), 64 hops max, 40 byte packets
1 83-217-95-81.adsl.realdsl.be (83.217.95.81) 48 bytes to 83.217.95.82 0.859 ms 1.344 ms 1.728 ms
2 193.27.64.25 (193.27.64.25) 36 bytes to 83.217.95.82 10.435 ms 9.880 ms 10.535 ms
3 ge1-1-0-801.br0.bebru1.realroute.net (83.143.241.49) 36 bytes to 83.217.95.82 10.291 ms 13.362 ms 10.273 ms
4 ge2-0-0-32.br0.uklon1.realroute.net (193.27.64.178) 36 bytes to 83.217.95.82 17.196 ms 16.337 ms 17.177 ms
5 v101-r4.thn.telecomplete.net (213.160.96.121) 36 bytes to 83.217.95.82 28.744 ms 30.193 ms 29.233 ms
6 ge3-0.pr1.lhr1.uk.above.net (195.66.224.76) 36 bytes to 83.217.95.82 19.408 ms 17.734 ms 17.670 ms
7 pos3-0.mpr2.lhr1.uk.above.net (208.184.231.73) 148 bytes to 83.217.95.82 17.715 ms 17.884 ms 17.949 ms
8 so-4-1-0.cr2.lhr3.uk.above.net (208.185.156.2) 36 bytes to 83.217.95.82 17.413 ms 17.234 ms 17.205 ms
9 so-7-0-0.mpr1.ams5.nl.above.net (64.125.27.178) 36 bytes to 83.217.95.82 30.989 ms 31.678 ms 30.979 ms
10 so-0-0-0.mpr3.ams1.nl.above.net (64.125.27.181) 36 bytes to 83.217.95.82 31.714 ms 30.952 ms 31.457 ms
11 so-1-1-0.cr2.fra1.de.above.net (64.125.23.249) 36 bytes to 83.217.95.82 38.807 ms 40.257 ms 38.626 ms
12 gi-9-4.er2a-fra1-de.above.net (64.125.23.190) 36 bytes to 83.217.95.82 40.483 ms 39.749 ms 39.051 ms
13 62.93.192.11.insoft.fra2.de.mfnx.net (62.93.192.11) 48 bytes to 83.217.95.82 62.818 ms 64.096 ms 61.806 ms

is dan ook icmp maarja..


wat ik heel erg vreemd vind is dus, dat als ik telnet een header reply krijg naar een forward, en als ik die reply rechtstreeks opvraag dat ik gewoon geen antwoord krijg van de server..

hoe kan ik in godsnaam 1 header reply krijgen en een andere niet..

[Ofloo]

blijkbaar heeft het dus niks met forwards te maken.. want ik kan www.voipbuster.com wel bezoeken en die heeft ook 302 bah terug van nul gaan zoeken wat het probleem zou kunnen zijn.

[Ofloo]

route probleem ? ??

narf# ping -c 5 193.27.64.153
PING 193.27.64.153 (193.27.64.153): 56 data bytes
64 bytes from 193.27.64.153: icmp_seq=0 ttl=252 time=11.964 ms
64 bytes from 193.27.64.153: icmp_seq=1 ttl=252 time=11.267 ms
64 bytes from 193.27.64.153: icmp_seq=2 ttl=252 time=17.575 ms
64 bytes from 193.27.64.153: icmp_seq=3 ttl=252 time=12.581 ms
64 bytes from 193.27.64.153: icmp_seq=4 ttl=252 time=11.885 ms

--- 193.27.64.153 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 11.267/13.054/17.575/2.298 ms
narf# ping -c 5 www.belgacom.be
PING www.belgacom.be (195.13.1.101): 56 data bytes

--- www.belgacom.be ping statistics ---
narf# traceroute -v www.belgacom.be
traceroute to www.belgacom.be (195.13.1.101), 64 hops max, 40 byte packets
1 83-217-95-81.adsl.realdsl.be (83.217.95.81) 48 bytes to 83.217.95.82 1.028 ms 1.223 ms 1.551 ms
2 193.27.64.25 (193.27.64.25) 36 bytes to 83.217.95.82 11.685 ms 10.613 ms 10.026 ms
3 ge1-1-0-801.br0.bebru1.realroute.net (83.143.241.49) 36 bytes to 83.217.95.82 11.297 ms 10.465 ms 9.795 ms
4 pecbru51.car.belbone.be (193.27.65.218) 36 bytes to 83.217.95.82 11.045 ms 10.758 ms 10.513 ms
5 cbu-pcbru21-pecbru51-ge50.car.belbone.be (80.84.18.136) 148 bytes to 83.217.95.82 12.048 ms cbu-pcbru25-pecbru51-ge117.car.belbone.be (80.84.18.66) 148 bytes to 83.217.95.82 12.002 ms cbu-pcbru21-pecbru51-ge50.car.belbone.be (80.84.18.136) 148 bytes to 83.217.95.82 13.295 ms
6 cbu-130.18.84.80.baddescr42-pcbru25.car.belbone.be (80.84.18.131) 36 bytes to 83.217.95.82 10.965 ms 11.405 ms 11.269 ms
7 cbu-skynet-pcbru21.car.belbone.be (195.13.13.13) 36 bytes to 83.217.95.82 11.013 ms 11.194 ms 11.261 ms
8 ge0-2.icorebnc1.isp.belgacom.be (194.78.0.130) 36 bytes to 83.217.95.82 10.851 ms 12.019 ms 11.085 ms
9 core2-atm3-0-0-4.paille.brussels.belbone.net (195.13.3.221) 36 bytes to 83.217.95.82 13.717 ms 12.744 ms 12.241 ms
10 30.10.belbone.be (195.13.10.30) 36 bytes to 83.217.95.82 13.004 ms 13.434 ms 12.565 ms
11 *
36 bytes from 193.27.64.153 to 83.217.95.82: icmp type 3 (Dest Unreachable) code 0
4: x00300045
8: x0040adbc
12: x3b0c063d
16: x525fd953
20: x0c01a8c0
24: x521b93d7
28: xcd1f3889
32: x00000000
*
36 bytes from 193.27.64.145 to 83.217.95.82: icmp type 3 (Dest Unreachable) code 0
4: x00400045
8: x00409abd
12: x3f0b063d
16: x525fd953
20: x0b01a8c0
24: x521bc1f3
28: xc141b817
32: x00000000