Re: AOL Servers Probing ???

From: N. Miller (anonymous_at_discussions.microsoft.com)
Date: 08/03/05 

Date: Tue, 2 Aug 2005 23:40:59 -0700

On Mon, 01 Aug 2005 11:30:07 -0400, !:?) wrote:

> Hi N. Miller,
>
> Speaking of AOL Proxies, I just got a Hit on Port 80 that seems a bit
> strange to me because in the Traceroute it went to a Dialup User first
> then to 2 Proxies where all the rest timed out after that.
>
> I have never seen it go through a Dialup user I'm not tracing in a
> Traceroute before on another IP.
>
> Rule "Default Block HTTP Port 80 TCP" blocked (compaq,http). Details:
> Inbound TCP connection
> Local address,service is (compaq,http)
> Remote address,service is (AC982843.ipt.aol.com,2426)
> Process name is "N/A"
>
> -- TRACEROUTE RESULTS --
> Tracing route to AC982843.ipt.aol.com [172.152.40.67]
> over a maximum of 30 hops:
>
> 1 163 ms 180 ms 163 ms ipt-rtcd16.dial.aol.com [152.163.5.112]
> 2 179 ms 171 ms 184 ms iptfarmd-rtc-ve3.proxy.aol.com
> [152.163.104.126]
> 3 209 ms 180 ms 156 ms ipt-rtcd10.proxy.aol.com [152.163.104.106]
> 4 * * * Request timed out.

First hop is your Netscape gateway. Is that what you mean by going to a
"Dialup User" first? Look here:

