0

I'm facing a weird problem at home and have been trying to find the root cause of the following problem, and solve it. I have a Motorola router at home and its public IP is 104.32.170.156 (taken from www.whatismyip.com). The problem is that this public IP cannot be reached from outside my network via ping / traceroute utilities. I have a remote server which has an IP 204.57.3.217, and I'm able to reach this one from my local machine - all outgoing ICMP Ping and traceroutes from my network succeed.

As a side note, my internet works just fine. I am also able to SSH from and from the remote server to my machine and vice-versa. But I'm wondering why ICMP ping and/or traceroute wouldn't be successful to my network.

Please note: I turned off firewall both on my laptop and on the router/modem I'm connected to, and rebooted the Router after applying this change. I had not changed any other setting in the Router - have left them to default, as everything seemed fine to me.

Given that the firewall has been disabled, I believe the Router wouldn't filter ICMP messages any more.

Traceroute from my local machine (104.32.170.156) to remote server (204.57.3.217):

traceroute to 204.57.3.217 (204.57.3.217), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 23.405 ms 0.993 ms 1.166 ms
2 cpe-104-32-160-1.socal.res.rr.com (104.32.160.1) 9.642 ms 10.100 ms 8.505 ms
3 tge0-9-0-18.lsajcatj01h.socal.rr.com (76.167.30.177) 10.003 ms 11.092 ms 11.227 ms
4 agg22.lsaicaev01r.socal.rr.com (72.129.18.86) 12.994 ms 16.208 ms 11.410 ms
5 agg26.lsancarc01r.socal.rr.com (72.129.17.0) 15.365 ms 14.306 ms 19.079 ms
6 bu-ether16.lsancarc0yw-bcr00.tbone.rr.com (66.109.6.102) 15.035 ms 15.378 ms 18.354 ms
7 0.ae0.pr1.lax00.tbone.rr.com (107.14.17.248) 13.144 ms 0.ae1.pr1.lax00.tbone.rr.com (107.14.17.250) 12.562 ms 0.ae0.pr1.lax00.tbone.rr.com (107.14.17.248) 12.725 ms
8  v217.core1.lax2.he.net (216.218.223.233)  70.217 ms  57.818 ms  49.854 ms
9  216.218.223.28 (216.218.223.28)  13.922 ms
            216.218.223.26 (216.218.223.26)  17.041 ms  27.590 ms
10  130.152.182.83 (130.152.182.83)  16.196 ms  16.301 ms  14.347 ms 
11  fw6-rtr-border-cal.usc.edu (128.125.251.227)  13.323 ms  14.346 ms 
        13.355 ms 
12  fw6-rtr-border-cal.usc.edu (128.125.251.227)  13.990 ms  15.406 ms  14.409 ms 
13  rtr6-fw6.usc.edu (128.125.255.146)  14.413 ms  15.327 ms  14.156 ms 
14  rtr30-v255.usc.edu (128.125.251.148)  44.621 ms  44.625 ms
    catarina.usc.edu (204.57.0.1)  20.688 ms 
15  204.57.3.217 (204.57.3.217)  15.020 ms  14.390 ms  14.275 ms

Traceroute from remote server (204.57.3.217) to my local machine (104.32.170.156) fails:

traceroute -I 104.32.170.156

traceroute to 104.32.170.156 (104.32.170.156), 30 hops max, 60 byte packets
 1  204.57.3.254 (204.57.3.254)  5.063 ms  5.299 ms  5.453 ms
 2  rumi.usc.edu (204.57.0.2)  0.501 ms  0.610 ms  0.672 ms
 3  v255-gw-6.usc.edu (128.125.251.149)  0.429 ms  0.500 ms  0.587 ms
 4  fw6-rtr6.usc.edu (128.125.255.147)  0.222 ms  0.215 ms  0.180 ms
 5  rtr-border-cal-fw6.usc.edu (128.125.251.226)  0.705 ms  0.732 ms  0.782 ms
 6  ln-usc1-pwaveusc2042.ln.net (130.152.182.81)  1.020 ms  0.816 ms  0.825 ms
 7  d3-0-1-2.a05.nycmny01.us.ra.gin.ntt.net (165.254.21.241)  2.340 ms  2.500 ms  2.585 ms
 8  ix-5-0.tcore2.LVW-Los-Angeles.as6453.net (64.86.252.133)  10.706 ms  10.720 ms  10.731 ms
 9  64.86.252.130 (64.86.252.130)  0.629 ms  0.629 ms  0.617 ms
10  bu-ether21.lsancarc0yw-bcr00.tbone.rr.com (107.14.19.139)  4.081 ms  3.811 ms  3.804 ms
11  ae3.lsanca4-rtr1.socal.rr.com (66.109.6.103)  6.551 ms  6.366 ms  6.274 ms
12  agg1.lsaicaev01r.socal.rr.com (72.129.17.1)  7.505 ms  6.291 ms  6.006 ms
13  agg1.lsajcatj01h.socal.rr.com (72.129.18.87)  5.790 ms  5.705 ms  5.727 ms
14  tge7-1.lsajcatj02m.socal.rr.com (76.167.30.190)  6.308 ms  6.330 ms  6.373 ms
15  * * *
16  * * *
17  * * *

Looking at both the traceroute outputs, it looks like traceroute to my public IP from the remote server (second case) breaks at / before my network.

I also ran tcpdump to capture all ICMP messages from my local machine to my IP, but I don't see any.

Does anyone have an idea why this is happening / how to resolve this? Thanks!

15
  • One possibility is that some routers have additional setting to enable / disable 'Respond to ping requests at WAN port' it's a kind of a security feature. Your router may have such a setting and that may be default set not to respond to ping requests.
    – patkim
    Sep 25, 2015 at 16:34
  • Another possiblilty is that rr have blocked ping at some routers in their network. Note your 2nd trace does not reach cpe-104-32-160-1.socal.res.rr.com (the 2nd hop in your first trace) and cpe is an abbreviation for Customer Premises Equipment. For security reasons, some routers do not allow you to Ping them (ICMP is disabled due to a firewall or other security measures), and the block may affect Traceroute, Pathping and Ping measurements but not actual server connections.
    – DavidPostill
    Sep 25, 2015 at 16:58
  • Thanks for the replies! @DavidPostill, I traceroute from the remote server to the 2nd hop (104.32.160.1) and the hop after that, and it works! And it looks like the incoming path to my IP is taking a slightly different route, which I think is fine. But the point here is if I am able to send ICMP packets from my network to another network, the reverse should also certainly work; and if it doesn't, I strongly suspect the problem lies at either ends' next hop routers. Otherwise, my ping wouldn't have succeeded in the first place, right? (if other intermediate router(s) would have filtered ICMP) Sep 25, 2015 at 17:37
  • @pat2015, Interesting! I don't see a really good point in vendors doing that (unless it's someone like Microsoft). Even if they would like to have that security feature included in, it has to be left to the user to configure it at the application level. In any case, I will look into it. Sep 25, 2015 at 17:45
  • You are correct that the reverse path can be different to the normal path, but I would expect in either case it go through 104.32.160.1 is as it unlikely that your router is connected to two different devices. In this case I think that the CPE is responding to direct ICMP, passing outbound ICMP but blocking onward transit of inbound ICMP. By the way, that stops the a ping of death affecting your internet connection ;)
    – DavidPostill
    Sep 25, 2015 at 17:46

0

You must log in to answer this question.

Browse other questions tagged .