1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

TimeWarner is routing 192.168.15.x - 254 in Maine

Discussion in 'Networking Issues' started by fossicker, Jun 11, 2008.

  1. fossicker

    fossicker Networkin' Nut Member

    If you've got TW, try to ping or tracert 192.168.15.1 behind NAT or with the cable modem's public IP address. I'm getting outside routes for a private IP address! Even the TW tech I talked to last night was getting a route from his computer when tracert'ing 192.168.15.1, so it's not just me...and even Level 3 techs were baffled.


    I've got TW Business Class, a dynamic public IP address via cable modem assigned to a WRT54GL running dd-wrt. Standard stuff, I'm NAT'ing 192.168.x.x and I assign static IP addresses to my network nodes, with a subnet mask of 255.255.255.0 and the gateway 192.168.1.1 (dd-wrt). DHCP is running in dd-wrt but is only there to provide 192.168.1.100 or 101 to ad-hoc devices, like my Toshiba E750 handheld. My static IP addresses are in 192.168.1.2 - 99

    According to RFC 1918, private IP addresses are /NEVER/ supposed to be routed to Internet routers. But for addresses in 192.168.15.1 - 254 they ARE being tossed past my WRT54GL as follows:

    I just got my Vonage package yesterday. The admin page for the Motorola VT2142 is supposed to be 192.168.15.1 but that page doesn't load in FireFox or IE. So I dropped into the XP command prompt and ping'ed 192.168.15.1 -- and to my surprise, I was routed out past my WRT54GL:

    Pinging 192.168.15.1 with 32 bytes of data:

    Reply from 204.210.64.22: TTL expired in transit.
    Reply from 204.210.64.22: TTL expired in transit.
    Reply from 204.210.64.22: TTL expired in transit.
    Reply from 204.210.64.22: TTL expired in transit.

    Ping statistics for 192.168.15.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


    Then I tried a tracert to 192.168.15.1

    Tracing route to 192.168.15.1 over a maximum of 30 hops

    1 2 ms 2 ms 1 ms 192.168.1.1
    2 8 ms 9 ms 9 ms 10.229.32.1
    3 11 ms 11 ms 10 ms gig0-1.ptldmeell-ubr01.nyroc.rr.com [204.210.64.
    225]
    4 14 ms 15 ms 14 ms gig1-1.ptldmebck-rtr01.nyroc.rr.com [204.210.64.
    209]
    5 16 ms 15 ms 17 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    6 21 ms 15 ms 16 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    7 19 ms 18 ms 18 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    8 19 ms 18 ms 18 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    9 22 ms 19 ms 19 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    10 20 ms 24 ms 19 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    11 23 ms 22 ms 23 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    12 * * 24 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    13 25 ms 25 ms 27 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    14 * 24 ms 25 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    15 28 ms 29 ms 28 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    16 29 ms 28 ms 28 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    17 30 ms 29 ms 29 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    18 30 ms 30 ms 31 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    19 32 ms 32 ms 31 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    20 32 ms 33 ms 32 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    21 34 ms 34 ms 35 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    22 34 ms * 37 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    23 37 ms 37 ms 38 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    24 39 ms 37 ms 37 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    25 41 ms 40 ms 40 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    26 39 ms * * ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    27 42 ms 42 ms 44 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    28 * 42 ms 41 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]
    29 43 ms 43 ms 44 ms gig6-1-0.ptldmeptl-rtr02.nyroc.rr.com [204.210.6
    4.21]
    30 45 ms 43 ms 43 ms ge-0-1-0.ptldmeags-rtr01.nyroc.rr.com [204.210.6
    4.22]

    Trace complete.


    Then I used dd-wrt "Static DHCP" AKA "DHCP Reservations" for the Vonage box to assign 192.168.1.79 via MAC address instead of 192.168.15.1, and that worked so that my Vonage box picked up 192.168.1.79.

    So two things:

    1) My Vonage box is apparently broken, I can't get to the VT2142 web admin page no matter what I try. It's working with DHCP reservations from dd-wrt, I get Vonage dial tone, but I want to fiddle about in the VT2142 admin page. No amount of unplugging/resetting/fiddling
    gets a response from the VT2142 (blue OR yellow RJ45). I can't put the VT2142 ahead of dd-wrt because the yellow RJ45 jack is broken - no link light. So I guess I'll get a Vonage RMA and try a replacement.

    2) Why in the hell is TW routing a private IP address range? Any other address in 192.168.x.x is UNROUTEABLE, except for 192.168.15.1 - 254.
    The tracert response looks like a TCP routing loop that dies eventually because of the TCP timeout...
  2. fossicker

    fossicker Networkin' Nut Member

    I side-graded my wrt54gl to Tomato from dd-wrt, and the situation is the same. Also I discovered that the tracert to 192.168.15.1 continues to bounce between 204.210.64.21 and 22 for as long as I have set the max hops as a tracert parameter, e.g.

    tracert 192.168.15.1 -h 100 (max hops is 255)
    results in 100 hops between 204.210.64.21 and 22
    I suspect the hopping would go on for as long as I have set the max hops parameter in tracert (tracert -h 1000 give an error
    Am I crazy or does this seem like an RFC compliance issue?
  3. HennieM

    HennieM Network Guru Member

    No, it's probably just a routing screw-up somewhere. To my mind, there is no such thing as RFC 1918 compliance, there is just a general consensus not to route private IPs.

    I guess the key is this from RFC1918:
    I would have a look at the parameters that get dynamically assigned to your internet connection device. Your ISP probably have a dynamic route assignment in there which say 192.168.15.0/24 should go out the internet/WAN port. This is the mistake IMO.

    FYI, many ISPs use private IPs in their devices, mainly for 2 purposes:
    1) The private IP gets assigned as a secondary IP, with special privileges, on a certain device to facilitate maintenance and the likes.
    2) In a route from my Asia link to my US link (or something similar) like
    Code:
                           ___________My stuff_______________
                          |                                  |
    --Asia internet link--|-Router1---private link---Router2-|--US internet link--
                          | 192.168.1.1           192.168.1.2|
                           ----------------------------------
    
    so a packet coming from Asia en route to the US passes through the private link. This private link however, is only known to the 2 routers in question, and both of them should be configured to not let 192.168.0.0/16 "out of My stuff". It sounds like your ISP went wrong with the "letting out" part somewhere.

Share This Page