How to Build a Bastion Host to Enhance Network Access Security?

Building your own bastion host is less complicated than it sounds. The most secure design employs a dual-homed physical isolation architecture — making the bastion machine the sole bridge between a protected internal computer and the broader internet or LAN. This guide walks through every step, from hardware layout through firewall lockdown.

Preparing the Physical Network

The bastion host (Computer B) requires two network interfaces: one connected to your router or external network, and one connected directly to the protected machine (Computer A) via a network cable — no router in between.

Acceptable hardware combinations include an onboard NIC plus a USB network adapter, or a Wi-Fi adapter for the external side and a wired NIC for the internal side.

Building the Isolated Internal Subnet

Create a minimal private LAN on the 10.0.0.0/24 subnet between Computer B and Computer A.

After this configuration, A and B can reach each other, but Computer A has no route to the internet whatsoever — complete network isolation is already in effect.

Choosing Your Access Strategy

Two well-established approaches let Computer A reach internet resources under controlled conditions. Choose based on how much direct browser access Computer A needs:

Solution A — Minimalist Jump Host (SSH / RDP)

Install KVM or VirtualBox on Bastion B and run a dedicated internet VM inside it. Configure SSH to listen only on the internal interface, so Computer A connects via SSH tunnel or RDP — and all malicious payloads stay locked inside the VM on B:

# Bind SSH only to the internal interface — never the WAN side
ListenAddress 10.0.0.1

Solution B — Squid Forward Proxy

Install Squid on Bastion B, then lock it down so only Computer A can use it:

# Debian / Ubuntu
sudo apt update && sudo apt install squid -y

Edit /etc/squid/squid.conf with a strict allow-list policy:

# Only Computer A may use this proxy
acl private_network src 10.0.0.2
http_access allow private_network
http_access deny all

# Bind to the internal interface only
http_port 10.0.0.1:3128

# High-anonymity: strip forwarding headers
forwarded_for off
request_header_access Via deny all

sudo systemctl restart squid

On Computer A (or in LibreWolf / Firefox preferences), set the HTTP/HTTPS proxy to 10.0.0.1 port 3128. Every request now flows through Bastion B’s audit layer.

The Ultimate iptables Defense Layer

The bastion host itself must be hardened. The single most important rule: never enable kernel IP forwarding (net.ipv4.ip_forward=0). Without it, Computer A cannot bypass the proxy and reach the external network via raw IP routing even if something goes wrong.

Apply the following iptables ruleset to Computer B:

# 1. Drop all forwarded traffic — sever any direct A→Internet routing
iptables -P FORWARD DROP

# 2. Allow A to reach Squid proxy port on Bastion B
iptables -A INPUT -s 10.0.0.2 -d 10.0.0.1 -p tcp --dport 3128 -j ACCEPT

# 3. Allow SSH / RDP for jump-host access (Solution A)
iptables -A INPUT -s 10.0.0.2 -d 10.0.0.1 -p tcp --dport 22 -j ACCEPT

# 4. Deny all other traffic from A — no probing, no scanning
iptables -A INPUT -s 10.0.0.2 -j DROP

What You Achieve After Setup

• Complete external invisibility: Scanners probing your router’s public IP or main LAN see only Bastion B’s WAN interface. Computer A does not appear on any external network map.
• Lateral movement prevention: Even if Computer A executes a high-risk trojan, the isolated 10.0.0.0/24 segment prevents outbound TCP/UDP connections to command-and-control servers, and also prevents scanning of other home devices (NAS, phones, smart TVs).
• Full traffic audit capability: With Squid’s access logs (/var/log/squid/access.log), every domain and request from Computer A is recorded on Bastion B.
• Rapid containment with VM rollback: In Solution A, disabling VM snapshots and rolling back after each session removes all traces of any infection instantly.