DEV Community: htin linn

How to Configure PCC Load Balancing and Failover on MikroTik RouterOS

htin linn — Sat, 08 Aug 2026 10:18:37 +0000

published: true

tags: mikrotik, networking, sysadmin, routeros

Managing multiple Internet Service Provider (ISP) connections is essential for high-availability enterprise networks. Relying on a single WAN connection creates a point of failure, whereas combining dual ISPs ensures both traffic distribution and network redundancy.

In this guide, we will set up Per Connection Classifier (PCC) Load Balancing alongside automated Failover on MikroTik RouterOS using two active WAN links.

Prerequisites & WAN Setup

For this demonstration, we assume two ISP connections connected to a MikroTik router:

ISP 1 (Primary / Dedicated): Ethernet port ether1_ISP1
ISP 2 (Secondary / Backup): Ethernet port ether2_ISP2
Local Network (LAN): Ethernet port bridge_LAN (192.168.88.0/24)

Step 1: Interface IP Address Assignment

Assign static IP addresses provided by your ISPs and configure your local gateway IP:


routeros
/ip address
add address=192.168.88.1/24 interface=bridge_LAN network=192.168.88.0
add address=1.1.1.2/30 interface=ether1_ISP1 network=1.1.1.0
add address=2.2.2.2/30 interface=ether2_ISP2 network=2.2.2.0
Step 2: Configure Firewall NAT Rules
Configure Network Address Translation (NAT) masquerading for both WAN interfaces to grant internet access to internal clients:
/ip firewall nat
add chain=srcnat out-interface=ether1_ISP1 action=masquerade
add chain=srcnat out-interface=ether2_ISP2 action=masquerade
Step 3: Configure Mangle Rules for PCC Marking
We use Per Connection Classifier (PCC) to split traffic evenly across both ISP links based on source/destination address pairs.
1. Accept Connections to Internal Subnets
Prevent local network traffic from being load-balanced:
/ip firewall mangle
add chain=prerouting dst-address=192.168.88.0/24 action=accept in-interface=bridge_LAN
2. Mark Incoming Connections from ISPs
Ensure responses to inbound traffic leave through the exact same interface they entered:
/ip firewall mangle
add chain=prerouting in-interface=ether1_ISP1 connection-state=new action=mark-connection new-connection-mark=ISP1_conn passthrough=yes
add chain=prerouting in-interface=ether2_ISP2 connection-state=new action=mark-connection new-connection-mark=ISP2_conn passthrough=yes
3. Apply PCC Rules to LAN Traffic
Distribute outgoing connections equally between both links:
/ip firewall mangle
add chain=prerouting in-interface=bridge_LAN connection-state=new per-connection-classifier=both-addresses-and-ports:2/0 action=mark-connection new-connection-mark=ISP1_conn passthrough=yes
add chain=prerouting in-interface=bridge_LAN connection-state=new per-connection-classifier=both-addresses-and-ports:2/1 action=mark-connection new-connection-mark=ISP2_conn passthrough=yes
4. Assign Routing Marks
Translate connection marks into routing decisions:
/ip firewall mangle
add chain=prerouting in-interface=bridge_LAN connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 passthrough=no
add chain=prerouting in-interface=bridge_LAN connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2 passthrough=no
Step 4: Configure Static Routes and Dynamic Failover
Configure default routes using check-gateway monitoring (ping) to automatically reroute traffic if an ISP connection fails.
# Routes for marked traffic
/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 routing-table=to_ISP1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=2.2.2.1 distance=1 routing-table=to_ISP2 check-gateway=ping

# Fallback default routes for unmarked router traffic
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=2.2.2.1 distance=2 check-gateway=ping
Step 5: Verification & Testing
1. Check Firewall Connections
Navigate to IP > Firewall > Connections in WinBox or execute:
/ip firewall connection print
Verify that active connections display connection-mark=ISP1_conn and connection-mark=ISP2_conn evenly.
Unplug the network cable for ether1_ISP1. The router should detect link failure via the check-gateway=ping health check and automatically shift all active network flows through ether2_ISP2 within seconds.Conclusion
Combining PCC load balancing with check-gateway ping monitoring in RouterOS maximizes WAN utilization while building automatic network redundancy. This dynamic routing strategy ensures optimal network stability for bandwidth-intensive environments.

