I built a VPN in C that communicates directly with the Linux kernel. I did it in one night, at 19 years old, without having attended computer science high schools, without university, without courses. With the help of a chatbot and the desire to understand how things really work.
The project is called c-tun-vpn and it’s on GitHub. It’s not a commercial VPN. It doesn’t have robust authentication, it doesn’t have multi-peer management, it doesn’t have all the features needed to actually use it in production. But it works. It creates an encrypted tunnel between two machines, routes all traffic through a gateway, masks the external IP. It does what a VPN should do.
And above all: I understood it. Every line of code. Every command. Every packet that enters and exits the kernel.
Why I did it
I knew that on Linux there are simpler ways to make a VPN. OpenVPN, WireGuard, ready-made tools that work better than my experiment. But I didn’t want a ready-made tool. I wanted to get my hands on the kernel. I wanted to understand what happens when an IP packet enters a virtual network interface. I wanted to see with my own eyes how Linux handles routing, NAT, forwarding. I wanted to learn low-level programming.
And I wanted to prove something to myself: that you don’t need degrees, diplomas, years of university to build something complex. You need curiosity, method and the ability not to give up when things don’t work on the first try.
How it works (technical summary)
The architecture is this:
Host A (Client) creates a virtual interface tun0 with IP 10.0.0.1. It intercepts IP packets generated by the operating system, encrypts them in user-space through the C program and encapsulates them inside UDP datagrams addressed to port 9000 of Host B.
Host B (Gateway) receives UDP packets on port 9000, decrypts them through its own C program and injects them into its tun0 interface (10.0.0.2). Thanks to IPv4 Forwarding enablement and iptables rules (NAT/MASQUERADE), Host B forwards packets to the Internet and sends the encrypted response back to Host A.
MTU & MSS Clamping management: to prevent UDP/IP encapsulation from fragmenting packets, I set the MTU of the tun0 interface to 1400 bytes and applied TCP MSS clamping.
Automation: I wrote Bash wrappers with OS signal management (trap SIGINT SIGTERM) to start the infrastructure and perform atomic cleanup of routing tables at shutdown.
The night
I did it in one night. But it wasn’t a quiet night.
There were moments when ping worked but the browser didn’t. Moments when the browser seemed to work but the IP that came out was the wrong one. Moments when tcpdump showed me encrypted packets on the Wi-Fi card (victory!) but then the traffic didn’t come back.
I debugged with ip route, ip a, tcpdump, traceroute. I checked every routing table, every iptables rule, every kernel flag. I verified that the real traffic was actually encrypted by capturing UDP packets on the physical Wi-Fi card and checking that they were only incomprehensible binary payload — zero cleartext bytes.
The real moment of pride wasn’t when the first ping succeeded. It was when I opened the browser, went to a site that shows your public IP, and saw the VPN gateway IP. Not my home router’s. My VPN’s. The tunnel really worked.
The role of AI
I used Gemini (just the chatbot, not complex tools or agents) to help me. I asked it how /dev/net/tun works, how to open a file descriptor in C, how to calculate MTU overhead, how to write iptables rules for NAT.
I didn’t copy and paste random code. I asked, I understood, I wrote, I tested. When something didn’t work, I debugged it myself. I configured the two physical Arch Linux machines on my local network myself. I executed every command myself. I interpreted every error myself.
After finishing the project, I asked ChatGPT and Claude to evaluate me. I gave them the complete report of what I had done, how I had used AI, what I understood and what I didn’t.
The evaluation they gave me:
Overall score: 83/100
“What strikes me is not so much the VPN itself. A minimal TUN+UDP VPN is a project that can also be found in advanced tutorials. The interesting part is that you decided to go through practically the entire chain: C systems programming, TUN interfaces, UDP sockets, Linux routing, forwarding, NAT, MTU/MSS, debugging with tcpdump, Bash scripting, project packaging. Many people learn these topics separately. You had to connect them into a working system.”
And then:
“Compared to an average undergraduate student: definitely above. Many students know TCP, UDP and routing theoretically, but have never created a TUN or touched iptables.”
“Compared to an average graduate: probably above average. Not because the project is huge, but because it’s very hands-on.”
“Compared to a junior Linux/networking: I’d say perfectly compatible. If I saw this project in the portfolio of a junior candidate oriented to systems, networks or cybersecurity, I wouldn’t be surprised at all.”
What I really learned
I learned that university teaches theory, not practice. And that there are things that aren’t taught at all, not even in master’s courses in networking or operating systems.
I learned that real experience is not measured in years but in working things. You can have 30 years of experience and never have touched Linux. You can sell VPN services by buying preconfigured dashboards on Windows and never have written a line of code that talks to the kernel.
I learned that those who graduate often feel superior to those who learned on their own, but superiority doesn’t exist if on one side there are concrete projects and on the other only theory.
I learned that AI doesn’t make you lazy if you use it well. It makes you faster. It allows you to focus on real problems instead of wasting hours looking for fragmented documentation. But it doesn’t save you if you don’t understand what you’re doing. I did the debugging. I did the machine configuration. I built the understanding of the system.
Why I’m telling this
I’m telling this because I want someone reading this article — maybe a guy like me, in a town like mine, without access to “right” schools or “important” universities — to understand that you don’t need credentials to build complex things. You need desire. You need method. You need the ability not to give up when the browser doesn’t work, when ping fails, when tcpdump shows you packets you don’t understand.
I’m telling this because there’s a strong prejudice in the technical job market: those without diplomas or degrees are treated as if they have no right to speak. As if experience were measured only in years or titles, not in real understanding.
I’ve seen people selling technical services without ever having touched the code underneath. I’ve seen experts working on preconfigured dashboards without knowing what happens when you press a button. I’ve seen seniority used as an argument to close discussions instead of opening them.
I’m not saying my projects are worth more than their experience. I’m saying that experience without understanding is not experience — it’s just time passed. And that time passed doesn’t automatically give you the right to treat those who are learning as if they don’t matter.
What’s missing from the project (and I know it)
It’s not a production-ready VPN. Missing:
- Robust peer authentication
- Secure key management
- Replay protection
- AEAD (Authenticated Encryption with Associated Data)
- Multi-client support
- IPv6 support
- Resilience and hardening
I know. And if someone asked me “are you ready to implement these features?”, the honest answer is: not yet. But I know where to start. I know what problems I would face. I know how to look for solutions.
And this difference — between those who know they don’t know and those who think they know everything — is the only experience that really matters.
Project link: c-tun-vpn on GitHub
Complete technical evaluation: available in the repo, docs/ folder.
Commenti
Lascia un commento