Dual WAN router creates loop

General network diagramHello,

I have an RV042 dual WAN router setup with two WAN connections, one is static and the other is dynamic.  I am trying to setup a VPN connection using the static IP, but I get no response.  When I Ping the static IP I get "TTL expired in transit", indicating some kind of loop.  Doing a tracert I get:

10    87 ms    86 ms    87 ms  cr1.n54ny.ip.att.net [12.122.80.226]
 11    89 ms    88 ms    92 ms  cr2.cgcil.ip.att.net [12.122.1.2]
 12    88 ms    90 ms    90 ms  cr1.cgcil.ip.att.net [12.122.2.53]
 13    88 ms    88 ms    86 ms  cr1.sffca.ip.att.net [12.122.4.121]
 14    87 ms    86 ms    91 ms  12.123.155.117
 15    88 ms    90 ms    88 ms  151.164.99.234
 16    88 ms    90 ms    88 ms  151.164.99.233
 17    88 ms    87 ms    87 ms  151.164.99.234
 18    90 ms    92 ms    89 ms  151.164.99.233
 19    88 ms    91 ms    87 ms  151.164.99.234
 20    90 ms    90 ms    87 ms  151.164.99.233
 21    89 ms    87 ms    87 ms  151.164.99.234
 22    87 ms    87 ms    87 ms  151.164.99.233
 23    87 ms    87 ms    87 ms  151.164.99.234
 24    89 ms    87 ms    87 ms  151.164.99.233
 25    86 ms    87 ms    87 ms  151.164.99.234
 26    87 ms    87 ms    91 ms  151.164.99.233
 27    88 ms    86 ms    87 ms  151.164.99.234
 28    91 ms    88 ms    86 ms  151.164.99.233
 29    88 ms    87 ms    87 ms  151.164.99.234
 30    96 ms    90 ms    87 ms  151.164.99.233

You can see the loop, it's not happening within my network, but external.

Any suggestions?

Thanks

lalto
laltobelliIT ConsultantAsked:
Who is Participating?
 
giltjrConnect With a Mentor Commented:
Not sure about filtering on protocols, but but it can block ICMP.  

If you enable the firewall on it and you have enabled the "Block WAN Request" option it will block ICMP, along with other inbound TCP requests.

http://www.cisco.com/en/US/docs/routers/csbr/rv0xx/administration/guide/rv0xx_AG_78-19576.pdf
0
 
giltjrCommented:
What device(s) have the IP address:

 151.164.99.233
 151.164.99.234

What does the routing table look like on those devices?
0
 
laltobelliIT ConsultantAuthor Commented:
Those devices are not on my network they are on the internet and are possibly owned by sbcglobal.net or ATT... via a couple of reverse IP lookups....
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
giltjrCommented:
Is AT&T your ISP?  If so you you need to contact AT&T.

If AT&T is not your ISP, you need to contact your ISP first and find out what is going on.
0
 
laltobelliIT ConsultantAuthor Commented:
No my ISP is Charter (where I am pinging from) and the ISP at the dual WAN router is Verizon.   The packets had long left the Charter servers, between hop 6 and 7.
0
 
giltjrCommented:
You will want to contact Verizon.  They are responsible for making sure AT&T has the correct routing entries for IP addresses they own.

Do you have the same problem when to a trace route to any/all of your IP addresses at the Verizon end?
0
 
Sandeep GuptaConsultantCommented:
15    88 ms    90 ms    88 ms  151.164.99.234
 16    88 ms    90 ms    88 ms  151.164.99.233

this is not a loop ...you see this repetedly because of provider ..sometime provider blocks trace & ping because of it when you do trace you won't see all the hops..and your outputs results in this way..

show  this output to your provider.
0
 
giltjrCommented:
guptasan26, I have to disagree with you. I have seen blocks and I have seen routing loops.  This looks like a routing loop to me.

If it were a simple block the traceroute to that hop would simply timeout and you would get no results for the hop that is blocking the ICMP.  

This is a case where it appears that 151.164.99.233 thinks the next hop should be 151.164.99.234 and thus forwards the request to it.  Then 151.164.99.234 thinks the next hop should be 151.164.99.233 and forwards it back.
0
 
Sandeep GuptaConsultantCommented:
what I mean from "not a loop" is that this is not a routing loop..it is the problem from provider and it apprears because providers blocks ping & trace sometimes.
0
 
giltjrCommented:
I understand what you are saying and I am saying I disagree with your assessment of the situation based on my experience.  Not saying your wrong, just base on what I have experienced I think it is something different.

Typical when ICMP is blocked you would see request timeout on the hop blocking ICMP.  Not bouncing it back and forth between two routers.  Especially two routers in the "middle" of the network.  On the edge between the ISP and the customer, maybe, but the two routers that are going back and forth are AT&T and the customers ISP is Verizon.

If what you are saying is true that would mean that either AT&T is blocking ICMP in the middle of their network, on the edge between them and Verizon, or Verizon is blocking ICMP in between them and AT&T.  Although that is possible, I personally have never seen it with AT&T or Verizon and I have used both of them as ISP's for close to 15 years now.

I have seen routing loops also and they look just like the output from  laltobelli post.  Now, I will say normally when I encounter a routing loop it is due to a link being down and routers are trying to find a way to get to the next hop.
0
 
laltobelliIT ConsultantAuthor Commented:
Ok, I tried this from a comcast account and got some interesting results.  The hops got to a Verizon server and then timed out.   Trace is below, I think it's time to call Verizon....

  5    10 ms    13 ms    11 ms  te-8-1-ur01.natick.ma.boston.comcast.net [68.87.144.197]
  6    16 ms    19 ms    15 ms  te-0-15-0-6-ar01.needham.ma.boston.comcast.net [68.85.69.94]
  7    38 ms    47 ms    47 ms  he-2-9-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.90.57]
  8    36 ms    37 ms    37 ms  pos-0-4-0-0-pe01.111eighthave.ny.ibone.comcast.net [68.86.85.22]
  9     *       45 ms     *     Vlan569.icore1.NTO-NewYork.as6453.net [209.58.26.137]
 10    38 ms    37 ms    37 ms  Vlan590.icore1.NTO-NewYork.as6453.net [209.58.26.94]
 11    52 ms    53 ms    47 ms  0.ge-4-0-0.BOS-BB-RTR2.ALTER.NET [152.63.20.110]
 12    46 ms    56 ms    46 ms  so-7-1-0-0.BOS-CORE-RTR2.verizon-gni.net [130.81.20.87]
 13    47 ms    47 ms    47 ms  A4-0-0-1711.BOS-DSL-RTR1.verizon-gni.net [130.81.7.22]
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
0
 
giltjrCommented:
That indicates that whatever hops are after 139.81.7.22 are blocking/dropping ICMP requests.

The name of the last router that responded implies that it is a DSL device, in Boston perhaps.  Could this be the last Verizon device before hitting your work place router/firewall?

Does the rotuer/firewall at your work place allow ICMP through?
0
 
laltobelliIT ConsultantAuthor Commented:
The router is an RV042, as I understand this model cannot filter on protocol.  I can ping the DHCP wan port without a problem.

This could be the last device before hitting my router, my router location is just outside of Boston.
0
 
laltobelliIT ConsultantAuthor Commented:
Hi giltjr,

You hit it.  Although I've used this router in the past and do not remember having to disable "Block WAN Request"

Anyways that appears to have resolved the issue and not only can I ping I can now access VPN>

Thanks,
laltobelli
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.