Abstract

The use of VPN-based private networking to improve MQTT broker security in Internet of Things infrastructures is examined in this study. It illustrates how private network tunnelling successfully reduces the risks of port discovery, unauthorised access, and distributed denial-of-service (DDoS) attacks in both Edge and Cloud environments by using WireGuard to isolate broker communications.

1. Introduction

This article presents an independent exploration of VPN-based private networking using WireGuard to enhance the security of MQTT brokers in IoT infrastructures. The work contributes to the broader research area of Edge and Cloud Computing Security by demonstrating a practical approach to securing broker communications through network isolation and encrypted tunnelling.

Regarding my research field of Edge & Cloud Computing Security, I already wrote a small post on the idea of using a private network (VPN) for connecting IoT devices to clouds, brokers, etc. I came to know its use when I was learning cybersecurity via Hack The Box, as cybersecurity is my main point of view around which this cloud and IoT security revolves.

2. Background

2.1. MQTT And Its Broker Exposure Risks

MQTT is widely used for telemetry due to its lightweight nature and low bandwidth usage. It's is more efficient for many IoT scenarios than HTTPS — performance benchmarks (e.g., Flespi, 2018) show that MQTT is on average significantly faster than HTTP for persistent connections.

2.1.1. EMQX (MQTT Broker)

Consider an IoT setup (gas sensors, temperature sensors, etc.) where devices communicate over MQTT and push data to a broker. In my experiments I used EMQX (https://www.emqx.com). EMQX offers a strong feature set suitable for experimentation and production: high-performance MQTT, advanced security and governance, multi-protocol support, data integration options, persistence, bridging, and management/monitoring capabilities.

2.1.2. Broker Exposure Risks

MQTT brokers exposed on public interfaces can be vulnerable to: unauthorized access and privilege escalation, credential stuffing and brute-force attacks, port discovery and service enumeration, and Denial of Service (DoS/DDoS).

2.2. WireGuard Overview

WireGuard is a modern VPN protocol and implementation that aims to be simpler and faster than traditional VPN solutions such as IPsec and OpenVPN. It provides lightweight, high-performance encrypted tunnels suitable for both edge devices and cloud VMs.

3. Case Study: AgroSense Smart Greenhouses

A representative case: AgroSense operates multiple smart greenhouses with sensors monitoring temperature, humidity, soil moisture, CO₂ level, and light intensity. Goals include real-time collection, secure transport to the cloud via MQTT, dashboard visualization and analytics, and automated actuation (fans, irrigation) based on thresholds.

4. System Architecture

4.1. Layers

• IoT Layer (Edge Devices): ESP32 / Raspberry Pi devices
• MQTT Layer: EMQX Broker on a Cloud VM
• Cloud Layer: Application and data processing services
• Application Layer: Web dashboard and analytics platform

4.2. Broker Exposure

Typical EMQX/VM ports used by AgroSense: 22 (SSH), 18083 (EMQX Dashboard), 1883 (MQTT non-TLS), 8883 (MQTT TLS). If exposed publicly they create attack surfaces discoverable via network scanning. By placing broker and clients inside a WireGuard private overlay, public discovery and direct attacks are greatly reduced.

5. Proposed Solution: VPN-Based Isolation Using WireGuard

Encapsulate broker operations inside a WireGuard VPN so that SSH, MQTT, and management access traverse the encrypted tunnel. The broker then becomes effectively invisible to unauthorized external entities.

5.1. Configuration Example

Example WireGuard configuration snippets (illustrative):

# Broker VM Configuration
[Interface]
Address = 10.10.0.1/24
PrivateKey = (Broker_VM_PRIVATE_KEY)
ListenPort = 51820

[Peer]
PublicKey = (TEAM_PUBLIC_KEY)
AllowedIPs = 10.10.0.2/32

# Team (Client) Configuration
[Interface]
Address = 10.10.0.2/32
PrivateKey = (TEAM_PRIVATE_KEY)

[Peer]
PublicKey = (BROKER_PUBLIC_KEY)
Endpoint = BROKER_VM_PUBLIC_IP:51820
AllowedIPs = 10.10.0.0/24, 192.168.0.0/16
PersistentKeepalive = 25

On the cloud VM, restrict cloud security rules to only allow UDP port 51820 (WireGuard) for ingress. Enforce an internal Linux firewall so services like SSH and MQTT are only reachable via the wg0 interface:

sudo ufw allow in on wg0 to any port 22
sudo ufw allow in on wg0 to any port 1883
sudo ufw allow in on wg0 to any port 18083
sudo ufw deny 22/tcp
sudo ufw deny 1883/tcp
sudo ufw deny 18083/tcp
sudo ufw enable

6. iptables Configuration

sudo iptables -I INPUT -p udp --dport 51820 -j ACCEPT
sudo iptables -I FORWARD -i wg0 -j ACCEPT
sudo iptables -I FORWARD -o wg0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

7. Security Impact and Risk Mitigation

Major threats addressed include unauthorized broker access, dashboard brute-force, DDoS on open ports, data interception, credential theft, and lateral movement. VPN isolation hides the broker from public scanning and enforces encrypted, authenticated tunnels for management and telemetry.

8. Discussion

VPN-based network isolation introduces minimal performance overhead while offering strong security benefits. WireGuard's simplicity makes it well-suited for edge devices and containerised brokers compared to heavier solutions. Using internal addressing (e.g., 10.10.0.0/24) decouples public IP exposure and enables scalable private overlays.

9. Conclusion

Isolating MQTT brokers inside a WireGuard private network reduces exposure to scanning, credential harvesting, and DoS attacks — aligning closely with Zero Trust and Defence-in-Depth principles. This approach scales into Kubernetes, edge gateways, or SD-WAN segmentation for larger deployments.

10. References

• WireGuard Official Documentation
• Flespi — HTTP vs MQTT performance tests (2018)
• EMQX Documentation
• Wikipedia — WireGuard Protocol Overview
• OASIS — MQTT Specification v5.0 (2019)