🧠💥 How I Routed My Entire Lab's HTB Traffic Through a Single VPN Box
😤 The Problem
If you’re working in a lab environment and doing serious work with Hack The Box (HTB), chances are you've got automation running scanners, exploit frameworks, recon tools, and maybe even a full orchestration setup.
The catch? HTB traffic only routes through their VPN tunnel. So unless every single box in your lab connects to the VPN (spoiler: bad idea), you’re stuck.
🎯 The Goal
Instead of duct-taping VPN clients on every box, here’s what we want:
Single system connected to HTB VPN
All LAN devices route HTB-bound traffic through that system
Clean iptables rules that don’t wreck your firewall
Scriptable and reversible setup that “just works”
🧠 The Setup
Here’s the architecture:
LAN Interface: Your main interface (e.g.,
ens33
)VPN Interface: Where your HTB VPN is connected (
tun0
)LAN Subnet:
192.168.0.0/24
HTB Subnet:
10.10.0.0/16
We’re going to build a gateway that transparently routes traffic from your LAN to HTB over the VPN.
🛠️ The Script
# Define variables
LAN_IFACE="ens33"
# LAN_IFACE: The interface connected to your local network (home lab or automation server).
VPN_IFACE="tun0"
# VPN_IFACE: The interface created by HTB's OpenVPN connection.
LAN_SUBNET="192.168.0.0/24"
# LAN_SUBNET: The subnet used by your internal LAN devices.
HTB_SUBNET="10.10.0.0/16"
# HTB_SUBNET: The IP range used by HTB target machines. This is what we want to reach via VPN.
echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
# 🚀 Enable IP forwarding
# Required so it can forward traffic from LAN to VPN
sudo iptables -F
sudo iptables -t nat -F
# Flushes all filter and NAT rules.
# ⚠️ Warning: This will wipe existing firewall rules. Fine for a lab, dangerous in production.
# NAT outgoing traffic to VPN
sudo iptables -t nat -A POSTROUTING -s $LAN_SUBNET -d $HTB_SUBNET -o $VPN_IFACE -j MASQUERADE
# Changes the source IP of packets from your LAN going to HTB, so they appear to come from your VPN interface IP.
# Allow traffic from LAN to VPN and back
sudo iptables -A FORWARD -s $LAN_SUBNET -d $HTB_SUBNET -i $LAN_IFACE -o $VPN_IFACE -j ACCEPT
# Allows packets going from LAN to HTB (via VPN)
sudo iptables -A FORWARD -d $LAN_SUBNET -s $HTB_SUBNET -i $VPN_IFACE -o $LAN_IFACE -j ACCEPT
# Allows return packets coming from HTB back to LAN
👽 Link to updated code
💥Connect my client
sudo ip route add 10.10.11.165 via 192.168.0.251 dev wlp0s20f3
10.10.11.165
is an HTB IP address of the box192.168.0.251
my proxy_box IP addressto delete the ip route
sudo ip route del 10.10.11.165 via 192.168.0.251 dev wlp0s20f3
⚡ Real-World Use Case
Now every system on my network even my toaster (I always knew it was destined for great things) can reach any HTB target, without needing its own VPN setup. 🤖🔗💣
💬 Final Thoughts
This isn’t about fancy scripts or over-engineering (I tend to do it a lot but don't we all). It’s about having a reliable, controlled setup that routes HTB traffic through your VPN without reinventing the wheel or smashing your firewall with a sledgehammer. You now have a surgical routing setup. There are no hacks, no weird side effects, and just a clean flow from your lab to HTB.
Last updated