#CS#Network#VPN#Security#Work
VPN: Protecting Your Bank Account on Public Wifi
Not just for Netflix. Creating a 'Secure Tunnel' in a hacker-infested public network.
May 10, 2025
Codemapo
Not just for Netflix. Creating a 'Secure Tunnel' in a hacker-infested public network.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.
Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?
A comprehensive deep dive into client-side storage. From Cookies to IndexedDB and the Cache API. We explore security best practices for JWT storage (XSS vs CSRF), performance implications of synchronous APIs, and how to build offline-first applications using Service Workers.
Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?
Do you log in or transfer money using "FREE_WiFi" at a cafe? For a long time, I vaguely thought, "Isn't HTTPS enough for security?" I trusted the padlock icon in the browser. Then a security developer friend shocked me with these words:
"Public wifi isn't 100% safe even with HTTPS. Attackers can break it with SSL Stripping or DNS Spoofing."
That scared me enough to dig deeper. I came to understand that a hacker on the same wifi network can snoop on your data via Man-in-the-Middle Attack. The solution I discovered was VPN (Virtual Private Network).
At first, I thought VPN was just a "tool to change internet addresses"—something you use to watch US Netflix or access Google from China. That's true, but it's not the whole story. The essence of VPN is creating an encrypted tunnel.
When I use the internet, it's like sending data through a transparent glass pipe. Anyone can see everything. But the moment I turn on VPN, an opaque metal pipe appears inside that glass pipe. Data flows only through that metal pipe. Nothing is visible from the outside.
This analogy clicked for me. Rather than the translation "Virtual Private Network," I found it more intuitive to think of it as "my secret passage."
The core concept of VPN is Tunneling. Initially, I understood this only as "encrypting data," but it's actually a technique to wrap data packets one more time.
Normal internet communication looks like this:
[My PC] → [Data Packet] → [Router] → [Internet] → [Destination Server]
With VPN, it changes to:
[My PC] → [Encrypted VPN Packet (with original packet hidden inside)] → [VPN Server] → [Decryption] → [Destination Server]
The original packet is encapsulated inside a VPN packet. It's like putting a letter inside another shipping box. Even if a hacker intercepts the packet at the router, they only see the outer packaging and can't tell what's inside.
I once captured packets myself. Using Wireshark to access a website without VPN, I could see all the HTTP headers. But with VPN turned on, all packet contents showed as Encrypted Application Data. At that moment, I realized, "Ah, this is tunneling."
VPN protocols come in many varieties. At first, I thought "Isn't all VPN the same?" but the speed, security, and compatibility varied wildly. Here's how I organized my understanding.
A classic protocol from the Windows XP era. Easy to configure and fast, but security is paper-thin. The 128-bit encryption was broken decades ago. Nobody uses it now. If your company VPN runs on PPTP, you should immediately confront the IT department.
This method adds an IPSec encryption layer to compensate for PPTP's weaknesses. Security is decent, but double-wrapping packets makes it slow. It uses UDP ports 500 and 4500, and if the firewall blocks them, you can't connect. When I traveled to China, L2TP didn't work, and I gave up.
The undisputed king of open-source VPN. It uses SSL/TLS encryption, supports both TCP and UDP, and bypasses firewalls well. You connect by loading a configuration file (.ovpn), but setup is a bit complex.
When I first set up my own OpenVPN server, I struggled a lot with creating certificates. You need to create a CA (Certificate Authority), server certificate, and client certificate separately.
# OpenVPN configuration file example
client
dev tun
proto udp
remote vpn.myserver.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
auth SHA256
comp-lzo
verb 3
This single file connects all clients to the VPN. Once you set it up, it's convenient, but at first, it was genuinely difficult.
The first time I tried WireGuard, I was shocked thinking, "VPN can be this fast?" The code is only 4,000 lines. OpenVPN has over 100,000 lines. Fewer lines mean fewer security vulnerabilities.
The speed is overwhelming. In my tests, OpenVPN achieved about 60% of my original internet speed, while WireGuard reached over 90%. That's because it operates at the kernel level.
Configuration is simple too. Here's the WireGuard server config I actually used:
# /etc/wireguard/wg0.conf (server)
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32
Client config is similarly simple:
# Client configuration
[Interface]
Address = 10.0.0.2/24
PrivateKey = <client_private_key>
DNS = 1.1.1.1
[Peer]
PublicKey = <server_public_key>
Endpoint = vpn.myserver.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
The VPN starts with a single command: wg-quick up wg0. Checking connection status is just wg show.
$ wg show
interface: wg0
public key: abcd1234...
private key: (hidden)
listening port: 51820
peer: efgh5678...
endpoint: 123.45.67.89:51820
allowed ips: 0.0.0.0/0
latest handshake: 45 seconds ago
transfer: 12.34 MiB received, 5.67 MiB sent
I loved this simplicity. Whenever I need to set up a new VPN these days, I always use WireGuard.
When using VPN, you need to choose whether to route all traffic through VPN or only some. This is called Full Tunneling and Split Tunneling.
Full Tunneling routes all my internet traffic through the VPN server—Netflix, YouTube, Naver, everything. Security is maximum, but speed slows down and the VPN server gets loaded. Plus, you get the ironic situation where accessing Korean sites becomes slower because it routes through a US server.
Split Tunneling sends only specific traffic through VPN. For example, only sending internal company network traffic (192.168.0.0/16) through VPN while sending everything else through regular internet.
I use split tunneling when working from home. Company admin pages and database access go through VPN, while YouTube and Netflix use regular internet. The setting is controlled in WireGuard's AllowedIPs:
# Full Tunneling
AllowedIPs = 0.0.0.0/0
# Split Tunneling (company network only)
AllowedIPs = 192.168.0.0/16, 10.0.0.0/8
This one difference completely changes the perceived speed.
VPNs are divided into two types based on purpose.
Remote Access VPN is how individual devices (laptops, smartphones) connect to the company network. It's the typical VPN that remote workers use. Every morning, instead of commuting, I press the VPN connect button. That's my commute.
Site-to-Site VPN connects the company headquarters and branch offices. Not individuals, but routers create a VPN tunnel. Seoul headquarters and Busan branch share the network as if they're in the same office. For example, a Busan branch employee can print to a Seoul headquarters printer. (Physically impossible, but possible network-wise)
I once set up a site-to-site VPN, and the key was designing so that the IP ranges on both sides don't overlap. If headquarters uses 192.168.1.0/24, the branch should use 192.168.2.0/24. Otherwise, the routing table gets tangled and chaos ensues.
As infrastructure moves to the cloud, VPN is also shifting to cloud-native methods.
AWS VPC VPN is a service that connects my on-premises server (company office) with AWS VPC (cloud network). Create a VPN Gateway, register a Customer Gateway, and create a VPN Connection—an IPSec tunnel is automatically created.
When I first set up AWS VPN, what confused me was that two tunnels are created by default—Tunnel 1, Tunnel 2. This is for high availability. If one dies, the other survives so the service doesn't break.
Azure VPN Gateway is similar. It supports both Point-to-Site (individual access) and Site-to-Site (branch connection). When using Azure, I was surprised by the performance difference between Basic SKU and VpnGw1 SKU. Basic maxes out at 10Mbps, while VpnGw1 reaches 650Mbps. The price is several times higher, but I learned you shouldn't use Basic in production environments.
Even with VPN on, there are cases where your IP leaks. When I first learned this, I panicked thinking, "VPN is on but it's useless?"
DNS Leak is when DNS queries don't go through the VPN tunnel but fly directly to your ISP (Internet Service Provider). For example, if you're connected to a US VPN server but DNS requests go to your Korean telecom provider, the provider knows every website you visited.
I tested on dnsleaktest.com. Even with VPN on, I saw KT DNS servers. I was shocked. The solution is to force-specify the DNS server in VPN settings.
# WireGuard DNS settings
DNS = 1.1.1.1, 1.0.0.1
Or manually change system DNS to Cloudflare (1.1.1.1) or Google (8.8.8.8).
WebRTC Leak is more insidious. The browser's WebRTC feature exposes my real local IP. You hide the public IP with VPN, but private IPs like 192.168.x.x leak. Even this alone can estimate your location.
I installed a Chrome extension (WebRTC Leak Prevent) to block it. For Firefox, go to about:config and set media.peerconnection.enabled to false.
"Can't I use VPN without paying?" I thought that at first too. I installed a free VPN app and tried it. The speed was slow, but I thought, "It's free, so I'll bear with it."
Then I saw an article. A research finding that 72% of free VPN apps track user data. I wanted to protect my data with VPN, but the VPN company was selling my data—that was the essence of it.
The revenue model of free VPNs is clear:
I now use a paid ExpressVPN subscription. It costs about $10/month, but I accepted that it's better than having my personal information sold.
It's somewhat natural for VPN to slow down speed. There's encryption/decryption overhead, and you're routing through one more VPN server. But if you misconfigure MTU (Maximum Transmission Unit), it becomes absurdly slow.
MTU is the maximum size of a packet you can send at once. Regular Ethernet is 1500 bytes. But VPN wraps the original packet one more time, so you need to reduce MTU by the size of the VPN header.
For example, WireGuard's header is about 60 bytes. So you should set MTU to around 1440. Otherwise, packets fragment in the middle, and speed drops while reassembling.
# WireGuard MTU settings
[Interface]
MTU = 1420
I used VPN with MTU 1500 without knowing this and spent a long time figuring out why certain sites were slow. Lowering MTU to 1420 immediately fixed it. This experience resonated with me, so now I check MTU first when setting up VPN.
These days, "securing without VPN" methods are emerging. That's ZTNA (Zero Trust Network Access).
Traditional VPN operates on "once you connect to VPN, you can access the entire internal network." Like entering a castle and being able to roam all rooms. But ZTNA's philosophy is "trust nobody." Even if you're connected to VPN, it rechecks permissions for each resource.
For example, I have permission to access the company database but not the HR system. ZTNA asks "Is this really you?" every time I try to access the database. It does device authentication, location verification, and behavioral pattern analysis.
I came to understand ZTNA as "the evolution of VPN." Services like Cloudflare Zero Trust and Zscaler are representative. Configuration is more complex than VPN, but the security level is much higher.
Knowing theory without practice is meaningless. Here's how I currently use VPN:
A self-hosted WireGuard server runs fine on a $5/month EC2 instance. Installation is simple too:
# Based on Ubuntu 22.04
sudo apt update
sudo apt install wireguard
# Generate keys
wg genkey | tee privatekey | wg pubkey > publickey
# Write config file (see example above)
sudo nano /etc/wireguard/wg0.conf
# Open firewall
sudo ufw allow 51820/udp
# Start VPN
sudo wg-quick up wg0
# Auto-start on boot
sudo systemctl enable wg-quick@wg0
With this setup, I can connect from my smartphone using the WireGuard app. Airport wifi, hotel wifi—I use them with peace of mind.
Let's return to the initial question. "Is Starbucks wifi safe?"
The answer is "no." Public wifi is a transparent bus. Anyone can see everything. Even with HTTPS, it's vulnerable to attacks like DNS spoofing, SSL stripping, and rogue APs (fake routers).
VPN adds a tinted bulletproof car inside that transparent bus. You can't see inside from the outside, and bullets won't penetrate. It's not perfect, but it's a minimum defense barrier.
Now when I work at a cafe, I feel anxious if I don't turn on VPN. When opening banking apps, logging into AWS console, or accessing company admin pages, I always turn on VPN. It's become a habit.
VPN isn't just a tool for bypassing Netflix regions or breaking through China's firewall. It's the minimum bulletproof vest that protects you on public networks.
The core insights I've accepted:
Ultimately, VPN isn't "I won't use it to save money" but "I'll invest in it as a security cost." Monthly $10 is much cheaper than having my bank account drained.