How a network works: TCP/IP, protocols and the layered design

If you understand a network in four layers, ninety percent of the problems you will see in an assessment already have an explanation. The rest don’t, but we will get there too.

The part that almost nobody explains well is why the stack is layered and not just a list of protocols. And the part that almost nobody measures is how big a packet is. These are the two things that make this subject worthwhile.

The commands and concepts in this article are there to help you understand how things work, not to get into places you are not authorised to be. A routing error on a production network is not an exercise: in Italy it is configured as aggravated computer intrusion (art. 615-ter of the criminal code). For authorised work, the reference is always the Vademecum dell’hacker.

What a network is, in one sentence

Two machines speaking a shared language. Everything else — cables, routers, protocols, DNS — is literally the infrastructure needed for the language to be common and for the message to arrive.

And there is one concept that has to be said straight away, because it is what holds everything together: the Internet is not a network. It is an agreement. There is no “centre” of the Internet, there is nobody routing packets for everyone. There are millions of autonomous networks that agreed to speak the same protocol and to pass packets to each other.

This has two immediate practical consequences:

• nobody can switch the Internet off from above;

• nobody knows the complete path of a packet, except the person looking at it at that moment.

The layered stack: why it is built that way

The reference model is OSI, seven layers, designed in the Seventies to be a theoretical framework. The one that actually works is TCP/IP, of which the Internet uses the four-layer version.

+-----------------------------------------------+
| 4. Applicazione    HTTP, DNS, TLS, SSH, SMTP  |
|    qui vive il tuo messaggio: "ciao"          |
+-----------------------------------------------+
| 3. Trasporto       TCP, UDP                   |
|    consegna affidabile, ordine, flusso        |
+-----------------------------------------------+
| 2. Internet        IPv4, IPv6, ICMP           |
|    indirizzamento e instradamento fra reti    |
+-----------------------------------------------+
| 1. Accesso rete    Ethernet, Wi-Fi, PPP, ARP  |
|    bit su cavo, MAC address                   |
+-----------------------------------------------+

The rule of the layer is simple and must be understood well: each layer talks only to its neighbour. Layer 3 knows nothing about layer 1, and does not need to know anything about it.

Here is why this is useful. When a video will not load:

• if the problem is at the physical level, no packets arrive;

• if it is at layer 2, the connectivity is there but conversations get confused;

• if it is at layer 3, the ping works towards the outside and not towards the inside;

• if it is at layer 4, the host is there but the port is closed;

• if it is at the top of layer 4, the connection is established and the problem is in the application.

Each layer rules out all the ones below it outright. This is the first thing to learn about the trade, and it applies to any fault: you work your way up from the bottom.

The journey of a packet, for real

This is the point where theory becomes useful. Imagine opening a web page. The packet containing the response crosses, in order, five layers on each of the two ends and about ten hops in between.

                IL TUO BROWSER (host A)
+-----------------------------------------------+
| 4  GET /index.html          (HTTP)            |
+-----------------------------------------------+
| 3  porta 54321 -> 443       (TCP, SYN)        |
+-----------------------------------------------+
| 2  192.168.1.10 -> 93.184.x.x  (IPv4)         |
+-----------------------------------------------+
| 1  aa:bb -> cc:dd           (Ethernet)        |
+-----------------------------------------------+
                      |
                 [ router ]  sfoglia l'IP, cambia l'header L2,
                      |     ma lascia intatto tutto il resto
                 [ router ]  idem, dieci volte
                      |
+-----------------------------------------------+
| 1  cc:dd -> aa:bb           (Ethernet)        |
+-----------------------------------------------+
| 2  93.184.x.x -> 172.217.x.x (IPv4)           |
+-----------------------------------------------+
| 3  porta 443 -> 54321       (TCP, ACK+data)   |
+-----------------------------------------------+
| 4  200 OK, <html>...        (HTTP)            |
+-----------------------------------------------+
                IL SERVER (host B)

The two things to notice in this diagram.