| 08/02/05 23:09:45 Slow traceroute AC982843.ipt.aol.com
| Trace AC982843.ipt.aol.com (172.152.40.67) ...
| 64.174.91.254 RTT: 69ms TTL:170 (adsl-64-174-91-254.dsl.sntc01.pacbell.net ok)
| 63.203.51.65 RTT: 54ms TTL:170 (dist1-vlan60.sntc01.pbi.net ok)
| 63.203.35.17 RTT: 55ms TTL:170 (bb1-g1-0.sntc01.pbi.net ok)
| 151.164.40.166 RTT: 110ms TTL:170 (bb2-p9-0.sntc01.sbcglobal.net ok)
| 151.164.241.193 RTT: 55ms TTL:170 (core2-p6-1.crscca.sbcglobal.net ok)
| 151.164.40.62 RTT: 68ms TTL:170 (bb1-p8-0.crscca.sbcglobal.net ok)
| 151.164.41.109 RTT: 82ms TTL:170 (ex2-p5-0.eqsjca.sbcglobal.net ok)
| 151.164.191.66 RTT: 69ms TTL:170 (ex1-p10-0.eqsjca.sbcglobal.net ok)
| 151.164.248.74 RTT: 69ms TTL:170 (asn1668-aol.eqsjca.sbcglobal.net ok)
| 66.185.150.80 RTT: 54ms TTL:170 (bb1-sjg-P0-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.153.58 RTT: 124ms TTL:170 (bb1-ash-P14-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.152.157 RTT: 137ms TTL:170 (bb1-rtc-P4-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.140.97 RTT: 124ms TTL:170 (pop1-rtc-P14-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.140.130 RTT: 137ms TTL:170 (wc1-rtc.atdn.net bogus rDNS: host not found [authoritative])
| 172.30.81.58 RTT: 137ms TTL:170 (No rDNS)
| 152.163.104.106 RTT: 206ms TTL:170 (ipt-rtcd10.proxy.aol.com ok)
| * * * failed

My first hop appears to be going to an SBC (PacBell) DSL user; but is it?
Really? Traceroute's first packet is sent to the router closest to you. In
this case, the pacbell.net DNS name indicates an SBC router facing my
Internet connection. My Netgear doesn't show in the first hop. Sometimes
traceroute will display your own IP address in the first hop; I see that
when I run a traceroute through my SMC Barricade:

| 08/02/05 23:17:56 Slow traceroute AC982843.ipt.aol.com
| Trace AC982843.ipt.aol.com (172.152.40.67) ...
| 192.168.102.3 RTT: 0ms TTL:170 (Mayuko ok)
| 209.244.43.94 RTT: 178ms TTL:170 (nas30.SanJose1.Level3.net ok)
| 63.215.15.3 RTT: 193ms TTL:170 (ge-7-0-2.core2.SanJose1.Level3.net ok)
| 4.68.123.161 RTT: 179ms TTL:170 (ae-1-56.bbr2.SanJose1.Level3.net ok)
| 209.247.10.130 RTT: 247ms TTL:170 (as-2-0.bbr2.Washington1.Level3.net ok)
| 4.68.121.162 RTT: 247ms TTL:170 (ge-4-0-0-56.gar1.Washington1.Level3.net ok)
| 66.185.139.85 RTT: 247ms TTL:170 (pop1-vie-P6-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.139.80 RTT: 439ms TTL:170 (bb1-vie-P0-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.152.160 RTT: 302ms TTL:170 (bb1-rtc-P5-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.140.97 RTT: 247ms TTL:170 (pop1-rtc-P14-0.atdn.net bogus rDNS: host not found [authoritative])
| 66.185.134.178 RTT: 247ms TTL:170 (wc1-rtc-S2-3-0.atdn.net bogus rDNS: host not found [authoritative])
| 172.30.81.58 RTT: 247ms TTL:170 (No rDNS)
| 152.163.104.106 RTT: 248ms TTL:170 (ipt-rtcd10.proxy.aol.com ok)
| * * * failed
| * * * failed
| * 152.163.104.106 RTT: 124ms TTL:170 (ipt-rtcd10.proxy.aol.com ok)
| * * * failed

I built a route through Level3, then dialed the modem on my SMC Barricade
7004BR for this trace; the first hop is the Barricade. Those AOL proxies
you are seeing are routers sending your packets on to the destination. Your
traceroute is staying within the AOL network. Both of mine start on
different networks (SBC dial-up POPs are through lines leased from Level3
in my region), but converge on the same peering point: 172.30.81.58. That
one has to be an AOL proxy, it is sending packets back to me with an RFC
1918 reserved IP address. I can't run a traceroute to that router.
Hmmm...oh, I forgot, my other network is in 172.29.0.0/16; I can't run a
tracroute out of that subnet into 172.30.0.0/16:

| 08/02/05 23:36:26 Slow traceroute 172.30.81.58
| Trace 172.30.81.58 ...
| 64.174.91.254 RTT: 42ms TTL:170 (adsl-64-174-91-254.dsl.sntc01.pacbell.net ok)
| 63.203.35.65 RTT: 41ms TTL:170 (dist1-vlan50.sntc01.pbi.net ok)
| * * * failed

In a Windows traceroute ICMP packets are sent with increasing hop counts.
First hop packet only goes to the router closest to your connection. Notice
that my last hop which resulted in return packets, in each of my traces, is
the same router as your last hop. AOL is a large network, and probably
doesn't want to waste time sending responses to ICMP packets, so there are
a lot of hops which say, "failed". My last successful trace on my dial-up
connection failed twice, then responded.

I really do not think that all of those "proxy.aol.com" names are proxies,
as you normally think of them. They are responding to the ICMP packets as
routers in all of the cases above.

Anyway, as much fun as I am having, traceroutes are not very useful for
trying to figure out what those probes you are seeing mean. You need to run
something like Ethereal, and capture those probe packets to get some idea
of what is happening. 

-- 
Norman
~Win dain a lotica, En vai tu ri, Si lo ta
~Fin dein a loluca, En dragu a sei lain
~Vi fa-ru les shutai am, En riga-lint

Relevant Pages

  • Re: icmp type 11 not go via nat POSTROUTING table
    ... everthing is working as it "should", there is no reason for a "ICMP ... I generated two test icmp packets ... This is how traceroute knows the IP of the ... If x.y.z.t is a private IP address, it cannot be tracerouted anyway, so ...
    (comp.os.linux.networking)
  • RE: Traceroute
    ... Plain IP packets, and actually anything that travels over IP or with an IP ... garbage after the IP header and play with the protocol field in the IP ... The best defense against tracerouting is an egress filter for the ICMP time ... for ICMP and UDP packets used by standard traceroute tools use are easily ...
    (Pen-Test)
  • Why some hosts in Internet not prefer to be traceroute-d ?
    ... i.e. not to send a TTL exceeded ICMP packet back to the host. ... like dropping TTL exceeded ICMP packets (dropping such packets in ... I used to traceroute in unprivileged user mode, ... What's the difference between a router and a endpoint host from ...
    (comp.os.linux.networking)
  • Re: PF + scrub + traceroute: ttl problem :(
    ... >like packets with ttl under 64, despite traceroute packets. ... >So the packets leaving my PC1 would have ttl 63 and i decided to use scrub ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Strange web site loading/DNS problem
    ... If the site sends out packets of 1500 bytes, and there is a router between ... When I can't get to the site, I get the typical traceroute: ... I have also changed the DNS server info in my router, ...
    (microsoft.public.windows.server.dns)