Join Log in
Score:-1
avatar Server

How can I tell (or prove) packets are being dropped by my router or my ISP?

se flag
Wayne Werner

I have a Hitron router that was provided by my ISP, and I have it configured to forward ports to devices on my LAN. I used to be able to access machines on the LAN from machines on the LAN by way of WAN IP of the router. For example

curl https://$(curl icanhazip.com)

would, in fact, make an HTTPS connection assuming I had a server listening behind the router.

Example:

client (192.168.0.42) ---> router (192.168.0.1) ---> dns for me.example.com, returns my WAN IP - same thing curl icanhazip.com returns. Example 203.0.113.42
client (source:192.168.0.42, dest:203.0.113.42:443) ---> nothing. Hangs forever. Or until timeout.

That used to work just fine.

Now I can only access the router via my gateway of 192.168.0.1, but that only goes directly to the router, not to any of the machines behind it. If I want to connect to a server on the LAN I have to use the IP directly.

But the weird thing is that if I'm not connected to my wifi - literally any other network - then I can connect to my external IP and the traffic is correctly forwarded.

client(source: 192.0.2.42, dest: 203.0.113.42:443) ---> router ---> web server (192.168.0.42)

Is it possible to figure out where my packets are getting dropped? I've looked around for any kind of information in the router itself, but no dice. I also reached out to my ISP on Twitter, but they also weren't much help. I've used ping & traceroute - either attempts to connect to the routers public IP fail. I've also spun up wireshark, and can see the ping packets go out and other traffic attempts, but I'm not familiar enough with it to know if there's a way to use it to say, "Ah yes, these packets are definitely getting dropped at X". I've also completely disabled the firewall at the router level, as well as mucked with any setting that looked remotely promising (even screwing up my router bad enough to have to do a hard reset on it, I think that was configuring the IP passthru).

Is it possible for me to verify that the packets are either getting dropped by my router, or getting dropped at the ISP level? And if so, how would I do that?

EDIT

For further fun and excitement, apparently this only applies to lower ports. I don't know what the exact range is, but it appears that higher ports still allow connections.

48
0 + 0
in flag
Robert
The common way to test if A or B causes something is to use them alone, so use a different router with your current ISP or a different ISP with your router and check if something changes.
0
Reply
vn flag
Mark Wagner
"I can access the router via my gateway of 192.168.0.1, but that only goes directly to the router, not to any of the machines behind it." What does that mean? Do you have some port forwarding configured?
1
Reply
Hagen von Eitzen avatar
cn flag
Hagen von Eitzen
It looks like you are attempting to come from the *inside*, NAT through the router, connect to an external port on that same router, and get portmapped *back in*? Such a scenario *may*drive the firewall settings insane ...
0
Reply
se flag
Wayne Werner
Ah, yes, missed including the port forwarding details. FWIW this is actually the only time in my life that I've *not* had this type of config work, though usually it's been... weird (like the client IP being reported as the router, instead of any of the real client IPs). This same port forwarding config *used* to work with this same ISP but a few months ago they did some network upgrades, including upgrading the router's firmware, which all coincides with the networking no longer working.
0
Reply
Score:2
avatar Server
us flag
Rob

It sounds like the problem is incorrectly configured hairpin NAT, which is something some SOHO routers automatically configure correctly and in others that requires specific routing and NAT rules.

https://serverfault.com/a/557776

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.