I'm studying some useful unix networking tools like traceroute and I found a strange behaviour using tcp packets instead of using udp or icmp ones.
In particular, if I try to traceroute whatever website the system reaches the destination in just one hops. These are some trials I did:
$ traceroute -T google.com
traceroute to google.com (216.58.209.46), 30 hops max, 60 byte packets
1 mil07s12-in-f14.1e100.net (216.58.209.46) 10.316 ms 10.263 ms 10.241 ms
$ traceroute -T tomshw.com
traceroute to tomshw.com (64.190.63.111), 30 hops max, 60 byte packets
1 64.190.63.111 (64.190.63.111) 2.940 ms 2.900 ms 2.878 ms
$ traceroute -T corriere.it
traceroute to corriere.it (185.53.36.36), 30 hops max, 60 byte packets
1 cache.corriere.it (185.53.36.36) 6.123 ms 6.063 ms 6.017 ms
$ traceroute -T facebook.com
traceroute to facebook.com (157.240.203.35), 30 hops max, 60 byte packets
1 edge-star-mini-shv-01-mxp2.facebook.com (157.240.203.35) 2.889 ms 2.855 ms 2.838 ms
$ traceroute -T interno.gov.it
traceroute to interno.gov.it (99.86.153.34), 30 hops max, 60 byte packets
1 server-99-86-153-34.mxp64.r.cloudfront.net (99.86.153.34) 5.960 ms 5.923 ms 5.892 ms
Instead, using udp packets or icmp packets the destination is reachead in a reasonable number of hops:
$ traceroute google.com
traceroute to google.com (216.58.209.46), 30 hops max, 60 byte packets
1 _gateway (192.168.182.1) 24.216 ms 24.172 ms 24.155 ms
2 192.168.10.1 (192.168.10.1) 24.143 ms 24.117 ms 24.088 ms
3 82.113.192.132 (82.113.192.132) 33.846 ms 33.818 ms 33.800 ms
4 185.25.74.93 (185.25.74.93) 47.396 ms 47.379 ms 47.367 ms
5 hu-0-0-1-2.ncs55-1-jn.network.twt.it (185.25.74.130) 47.350 ms 47.337 ms 54.092 ms
6 142.250.169.248 (142.250.169.248) 54.073 ms 32.662 ms 35.847 ms
7 * * *
8 108.170.245.65 (108.170.245.65) 35.724 ms 61.251 ms 216.239.40.200 (216.239.40.200) 51.454 ms
9 108.170.245.73 (108.170.245.73) 131.758 ms 108.170.232.181 (108.170.232.181) 105.612 ms 108.170.245.73 (108.170.245.73) 131.720 ms
10 172.253.71.141 (172.253.71.141) 61.114 ms mil07s12-in-f14.1e100.net (216.58.209.46) 61.095 ms 61.126 ms
$ traceroute -I google.com
traceroute to google.com (216.58.209.46), 30 hops max, 60 byte packets
1 _gateway (192.168.182.1) 21.592 ms 37.848 ms 41.086 ms
2 192.168.10.1 (192.168.10.1) 47.584 ms 50.838 ms 54.088 ms
3 82.113.192.132 (82.113.192.132) 57.354 ms 63.878 ms 63.870 ms
4 185.25.74.93 (185.25.74.93) 63.861 ms 63.846 ms 63.901 ms
5 hu-0-0-1-2.ncs55-1-jn.network.twt.it (185.25.74.130) 63.891 ms 1457.578 ms 1457.568 ms
6 142.250.169.248 (142.250.169.248) 70.296 ms 14.804 ms 33.535 ms
7 209.85.242.39 (209.85.242.39) 82.764 ms 82.748 ms 82.731 ms
8 108.170.232.169 (108.170.232.169) 82.712 ms 82.696 ms 82.745 ms
9 mil07s12-in-f14.1e100.net (216.58.209.46) 225.226 ms 228.457 ms 228.433 ms
Looking at Wireshark I have a synack for the first syn probe that has ttl = 1 and it is strange because it should expire.
Finally, trying to change the port, for example to 22, it seams to work a bit:
$ traceroute -T -p 22 google.com
traceroute to google.com (216.58.209.46), 30 hops max, 60 byte packets
1 _gateway (192.168.182.1) 10.014 ms 9.943 ms 9.921 ms
2 192.168.10.1 (192.168.10.1) 13.022 ms 12.947 ms 12.917 ms
3 82.113.192.132 (82.113.192.132) 38.882 ms 38.855 ms 38.832 ms
4 185.25.74.93 (185.25.74.93) 38.802 ms 38.846 ms 38.818 ms
5 hu-0-0-1-2.ncs55-1-jn.network.twt.it (185.25.74.130) 38.790 ms 38.765 ms 38.748 ms
6 142.250.169.248 (142.250.169.248) 38.649 ms 10.215 ms 10.256 ms
7 * * *
8 * * *
...
29 * * *
30 * * *
$ traceroute -T -p 22 tomshw.com
traceroute to tomshw.com (64.190.63.111), 30 hops max, 60 byte packets
1 _gateway (192.168.182.1) 5.657 ms 5.594 ms 5.567 ms
2 192.168.10.1 (192.168.10.1) 12.123 ms 12.099 ms 12.075 ms
3 82.113.192.132 (82.113.192.132) 17.724 ms 20.958 ms 20.934 ms
4 185.25.74.93 (185.25.74.93) 24.177 ms 24.154 ms 24.198 ms
5 te-0-2-0-1.asr9kp-jn.network.twt.it (82.113.194.246) 20.835 ms 20.812 ms 20.817 ms
6 81.25.202.185 (81.25.202.185) 24.095 ms 15.309 ms 18.446 ms
7 mno-b3-link.ip.twelve99.net (62.115.144.98) 18.414 ms 14.755 ms 17.877 ms
8 ffm-bb2-link.ip.twelve99.net (62.115.116.172) 29.702 ms 39.470 ms 39.454 ms
9 mcn-b3-link.ip.twelve99.net (62.115.124.47) 39.430 ms 39.407 ms 39.374 ms
10 internetx-ic332227-mcn-b2.ip.twelve99-cust.net (62.115.160.178) 39.350 ms 39.355 ms 39.329 ms
11 91.195.241.102 (91.195.241.102) 39.269 ms 39.239 ms 164.766 ms
12 91.195.241.118 (91.195.241.118) 167.982 ms 167.951 ms 91.195.241.114 (91.195.241.114) 207.035 ms
13 64.190.63.111 (64.190.63.111) 206.969 ms 206.940 ms 203.627 ms
What could be the explanation to this behaviour ? The operating system I'm using is Kubuntu 21.10 with default settings so I would exclude proxies or something like that.
traceroute man says:
tcp -T
Well-known modern method, intended to bypass firewalls.
Uses the constant destination port (default is 80, http).
so it seems there is some kind of invisible proxy for 80 port in your network
Related
I want to make TCP SYN requests using traceroute and discovered the flag -T. However, I don't know which values I have to use in order to make such requests.
Use -T option if you want to use TCP SYN for probing the remote address as shown in example below:
[root#localhost ~]# traceroute -T google.com
traceroute to google.com (172.217.31.206), 30 hops max, 60 byte packets
1 gateway (192.168.0.1) 2.050 ms 3.041 ms 2.819 ms
2 10.234.0.1 (10.234.0.1) 3.771 ms 3.749 ms 3.716 ms
3 * * *
4 * * *
5 * * *
6 14.140.100.6.static-vegas.net.us (14.140.100.6) 12.234 ms 13.070 ms 12.644 ms
7 * * *
8 * * *
9 108.170.253.97 (108.170.253.97) 11.451 ms 108.170.253.113 (108.170.253.113) 13.403 ms 108.170.253.97 (108.170.253.97) 13.886 ms
10 74.125.253.13 (74.125.253.13) 9.523 ms 11.963 ms 11.388 ms
11 maa03s28-in-f14.1e100.net (172.217.31.206) 10.477 ms 10.222 ms 8.391 ms
From here.
I am running a traceroute command to host [YYY.YYY.Y.Y], and at the output is as follows:
...
e1-25-20-cr-rt-bb2-area2.ns.uwaterloo.ca (ZZZ.ZZ.ZZ.ZZ) 4.164 ms 6.741 ms 6.444 ms
8 wms.uwaterloo.ca (MMM.MM.MMM.MM) 3.034 ms 3.612 ms 3.334 ms
9 wms.uwaterloo.ca (MMM.MM.MMM.MM) 3.802 ms !N 5.354 ms !N 5.588 ms !N
Several sources have told me that !N means that the destination host is unreachable. However, this seems to be the case when the output is as follows:
9 wms.uwaterloo.ca (129.97.208.23) !N !N !N
What does it mean when !N appears beside an elapsed time ?
I don't think I should be interpreting {elapsed_time} !N as destination unreachable since I was definitely able to reach my target destination through a web browser and through "ping".
wms.uwaterloo.ca sends back an ICMP Destination network unreachable message. Some protocols and port used by your traceroute are filtered. If you can create a packet capture then you will see and understand what happens under the hood.
IP address of source host is 10.192.240.10 and destination is 10.192.250.10. do the both hosts reside on same network or not ?
If so, How can we find it.
The first thing to know is the netmask. If the bits that are different are in the zero range of the netmask, then they should route on the same network. For instance, my home network uses 192.168.0.0/255.255.254.0 which means that 192.168.0.0-192.168.1.255 are routed by my home router ... 192.168.1.10 is on the same network with 192.168.0.10.
You could also try to traceroute from one to the other to determine how many hops. One hop means there's no active routing between the hosts, thus most likely the same network.
One hop, same network (kinda .. desktop is a wired connection, remote is a wireless connection; but from an IP point of view, the same):
paulw#desktop:~/PROJ$ traceroute 192.168.1.208
traceroute to 192.168.1.208 (192.168.1.208), 30 hops max, 60 byte packets
1 remote (192.168.1.208) 218.838 ms 219.288 ms 219.484 ms
paulw#desktop:~/PROJ$
Many hops, different network:
paulw#desktop:~/PROJ$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router.asus.com (192.168.1.1) 0.232 ms 0.410 ms 0.485 ms
2 xx.xxx.xx.x (xx.xxx.xx.x) 161.662 ms 161.701 ms 161.701 ms
3 xe-10-3-3-32767-sur03.arvada.co.denver.comcast.net (68.86.129.153) 87.925 ms 87.963 ms 88.518 ms
4 te-0-13-0-2-ar02.denver.co.denver.comcast.net (162.151.8.41) 89.585 ms xe-10-0-2-0-sur02.arvada.co.denver.comcast.net (68.86.128.138) 89.493 ms te-0-13-0-2-ar02.denver.co.denver.comcast.net (162.151.8.41) 89.574 ms
5 pos-0-7-0-0-ar02.aurora.co.denver.comcast.net (68.86.128.246) 91.431 ms 92.441 ms 97.540 ms
6 he-3-9-0-0-cr01.denver.co.ibone.comcast.net (68.86.92.21) 92.421 ms 95.757 ms 96.290 ms
7 xe-1-0-2-0-pe01.910fifteenth.co.ibone.comcast.net (68.86.84.122) 159.017 ms 74.074 ms 74.119 ms
8 as15169-1-c.910fifteenth.co.ibone.comcast.net (23.30.206.106) 74.667 ms 73.637 ms 73.654 ms
9 72.14.234.59 (72.14.234.59) 74.204 ms 72.14.234.57 (72.14.234.57) 78.921 ms 72.14.234.59 (72.14.234.59) 77.861 ms
10 216.239.46.146 (216.239.46.146) 89.413 ms 216.239.46.150 (216.239.46.150) 84.180 ms 216.239.46.146 (216.239.46.146) 83.705 ms
11 216.239.46.55 (216.239.46.55) 88.090 ms 72.14.239.50 (72.14.239.50) 27.409 ms 81.115 ms
12 216.239.46.193 (216.239.46.193) 85.238 ms 216.239.46.191 (216.239.46.191) 81.420 ms 216.239.43.217 (216.239.43.217) 81.457 ms
13 * * *
14 google-public-dns-a.google.com (8.8.8.8) 82.888 ms 83.473 ms 85.024 ms
paulw#desktop:~/PROJ$
This is strange. How this actually works. So far I know it is "impossible" to have a network like this.
I'm going to explain in details how my network works.
I have a LAN. 192.168.1.0/24 and router is on 192.168.1.1, This router has a public address.
I can share the IP address because I'm running there a server for tests nothing more. It is ok so far.
Now the magic happens.
When I trace the route to an IP I got this (To google DNS):
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 zonhub.home (192.168.1.1) 1.160 ms 1.676 ms 1.340 ms
2 * * *
3 10.137.211.97 (10.137.211.97) 12.915 ms 12.526 ms 12.145 ms
4 10.255.49.90 (10.255.49.90) 10.349 ms 10.255.49.102 (10.255.49.102) 11.483 ms 11.042 ms
5 80.157.128.249 (80.157.128.249) 34.577 ms 80.157.130.41 (80.157.130.41) 32.917 ms 80.157.130.33 (80.157.130.33) 30.602 ms
6 mad-sa3-i.MAD.ES.NET.DTAG.DE (217.5.95.161) 33.396 ms 80.157.128.22 (80.157.128.22) 27.107 ms mad-sa3-i.MAD.ES.NET.DTAG.DE (217.5.95.161) 29.510 ms
7 80.157.128.22 (80.157.128.22) 28.050 ms 72.14.235.20 (72.14.235.20) 32.767 ms 80.157.128.22 (80.157.128.22) 27.932 ms
8 72.14.235.20 (72.14.235.20) 29.780 ms 72.14.235.18 (72.14.235.18) 27.020 ms 26.706 ms
9 216.239.43.233 (216.239.43.233) 49.456 ms 209.85.240.191 (209.85.240.191) 44.034 ms 216.239.43.233 (216.239.43.233) 51.935 ms
10 72.14.236.191 (72.14.236.191) 53.374 ms 209.85.253.20 (209.85.253.20) 50.699 ms 216.239.43.233 (216.239.43.233) 44.918 ms
11 209.85.251.231 (209.85.251.231) 50.151 ms * 216.239.49.45 (216.239.49.45) 47.309 ms
12 google-public-dns-a.google.com (8.8.8.8) 51.536 ms 50.180 ms 45.505 ms
What is that 2nd, 3rd and 4th hop? How can it be on class A private address when 192.168.1.1 is running the NAT service where I have my LAN and my external 3 publics addresses (yes I have 3 and is 3 "class A" IP's on 88,89,93 network).
Another thing is how on 4th hop we have the 2nd octet 255?
Anyone feel free to traceroute my no-ip domain: synackfiles.no-ip.org
Just don't mess with my router (it blocks if you port scan or fail to log in in ssh or http auth so you get banned for this. If you just traceroute it is fine) :P
Now, second magic and weird stuff happens.
I'm going to run nmap. So i GOT THIS:
sudo nmap -sV -A -O 10.137.211.113 -vv -p 1-500 -Pn
Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-14 15:24 WET
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
Initiating Parallel DNS resolution of 1 host. at 15:24
Completed Parallel DNS resolution of 1 host. at 15:24, 0.04s elapsed
Initiating SYN Stealth Scan at 15:24
Scanning 10.137.211.113 [500 ports]
SYN Stealth Scan Timing: About 30.40% done; ETC: 15:26 (0:01:11 remaining)
SYN Stealth Scan Timing: About 60.30% done; ETC: 15:26 (0:00:40 remaining)
Completed SYN Stealth Scan at 15:26, 101.14s elapsed (500 total ports)
Initiating Service scan at 15:26
Initiating OS detection (try #1) against 10.137.211.113
Initiating Traceroute at 15:26
Completed Traceroute at 15:26, 9.05s elapsed
Initiating Parallel DNS resolution of 1 host. at 15:26
Completed Parallel DNS resolution of 1 host. at 15:26, 0.01s elapsed
NSE: Script scanning 10.137.211.113.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 15:26
Completed NSE at 15:26, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Nmap scan report for 10.137.211.113
Host is up (0.0010s latency).
All 500 scanned ports on 10.137.211.113 are filtered
Device type: general purpose|specialized|media device
Running: Barrelfish, Microsoft Windows 2003|PocketPC/CE|XP, Novell NetWare 3.X, Siemens embedded, Telekom embedded
OS CPE: cpe:/o:barrelfish:barrelfish cpe:/o:microsoft:windows_server_2003::sp1 cpe:/o:microsoft:windows_server_2003::sp2 cpe:/o:microsoft:windows_ce cpe:/o:microsoft:windows_xp:::professional cpe:/o:novell:netware:3.12
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SCAN(V=6.00%E=4%D=11/14%OT=%CT=%CU=%PV=Y%G=N%TM=5284EBAB%P=armv7l-unknown-linux-gnueabi)
T7(R=Y%DF=N%TG=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=R)
U1(R=N)
IE(R=N)
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 2.32 ms zonhub.home (192.168.1.1)
2 ... 30
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 122.65 seconds
Raw packets sent: 1109 (49.620KB) | Rcvd: 4 (200B)
Well, this is odd. I don't know how my country's WAN is designed and built.
I'm from Portugal and my ISP is "ZON TVCABO". You can search now. :P
This is very very very interesting..
Sincerely,
int3
I cannot tell you how your providers WAN is built - but in order to
save public IPs - one can design an ISPs internal network with private
IPs. The routers that are not needed to be available from public will
have private IPs only - the IPs assigned to you can be routed to your
uplink over routers that are ISP internally only.
the 2nd hop has no tracing allowed, but allows to forward them.
the 4th - 10.255.x.x is a private IP in the 10.0.0.0/8 A range. (you
can use numbers from 0-255)
I've kind of ran into an ugly snag. I developed a website for a client a few years back, and since then they've transferred their site to a different domain name provider and host. Now they want some updates, but when I try to access their site I get a Network Timeout (the page just tries to load for a few minutes, then firefox shows a Network Timeout error). I can access the site via a proxy, but proxies kinda suck and don't support everything, plus I'm a little paranoid about sending sensitive data through a proxy, not to mention I don't see how that would help me with FTP access and what not. I'm not exactly sure where along the line this problem is occurring... is my ISP blocking it, is the webserver blocking me, is it my router, or what's going on? I know of two sites that do this, and I think they're hosted by the same people.
The sites are http://fvringette.com/ and http://damngoodtimes.com/
#MarkusQ: traceroute for fvringette.com (which turns out to be the same as with damngoodtimes.com)
traceroute: Warning: Multiple interfaces found; using 134.117.14.35 # hme0
traceroute to 76.74.225.90 (76.74.225.90), 30 hops max, 40 byte packets
1 unix-gate.physics.carleton.ca (134.117.14.1) 0.973 ms 0.513 ms 0.514 ms
2 10.50.254.3 (10.50.254.3) 0.437 ms 0.385 ms 0.351 ms
3 10.30.33.1 (10.30.33.1) 0.488 ms 0.394 ms 0.370 ms
4 10.30.55.1 (10.30.55.1) 0.396 ms 0.416 ms 0.391 ms
5 134.117.254.242 (134.117.254.242) 0.708 ms 0.720 ms 0.704 ms
6 10.30.57.1 (10.30.57.1) 1.338 ms 1.221 ms 1.237 ms
7 kolker.fcican.com (207.34.252.249) 1.464 ms 1.544 ms 1.459 ms
8 * * *
9 154.11.3.17 (154.11.3.17) 7.355 ms 7.393 ms 7.426 ms
10 oc48.so-2-0-3.van-hc21e-cor-1.peer1.net (216.187.114.137) 62.762 ms 62.838 ms 62.625 ms
11 oc48.pos4-0.van-hc21e-dis-1.peer1.net (216.187.89.253) 62.795 ms 63.238 ms 62.893 ms
12 64.69.91.245 (64.69.91.245) 64.103 ms 62.908 ms 63.266 ms
13 64.69.91.245 (64.69.91.245) 63.094 ms !H 63.072 ms !H 63.173 ms !H
64.69.91.245 - Geo Information
IP Address 64.69.91.245
Host 64.69.91.245
Location CA CA, Canada
City Vancouver, BC v6b4n5
Organization Peer1 Internet Bandwidth & Server Co-Location Faci
ISP Peer 1 Network
AS Number AS13768
Latitude 49°25'00" North
Longitude 123°13'33" West
Distance 9281.29 km (5767.13 miles)
64.69.91.245 - Whois Information
OrgName: Peer 1 Network Inc.
OrgID: PER1
Address: 75 Broad Street
Address: 2nd Floor
City: New York
StateProv: NY
PostalCode: 10004
Country: US
NetRange: 64.69.64.0 - 64.69.95.255
CIDR: 64.69.64.0/19
NetName: PEER1-BLK-01
NetHandle: NET-64-69-64-0-1
Parent: NET-64-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.PEER1.NET
NameServer: NS2.PEER1.NET
Comment:
RegDate: 2000-04-12
Updated: 2007-08-29
RTechHandle: ZP55-ARIN
RTechName: Peer1 Network Inc.
RTechPhone: +1-604-683-7747
RTechEmail: net-admin#peer1.net
OrgAbuseHandle: NSA-ARIN
OrgAbuseName: Peer 1 Network AUP Enforcement
OrgAbusePhone: +1-604-484-2588
OrgAbuseEmail: abuse#peer1.net
OrgTechHandle: ZP55-ARIN
OrgTechName: Peer1 Network Inc.
OrgTechPhone: +1-604-683-7747
OrgTechEmail: net-admin#peer1.net
OrgName: Peer1 Internet Bandwidth & Server Co-Location Facilities
OrgID: PIBSCF
Address: 2100-555 W. hastings St.
City: Vancouver
StateProv: BC
PostalCode: V6B 4N5
Country: CA
NetRange: 64.69.91.240 - 64.69.91.255
CIDR: 64.69.91.240/28
NetName: PEER1-GVLANPRI-01
NetHandle: NET-64-69-91-240-1
Parent: NET-64-69-64-0-1
NetType: Reassigned
Comment:
RegDate: 2002-03-14
Updated: 2002-03-14
RTechHandle: MT1763-ARIN
RTechName: Teolis, Mark
RTechPhone: +1-604-683-7747
RTechEmail: net-admin#peer1.net
# ARIN WHOIS database, last updated 2009-04-06 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.
It occured to me that it may be more useful if I do a trace from my home computer, to fvringette.com rather than from some random computer which may actually be able to connect. Output of tracert:
1 <1 ms <1 ms <1 ms <snip>
2 24 ms 24 ms 23 ms 70.71.106.1
3 24 ms 24 ms 24 ms rd1bb-ge5-0-0-1.vc.shawcable.net [64.59.149.2]
4 25 ms 29 ms 29 ms rc2bb-tge0-15-0-0.vc.shawcable.net [66.163.69.137]
5 28 ms 30 ms 29 ms rc2wh-tge0-15-1-0.vc.shawcable.net [66.163.69.121]
6 25 ms 24 ms 24 ms 204.239.129.213
7 26 ms 29 ms 29 ms oc48.pos3-0.van-spenc-dis-1.peer1.net [216.187.89.250]
8 27 ms 29 ms 30 ms 64.69.91.245
9 * * * Request timed out.
10 * * * Request timed out.
After this all requests just keep timing out. It's the same IP, 64.69.91.245 that seems to be causing the problem... does this mean that I'm just unlucky and got a dead server that won't forward my request? I have no idea how these things work.
I can ping 64.69.91.245, but not telnet 64.69.91.245. It says 'connect failed', not 'connection refused'... I can't think of why it would fail for me, but no one else?
Try doing a traceroute for starters.
The "!H"s on line 13 mean that the host (64.69.91.245) is unreachable--but not all the time (see line 12). This looks at a glance to be further than your ISP, maybe at theirs.
Next step would be to figure out who that is...
My guess is either their hardware is faulty, or that they are blocking you inadvertently.
Some networks have the policies to block telnet connections/packets on the premise that they are unencrypted and only allow SSH.
Of course they may be blocking you for another reason.
Perhaps you should discuss it with them. It may be the case that they have blocked your IP address because you've been trying to telnet into their servers all day. :)