At the first hop the physical header disappears. The router receives an Ethernet frame, reads the destination IP, throws the Ethernet away and builds a new frame for the next network. At the second hop the destination IP has become a different one, and the destination port has become 443, no longer 54321.

But the TCP segment crosses the routers intact. The sender and the recipient never change, because they are at the ends. This is why the TCP connection is said to be “logical”: it exists between two endpoints, crosses the world, and no router in between takes part in it.

This is also the operational definition of NAT: a router that changes the ports is a NAT. It is the reason why port 54321 here is ephemeral and you will not remember it tomorrow.

The numbers: MTU, MSS and why videos freeze

Here is a thirty-second calculation worth more than a chapter of theory.

A standard Ethernet packet has a maximum payload size of 1500 bytes, and it is called the MTU. But inside those 1500 bytes the IP header and the TCP header have to fit, and the actual data is whatever is left over.

+---------------------------+--------+--------+------------------+
| dati utili (MSS)          | TCP 20 | IP 20  | payload max 1460 |
+---------------------------+--------+--------+------------------+
|<-------- MSS: 1460 byte ---------->|<------ 40 overhead ------>|

MSS = MTU - 20 (IP) - 20 (TCP) = 1500 - 40 = 1460 byte

On a 1500-byte packet, 40 bytes are headers and 1460 are data. It is not an academic detail: it is almost 3% of waste which, on a video, is a frozen frame.

And this is where a problem you keep seeing in production is born. Add a VPN tunnel and those 40 bytes become 100, but the packet keeps being built as if they were 40. Result: large packets do not get through, and the page loads but the images do not.

NESSUN TUNNEL                 CON VPN (WireGuard/IPSEC)
MTU 1500                      MTU 1500 (ma il tunnel ne usa ~60)
  dati 1460                     dati 1400
  +40 overhead                  +100 overhead  -> 1500+  = ROTTO
                               ...
  funziona                     funziona solo se il MSS viene
                               "clampato" a 1400

sintomo tipico: SSH si blocca appena apri un file grande

The remedy is called MSS clamping: during the handshake, the sender announces in the SYN packet how much data it wants to send, and if the client accepts, both sides adapt to the smaller value. It is one line of configuration and it solves a whole class of problems that at first sight have nothing to do with the VPN.

The values to know by heart:

And the command to actually measure it, if a packet does not get through:

# Linux: scopre l'MTU lungo il percorso
tracepath 93.184.216.34

# prova un pacchetto di 1472 byte con il bit "non frammentare"
# 1472 + 20 (IP) + 8 (ICMP) = 1500: la taglia esatta dell'MTU
ping -M do -s 1472 93.184.216.34

If that ping succeeds, the MTU is 1500. If it dies and a smaller one gets through, you have found your problem — and it is often a VPN.

TCP versus UDP: the choice that defines everything else

TCP and UDP are both at the transport layer, and they differ on a single question: does delivery have to be guaranteed?

TCP guarantees that the data arrives in order and complete, and it does so invisibly, with three mechanisms:

• the three-way handshake — SYN, SYN-ACK, ACK — which establishes the session and agrees the parameters;

• the sequence numbers, which let you know what is missing and request it again;

• the retransmission of whatever does not arrive within a timeout.

The price is that the overhead is not negotiable. Every packet carries 40 bytes of control, and before you can send even a single byte you have to wait for the round trip of the third segment. For a file transfer it is the right trade-off.

UDP does not guarantee anything. It sends and does not care. There is no handshake, there is no retransmission, the header is 8 bytes.

TCP: tre viaggi e poi i dati, ma ogni pacchetto torna garantito

  Client                                Server
    |                                     |
    |----------- SYN (seq=0) ------------>|  stabilisce
    |<------ SYN-ACK (ack=1) -------------|  e concorda
    |----------- ACK (seq=1) ------------>|  la sessione
    |                                     |
    |----------- dati (seq=1) ----------->|  ora si parla
    |<---------- dati (seq=1) ------------|  con garanzia

UDP: un viaggio e basta

  Client                                Server
    |----------- dati -------------------->|  vada o non vada,
    |                                      |  nessuno se ne cura
    |----------- dati -------------------->|

