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 []
 11    89 ms    88 ms    92 ms  cr2.cgcil.ip.att.net []
 12    88 ms    90 ms    90 ms  cr1.cgcil.ip.att.net []
 13    88 ms    88 ms    86 ms  cr1.sffca.ip.att.net []
 14    87 ms    86 ms    91 ms
 15    88 ms    90 ms    88 ms
 16    88 ms    90 ms    88 ms
 17    88 ms    87 ms    87 ms
 18    90 ms    92 ms    89 ms
 19    88 ms    91 ms    87 ms
 20    90 ms    90 ms    87 ms
 21    89 ms    87 ms    87 ms
 22    87 ms    87 ms    87 ms
 23    87 ms    87 ms    87 ms
 24    89 ms    87 ms    87 ms
 25    86 ms    87 ms    87 ms
 26    87 ms    87 ms    91 ms
 27    88 ms    86 ms    87 ms
 28    91 ms    88 ms    86 ms
 29    88 ms    87 ms    87 ms
 30    96 ms    90 ms    87 ms

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

Any suggestions?


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.

What device(s) have the IP address:

What does the routing table look like on those devices?
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....
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

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.
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.
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?
Sandeep GuptaConsultantCommented:
15    88 ms    90 ms    88 ms
 16    88 ms    90 ms    88 ms

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.
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 thinks the next hop should be and thus forwards the request to it.  Then thinks the next hop should be and forwards it back.
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.
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.
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 []
  6    16 ms    19 ms    15 ms  te-0-15-0-6-ar01.needham.ma.boston.comcast.net []
  7    38 ms    47 ms    47 ms  he-2-9-0-0-cr01.newyork.ny.ibone.comcast.net []
  8    36 ms    37 ms    37 ms  pos-0-4-0-0-pe01.111eighthave.ny.ibone.comcast.net []
  9     *       45 ms     *     Vlan569.icore1.NTO-NewYork.as6453.net []
 10    38 ms    37 ms    37 ms  Vlan590.icore1.NTO-NewYork.as6453.net []
 11    52 ms    53 ms    47 ms  0.ge-4-0-0.BOS-BB-RTR2.ALTER.NET []
 12    46 ms    56 ms    46 ms  so-7-1-0-0.BOS-CORE-RTR2.verizon-gni.net []
 13    47 ms    47 ms    47 ms  A4-0-0-1711.BOS-DSL-RTR1.verizon-gni.net []
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
That indicates that whatever hops are after 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?
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.
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>

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.