WireGuard Site-to-Site VPN on Linux

htin linn — Sat, 08 Aug 2026 09:43:19 +0000

Connecting separate office locations or data centers securely over the public internet is a critical task for network engineers and system administrators. Traditional VPN solutions like IPsec or OpenVPN can be complex to configure and resource-heavy.

WireGuard provides an extremely fast, modern, and lean alternative that utilizes state-of-the-art cryptography. In this tutorial, we will walk through configuring a production-ready Site-to-Site WireGuard VPN connecting two Linux gateways.

Network Topology Overview

Before diving into configuration, let's define our environment topology:

Site A (Headquarters):
- Public IP: 203.0.113.10
- Internal Subnet: 192.168.10.0/24
- WireGuard Gateway Interface: wg0
- WireGuard IP: 10.0.0.1/30
Site B (Branch Office):
- Public IP: 198.51.100.20
- Internal Subnet: 192.168.20.0/24
- WireGuard Gateway Interface: wg0
- WireGuard IP: 10.0.0.2/30

Step 1: Installing WireGuard on Both Gateways

First, install WireGuard and necessary networking utilities on both Linux gateways (Debian/Ubuntu-based example):


bash
sudo apt update
sudo apt install -y wireguard iptables


(For RedHat/CentOS/Rocky Linux systems, use sudo dnf install -y wireguard-tools iptables).
Step 2: Enable IP Forwarding
For a Site-to-Site VPN, the Linux gateways must forward packets between internal subnets and the WireGuard interface.
On both Site A and Site B gateways, enable IP forwarding permanently:
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Step 3: Key Generation
WireGuard uses public/private key pairs for peer authentication.
On Site A Gateway:
cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
On Site B Gateway:
cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
Note: Keep private keys strictly confidential and readable only by root.
Step 4: Configuring Site A Gateway (/etc/wireguard/wg0.conf)
Create the configuration file on Site A:

sudo nano /etc/wireguard/wg0.conf
Add the following content (replace keys with your actual generated keys):

[Interface]
Address = 10.0.0.1/30
ListenPort = 51820
PrivateKey = <SITE_A_PRIVATE_KEY>

# PostUp and PostDown rules for NAT routing across internal interface (eth0)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site B Details
PublicKey = <SITE_B_PUBLIC_KEY>
Endpoint = 198.51.100.20:51820
# Allow WireGuard tunnel IP and Site B internal subnet
AllowedIPs = 10.0.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25
Step 5: Configuring Site B Gateway (/etc/wireguard/wg0.conf)
Create the configuration file on Site B:
sudo nano /etc/wireguard/wg0.conf
Add the following content:
[Interface]
Address = 10.0.0.2/30
ListenPort = 51820
PrivateKey = <SITE_B_PRIVATE_KEY>

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site A Details
PublicKey = <SITE_A_PUBLIC_KEY>
Endpoint = 203.0.113.10:51820
# Allow WireGuard tunnel IP and Site A internal subnet
AllowedIPs = 10.0.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25

Step 6: Starting and Enabling the WireGuard Tunnel
Start the interface and enable auto-start on boot for both gateways:
sudo systemctl enable --now wg-quick@wg0
Step 7: Verifying Tunnel and Route Connectivity
1. Check WireGuard Status
Execute the following command on either gateway to verify the active peer handshake:
sudo wg show

2. Test Ping Across Tunnels
From Site A Gateway, ping Site B's internal IP:
ping -c 4 10.0.0.2
ping -c 4 192.168.20.1
From a workstation inside Site A (192.168.10.50), ping a machine in Site B (192.168.20.50) to confirm cross-subnet routing.
Step 8: Adding Static Routes on Local Routers (Optional)
If your Linux gateways are separate from your core LAN routers, remember to add a static route on your primary LAN router:
Site A LAN Router: Destination 192.168.20.0/24 via Next Hop 192.168.10.X (Site A Linux Gateway).
Site B LAN Router: Destination 192.168.10.0/24 via Next Hop 192.168.20.X (Site B Linux Gateway).
Conclusion
WireGuard provides high-performance encrypted transport with minimal overhead compared to legacy VPN protocols. By enabling IP forwarding, setting precise AllowedIPs routing policies, and configuring iptables post-up actions, you can establish a secure and efficient site-to-site communication channel across remote sites.