The Holy Trinity of Networking

I am speed — Lighting McQueen

When people talk about slow nmap scans (during OSCP exam) or inability to get reverse shells, they often blame their “Internet speed.” But that’s a misconception. In reality, there are three main factors that influence how fast your scans can be. Internet speed is not the biggest culprit. Let me elaborate.

Behind almost every network issue in an OSCP lab (or exam) hides what I call the Holy Trinity of Networking: Speed, Latency, and MTU. Understanding these three will not only save your scans but also your sanity during the exam.

Let’s explain in more detail each and how they can affect or not, your nmap scans and overall exam experience. A good understanding of these three concepts will also help you in real life engagements.

Internet Speed

This is measure in Mbps. Speed tells you how much data you can move per second. Most people blame it when things go wrong. But in the OSCP environment, speed is rarely the problem. nmap packets are small. You are not streaming a Netflix movie. So even if your connection is fast, it will not make your scans magically shorter.

Network Latency

Latency is the second player, and the one that hurts the most. When your VPN tunnel adds extra distance between your Kali box and the lab network, every packet takes a little longer to make the round trip. Those few milliseconds multiply across thousands of packets. That is why sometimes your scan feels stuck at 2%. If you are using Wi-Fi, things get even worse. Switch to Ethernet and the difference becomes night and day. I learned this the hard way halfway through my OSCP lab time. I ended hiring a guy that “drop” a cable from the place where my home router is to my home office. Now both of my laptops (work and personal) use Ethernet, not 5G WiFi.

The Infamous MTU

A lot has been discussed on Offsec Discord about this. Even Offsec has an article about it, which I do recommend reading:

https://help.offsec.com/hc/en-us/articles/360046293832-Common-VPN-and-Machine-VM-Issues#general-vpn-tips

Sometimes is not the payload. Is not you. It’s your current MTU value. Check it out today, especially if you are not in US.

The Maximum Transmission Unit defines how large a packet can be before it gets split. The VPN overhead often lowers that limit without you realizing it. If a packet exceeds that value, it fragments. Fragmentation slows down scans, and sometimes breaks reverse shells completely. I once lost a perfect foothold because the shell never made it back to Kali. It was not my payload. It was MTU.

Got it now?

Ok, let’s test our new knowledge. Here’s the million-dollar question. If your nmap scan feels slow or your reverse shell refuses to connect, what should you check first based on everything we just talked about?

The right answer is MTU . Then Latency. Speed is the last thing you should worry about.

Speed gives you capacity. Latency decides how responsive your actions feel. MTU determines if your packets even make it back to you.

Possible fixes

Unfortunately, a complete fix of these network issues are not easy. In occasions , only hardware or physical proximity truly resolves the problem. But there are a few tricks.

If your issue is MTU, I suggest reading a previous blog I made :

[embed]Why MTU values can make your payload fail during your OSCP exam. Rerverse Shell — AI generatedduckwrites.medium.com

If you are not a US student and you’re on WiFi , I strongly suggest using an Ethernet. Connect your laptop to the “Modem” via physical cable, at least, while taking the OSCP exam. Doing this, will greatly reduce your network latency. Ideally, Offsec should have a VPN offering in Asia or Europe, similar to HTB. That’s probably coming in 2026. I got the feeling.

Next time your Nmap scan drags on or your reverse shell fails to connect, don’t worry. Take a step back and remember the Holy Trinity. The problem may not be your syntax or your payload , but the lack of an Ethernet cable or a possible MTU misconfiguration . Network speed is the last thing you should check, for our particular issue at least.