No longer able to trace a route to my Sonic-connected home LAN from outside

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
4 posts Page 1 of 1
by scubbo » Thu Mar 04, 2021 10:17 am
Hi folks,

See this SuperUser question for more detail. I recently noticed that external machines weren't able to trace a route to my home LAN's IP - either from my own work's VPN, or from a friend's external machine. Has anything changed in Sonic's Berkeley setup that might be causing this? I still have perfectly fine internet connectivity _from_ my home - but the rest of the Internet doesn't seem to be able to connect _to_ it.
by lasevich » Tue Mar 09, 2021 11:02 pm
I am going to assume you meant traceroute to your WAN IP and not your inside/LAN IPs(that would never work). Traceroute uses a different protocol (ICMP) from most connections (usually TCP/UDP) and it can sometimes be blocked along the route under guise of security. There are other tools that can perform trace using TCP protocol(though responses are still ICMP, so some of the same issues may apply), you may need to have something listening on your side.

In any case, successful traceroute does not imply you can actually connect, and lack of it does not imply lack of connectivity - so it's not really all that important/useful to end-users...
by utkoleg » Fri Nov 19, 2021 3:26 pm
Hey scubbo, seems like you are not alone, I also noticed ICMPs and other connections to my IP are now blocked (also Berkeley resident).

I wonder if we could get a reply from Sonic Infra on this.
by tomoc » Mon Dec 06, 2021 11:04 am
Sonic should not be blocking ICMP traffic towards any customer addresses (except for brief periods during DDoS mitigation). The traceroute in the superuser post shows traffic dying before (or right after) leaving the private IP space on the connection (10.x.x.x/8). That looks to be VPN/far end behavior and unrelated to Sonic's network. There are circumstances where some of the Sonic routers along the path won't respond in the traceroute, but they just show up as "* * *"s in the path.

Please provide some specifics and traceroutes if this still appears to be an issue.

My traceroute to scubbo appears normal, although the attached device itself does not appear to be responding with TTL exceeded (acceptable residential gateway behavior). Below that, you'll see a successful ping to the WAN address.

# traceroute 192.184.132.x
traceroute to 192.184.132.x (192.184.132.x), 30 hops max, 60 byte packets
1 204-228-149-157.xmission.com (204.228.149.157) 0.927 ms 0.866 ms 0.868 ms
2 br2.core.xmission.net (166.70.1.22) 0.374 ms 0.327 ms 0.322 ms
3 10gigabitethernet6-14.core1.slc1.he.net (65.19.138.173) 0.317 ms 0.294 ms 0.363 ms
4 100ge4-2.core1.sjc2.he.net (184.105.223.213) 14.726 ms 14.800 ms 16.408 ms
5 0.xe-5-0-0.gw.equinix-sj.sonic.net (206.223.116.35) 16.737 ms 14.884 ms 16.692 ms
6 100.ae1.cr1.equinix-sj.sonic.net (75.101.33.186) 208.564 ms 208.440 ms 208.419 ms
7 * * *
8 0.ae2.cr2.hywrca01.sonic.net (70.36.205.66) 34.069 ms 41.048 ms 40.277 ms
9 0.ae0.cr2.albyca11.sonic.net (198.27.244.106) 37.009 ms 31.956 ms 31.894 ms
10 305.ae0.bras3.albyca11.sonic.net (157.131.209.156) 19.657 ms 19.640 ms 17.995 ms
11 * * *

# ping -c 5 192.184.132.x
PING 192.184.132.x (192.184.132.x) 56(84) bytes of data.
64 bytes from 192.184.132.x: icmp_seq=1 ttl=54 time=21.2 ms
64 bytes from 192.184.132.x: icmp_seq=2 ttl=54 time=20.3 ms
64 bytes from 192.184.132.x: icmp_seq=3 ttl=54 time=20.9 ms
64 bytes from 192.184.132.x: icmp_seq=4 ttl=54 time=20.2 ms
64 bytes from 192.184.132.x: icmp_seq=5 ttl=54 time=20.4 ms

--- 192.184.132.x ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4025ms
rtt min/avg/max/mdev = 20.237/20.652/21.282/0.440 ms
Tomoc
Sonic NOC
4 posts Page 1 of 1

Who is online

In total there are 7 users online :: 1 registered, 0 hidden and 6 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: Google [Bot] and 6 guests