The practical consequence, which is almost the point of the article: security tools love UDP and hate TCP. A protocol that announces itself and then goes silent for three seconds is the most useful signal an attacker can give you. Signature-based IDS look for activity on the port, and by definition the activity is not there: they only have SYNs without completing the session. This is why the control channels of modern C2s run over UDP.

Ports, and why they are not a firewall

A port is a 16-bit number from 0 to 65535. The first 1024 are “well-known”, the others are registered or ephemeral.

The concept that needs to be made clear, because it is the most widespread misconception: an open port is not an access. It means that someone is accepting connections on that number. What happens afterwards depends on the protocol, on the credentials and on what is behind it.

This sentence I would put on the wall: *an open port does not mean an accessible port*. The first is a network condition, the second a security condition, and they are two completely different things. A service listening on 443 with admin/hacker2026 is an open port that is also accessible, but not because it is open.

And there is the opposite case, which is more interesting: a closed port is often better than a filtered one, because a closed port says “not here”, while a filtered one says “someone is there, but I am not telling you”. The difference between closed and filtered is information, and in an assessment it is information you pay to obtain.

How to investigate, in practice

Order matters, and it is the one from the Vademecum dell’hacker: from the bottom up, because each level rules out the ones below it.

# LIVELLO 1-2: esiste il collegamento? il ping risponde?
ping -c 3 93.184.216.34
ip addr show
ip route

# LIVELLO 2: l'MTU passa davvero? (non fidarti di ping da solo)
tracepath 93.184.216.34

# LIVELLO 3: che porte ci sono, e con quale stato?
# -sV scopre le versioni, -sC esegue gli script NSE
nmap -sV -sC -p- 192.168.1.10

# LIVELLO 4: la porta è aperta o filtrata?
# Le due risposte sono diverse e la differenza è un'informazione.
nc -zv 192.168.1.10 22

# LIVELLO 4-5: la risposta HTTP è quella che dice di essere?
curl -sI https://esempio.it
curl -s -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://esempio.it

# LIVELLO 2-3: le query DNS viaggiano davvero su UDP?
dig +short esempio.it

Four things you learn by doing, and that no theory gives you:

1. -p- scans all the ports, -p 22,80,443 only those. A full scan on a host with many services takes minutes.

2. The filtered state is not closed. The first says “there is something that does not respond”, the second says “there is nothing there”.

3. ssl_verify_result at zero is the only way to be sure that the certificate chain is valid. A browser that warns you and a script that carries on tell two different stories.

4. tracepath also tells you the PMTU, traceroute does not. For the problem of videos that freeze, the difference is everything.

The traps, said first

The four-layer model is a simplification. In reality there are seven levels and HTTP, for example, is not on the first layer but between the fourth and the fifth. Whoever taught you OSI at school taught you a teaching skeleton, not a description. It is useful as a reasoning tool and should be used as such.

An IP address does not identify a person and it is not a fixed identity. Behind a NAT there can be one user; a VPN changes the IP without moving anyone. Treating the IP as an identity is the mistake that leads you to block the wrong user — or, worse, to block nobody.

“Unreachable” is neither “yes” nor “no”. A timeout is a third state, and in an assessment it has three possible causes: firewall, host switched off, or broken path. Ping does not distinguish between them. tracepath and the router logs do.

MTU and DNS are the two problems nobody looks at. A video that freezes and a resolution that “sometimes” works are almost always one of the two. They are also the two cheapest to diagnose, and it takes you thirty seconds with the commands above.

The rule we use

The reasoning of CYBER ONIONS about protocols is short, and it is not about theory:

A protocol is a promise made to someone. TCP promises that the data arrives, UDP promises nothing, HTTPS promises that you are talking to whoever they claim to be.

Every time you read a header, what matters is not the number but the commitment that protocol takes on. This is why a TCP service discovered on a public port is a finding, and a discovered UDP service is often a more serious finding.

In one line

If only one thing remains from all of this: work your way up from the lowest level you can, rule out everything you have verified works, and repeat on what is left.