I require a specialist advisor. It seems you've encountered some unusual circumstances online.
I require a specialist advisor. It seems you've encountered some unusual circumstances online.
to reach the core of the matter, I’m going to admit I’m really puzzled at the moment. earlier this morning I was attempting advanced methods to get past Netflix’s U.S. content restriction. but let me be clear—this isn’t about simply circumventing the block. It’s a much larger issue. So here I was, experimenting with various tools like VPNs and my OpenNMS firewall. When I paused to check a Netflix domain name by chance, that’s when I first spotted this problem. At least I think it’s a bug. What else could possibly cause this? This is definitely something out of the ordinary. Somehow I managed to make my ISP send packets from the destination instead of my local machine. This bug forces every IP address I ping or traceroute to show a 1ms response time, no matter where it’s from—Japan, the UK, or the U.S. I tested a video game; before this, I always experienced around 60ms latency. The game felt smoother than usual, but still reported my original 60ms ping. I’ve attached screenshots of the ping tests from different sites and servers. If anyone wants a video explanation, I can make one. But I’m not sure how to explain this to someone else. It seems to be affecting only Cable Internet. When I switched to DSL, it worked again. Only Cable was impacted. And I could revert back and it functioned properly here—check out the YouTube demo.
I understand this means I've caused my ISP to believe packets come from the target location instead of my own device. Essentially, each ping test is seeing the destination as the source because your ISP now thinks it's where the traffic should go.
Check the screenshot closely—see where the tracert leads. The initial IP you see is likely a public one from Google. Your actual home IP should appear as your registered address, not that public number. Make sure it matches what you expect for your location.
I want to clarify the steps I took to bypass Netflix’s geo restrictions. My assessment (though I don’t claim to be a networking specialist) is that your router might be sending responses to every ping request on its own, possibly because of NAT or routing rules you’ve set. This could be intentional or accidental.
Note: Windows traceroute usually uses standard ICMP packets, which can be altered by default settings. You can also try using UDP instead of ICMP for a different result. I’m not certain about the exact method to switch it, but I’ll investigate further.
Thanks for your response. I value your input. It seems like a routing rule might be involved, though it's definitely not nat. The main adjustments I made in my firewall were related to DNS configurations. On the VPN side, I experimented with directing specific Netflix domains through my local DNS server rather than using the VPN itself. However, this didn't assist with unblocking. For routing, I enabled OpenVPN alongside my internet connection instead of placing it as an additional layer. This kept my IP address stable while still maintaining a connection to the VPN. I used the route-nopull feature. It's hard to spot any unusual changes in my settings that would affect how the VPN handles internet traffic.
It seems like local interference is mimicking ICMP traffic and faking your identity during pings. All traces suggest a single hop away with ping times under 1ms. This defies normal public internet behavior and likely originates from within your network. Check the route print command to confirm if the default path points to 127.0.0.1/localhost and redirects to a device on your PC.
There’s something intriguing about how the IP addresses behave—it seems like they’re being cached. Both the domains and the IPs appear to be storing data. I’m curious if my VPN configuration is influencing this caching process. Usually, 1.1.1.1 and unbound DNS only handle domain caching, but what if my VPN is also managing the IP address cache? That could explain the almost instant connection seen in tracert. I’m still figuring it out. Here are my VPN settings—don’t expect any standard defaults. Please add "route-nopull" to the client file if anyone decides to try this.
Great catch! I attempted to print the route and saw some unexpected details. The VPN server IP address is actually reaching through my local router gateway??!?