Finding Packet Drop Location
on Blog
Yesterday I write a blog about finding outgoing and incoming latency data with uping.
While testing the program with different ports, I have an issue with port 53.
You know port 53 is used for DNS, maybe ISP or data center apply a rule for the safer network. Let’s try to look a path is anyone drops my packet. I execute traceroute command to the server with port 53.
Seems like a no problem but for a now.
Does the packet arrive at the server? To ensure, I inspect my server traffic with tcpdump. 
The packets are arrived into the server and responded without any error.
So I also tested in different Source IP which is announced in UK (in real, Ip is physically located in Marmaris). It does not have any issue, it means port 53 is not closed for everyone in my server.
Where is My Packet?
We see the packet in tcpdump, so my packets drop at between server to the client which is an incoming path for client.
Let’s look at it.
It seems like has a problem. In normal, the packet will be arriving 18th hop but in this time it does not arrive. Here are other packets.
17th hop is my home router, so the problem is happening at 15th or 16th hop.
Here is full route path, I also draw route path on maps and added as an image beginning of this post.
> Istanbul (Gayrettepe Turknet) > Sofia (Cogent) > Belgrade (Cogent) > Vienna (Cogent) > Munich (Cogent) > Frankfurt (Cogent) > Amsterdam (Cogent) >
client Server
< Istanbul (Gayrettepe Turknet) < Istanbul (Acibadem TurkTelekom) < Frankfurt (TurkTelekom) < Level3 (Frankfurt) < Amsterdam <
But WHY?
Port 53 is used for DNS and Port 53 is a sweet port for non protected servers to use as reflection attacks. 15th or 16th hop is my Service provider and they might apply a white list for port 53.
Let’s control this idea.
I temporally run socat for forwarding Port 53 is to common Public DNS server on the server-side.
docker run -it --rm --network host ahmetozer/cna socat UDP4-RECVFROM:53,fork UDP4-SENDTO:1.1.1.1:53
On the client side, I execute nslookup for testing.
$ nslookup example.com server
Server: research1.sv.local
Address: research1.sv.local#53
Non-authoritative answer:
Name: google.com
Address: 216.58.214.14
Name: google.com
Address: 2a00:1450:400e:804::200e
So what happened my other packets?
If the port sensitive for data it means very great firewall between me and server (16th hop) to check is it real DNS question or all packets forwarded to some proxy.
It is another post and I will write in this week.
I hope you liked this blog. If so don’t forget to share, stay safe and see you next blog.