# MikroTik RouterOS 7.23.2 Tunnel & VPN Benchmark Project

You are acting as a senior MikroTik RouterOS network engineer and automation specialist.

Your task is to remotely connect to two MikroTik routers, configure several different tunnel technologies between them, verify each tunnel carefully, benchmark their performance, collect all test results, and finally generate a structured technical comparison report.

This is a REAL LAB environment.

You are allowed to connect to the routers using SSH and execute RouterOS commands, but you must work carefully and incrementally.

Do NOT blindly apply large configurations.

Do NOT make unnecessary changes.

Do NOT modify unrelated parts of the existing router configuration.

The objective is to compare different MikroTik tunnel technologies under approximately the same network conditions.

---

# LAB ENVIRONMENT

There are two MikroTik routers.

## Router 1 – Iran

Location:

Iran

RouterOS:

7.23.2

Connection method:

SSH

SSH Host/IP:

[IRAN_ROUTER_IP]

SSH Port:

[IRAN_SSH_PORT]

Username:

[IRAN_USERNAME]

Password:

[IRAN_PASSWORD]

---

## Router 2 – Germany

Location:

Germany

RouterOS:

7.23.2

Connection method:

SSH

SSH Host/IP:

[GERMANY_ROUTER_IP]

SSH Port:

[GERMANY_SSH_PORT]

Username:

[GERMANY_USERNAME]

Password:

[GERMANY_PASSWORD]

---

# IMPORTANT SECURITY AND SAFETY RULES

These routers may already contain existing configuration.

You must NOT assume they are empty routers.

Before making any changes:

1. Connect to both routers.
2. Verify that SSH access works correctly.
3. Check RouterOS version.
4. Inspect the existing configuration.
5. Check existing interfaces.
6. Check existing IP addresses.
7. Check existing routes.
8. Check existing firewall rules.
9. Check existing tunnels/VPN interfaces.
10. Check whether any configuration you are planning to create could conflict with the existing configuration.

Do not remove, disable, rename, or modify unrelated existing configuration.

Before starting the tunnel configuration, create backups of both routers.

Create both:

- RouterOS binary backup
- RouterOS configuration export

Use meaningful filenames containing:

- router/location
- date/time
- pre-benchmark indication

Example concept:

iran-pre-benchmark
germany-pre-benchmark

Do not overwrite existing backups.

---

# SAFE MODE

Whenever practical, use RouterOS Safe Mode while applying configuration that could affect connectivity.

The most important rule throughout this project is:

DO NOT LOCK YOURSELF OUT OF THE ROUTERS.

Do not change:

- management IP addresses
- SSH configuration
- default routes
- firewall rules related to management

unless absolutely required.

If a configuration change could potentially break remote access, stop and analyze it before executing it.

---

# WORKING METHOD

Work incrementally.

For every major step:

1. Inspect.
2. Plan.
3. Execute.
4. Verify.
5. Document.

Do not configure all tunnels at once.

Complete and verify one tunnel before moving to the next one.

If something does not work:

Do NOT immediately start changing random settings.

Troubleshoot systematically.

Inspect:

- interface state
- logs
- routes
- firewall
- NAT
- tunnel parameters
- reachability
- MTU
- protocol-specific settings

Identify the actual cause before changing the configuration.

---

# PROJECT OBJECTIVE

Configure and benchmark the following tunnel scenarios between the Iran and Germany MikroTik routers:

## Test 1

WireGuard

## Test 2

SSTP

Iran router acts as the SSTP Server.

Germany router acts as the SSTP Client.

## Test 3

SSTP

Germany router acts as the SSTP Server.

Iran router acts as the SSTP Client.

## Test 4

6to4 Tunnel

The final goal is to compare these tunnel technologies using measurable results.

---

# TESTING PRINCIPLE

The tests must be as fair and repeatable as reasonably possible.

Use similar conditions for every tunnel.

Do not intentionally optimize one tunnel while leaving another tunnel with obviously poor configuration.

Where protocol overhead or implementation differences exist, document them rather than hiding them.

Before every benchmark, verify that the correct tunnel is actually carrying the test traffic.

Do not assume that because an interface is running, traffic is necessarily passing through it.

---

# PHASE 1 – INITIAL DISCOVERY

Connect to both routers.

Create a short inventory.

For each router collect:

- identity
- RouterOS version
- architecture
- CPU
- CPU core count
- RAM
- current CPU load
- interfaces
- public/WAN interface
- IP addresses
- relevant routes
- existing tunnel interfaces
- relevant firewall rules
- relevant NAT rules

Determine the public IP connectivity between the two routers.

Test basic IP reachability between Iran and Germany before creating any tunnel.

Record baseline latency.

Perform multiple ping tests instead of relying on a single ping.

Record:

- minimum latency
- average latency
- maximum latency
- packet loss

This will become the baseline for later comparison.

---

# PHASE 2 – BACKUP

Before changing configuration:

Create a binary RouterOS backup on both routers.

Also export the RouterOS configuration to a readable `.rsc` file.

Verify that the files were created successfully.

Record the filenames in the project documentation.

---

# PHASE 3 – WIREGUARD

Configure a WireGuard tunnel between the Iran and Germany routers.

Use a dedicated WireGuard interface.

Generate appropriate WireGuard keys.

Exchange public keys correctly.

Assign a dedicated point-to-point tunnel subnet that does not conflict with existing networks.

Configure peers appropriately.

Set:

- endpoint address
- endpoint port
- allowed-address
- persistent keepalive where appropriate

Add only the minimum required firewall configuration.

Do not expose unnecessary services.

After configuration:

Verify the WireGuard interface.

Verify peer status.

Verify handshake.

Verify RX/TX counters.

Ping the opposite tunnel IP from both routers.

Test:

Iran → Germany

and

Germany → Iran

Do not proceed to benchmarking until the tunnel is confirmed operational.

Document the final WireGuard configuration relevant to this test.

---

# PHASE 4 – WIREGUARD BENCHMARK

Benchmark the WireGuard tunnel.

Measure at minimum:

## Latency

Run multiple ICMP tests through the WireGuard tunnel.

Collect:

- min RTT
- average RTT
- max RTT
- packet loss

## Throughput

Use MikroTik's built-in bandwidth-test where appropriate.

Run tests in both directions.

Test:

Iran → Germany

Germany → Iran

Where practical, test:

- TCP
- UDP

Do not immediately use maximum possible load.

Start conservatively.

Monitor CPU utilization during testing.

Increase test load carefully.

Avoid destabilizing either router.

Record:

- protocol
- direction
- target
- duration
- throughput
- packet loss where applicable
- CPU load
- relevant observations

If UDP testing is performed, increase offered load gradually instead of immediately flooding the connection.

Try to identify the approximate maximum stable throughput without causing unnecessary router instability.

---

# PHASE 5 – SSTP: IRAN SERVER

Configure SSTP with:

Iran = SSTP Server

Germany = SSTP Client

Use RouterOS-supported secure settings.

Create only the accounts/secrets required for this lab.

Use a dedicated tunnel address range that does not conflict with existing networks.

Configure the SSTP server.

Configure authentication appropriately.

Configure the Germany SSTP client.

Add only firewall rules required for SSTP operation.

Do not unnecessarily weaken existing firewall security.

After configuration verify:

- SSTP server status
- SSTP client status
- active PPP session
- assigned tunnel addresses
- RX/TX traffic
- route/reachability

Test:

Iran → Germany tunnel IP

Germany → Iran tunnel IP

Confirm that the tunnel is actually carrying the test traffic.

---

# PHASE 6 – SSTP IRAN-SERVER BENCHMARK

Perform the same benchmark methodology used for WireGuard.

Collect:

- latency
- min RTT
- average RTT
- max RTT
- packet loss
- TCP throughput
- UDP throughput where practical
- CPU utilization
- direction
- observations

Test both:

Iran → Germany

Germany → Iran

Keep the methodology as consistent as possible with the WireGuard test.

---

# PHASE 7 – SSTP: GERMANY SERVER

Now configure the opposite SSTP scenario.

Germany = SSTP Server

Iran = SSTP Client

This must be treated as a separate benchmark scenario.

Do not simply assume the results will be identical because the same protocol is being used.

Configure and verify the tunnel.

Check:

- SSTP server
- SSTP client
- PPP session
- addresses
- routing
- RX/TX counters
- bidirectional tunnel reachability

Test tunnel IP connectivity in both directions.

---

# PHASE 8 – SSTP GERMANY-SERVER BENCHMARK

Repeat the benchmark.

Measure:

- latency
- packet loss
- TCP throughput
- UDP throughput where practical
- CPU utilization

Test:

Iran → Germany

Germany → Iran

Record all results independently from the previous SSTP test.

We specifically want to determine whether changing the SSTP server location/direction affects performance.

---

# PHASE 9 – 6to4

Configure a 6to4 tunnel between the two MikroTik routers.

Before configuration, inspect RouterOS 7.23.2 syntax and existing IPv6 configuration.

Do not interfere with existing IPv6 connectivity.

Create the required 6to4 interfaces and addresses.

Use appropriate IPv6 addressing for the tunnel.

Verify that the tunnel is operational.

Test IPv6 connectivity across the tunnel.

Perform ping tests in both directions.

Confirm that traffic is actually traversing the 6to4 tunnel.

---

# PHASE 10 – 6to4 BENCHMARK

Benchmark the 6to4 tunnel using a methodology as close as possible to the previous tests.

Measure:

- latency
- packet loss
- throughput
- CPU utilization

Test both directions.

Clearly document any limitations that make the 6to4 test not directly equivalent to WireGuard or SSTP.

Do not manipulate results to make the comparison appear cleaner.

Technical differences between the technologies should be explicitly documented.

---

# BENCHMARK METHODOLOGY

For every tunnel scenario, collect consistent measurements.

At minimum record:

Tunnel

Direction

Transport/Test Type

Average Throughput

Peak Throughput

Minimum Latency

Average Latency

Maximum Latency

Packet Loss

Router CPU during test

Any abnormal behavior

Tunnel stability

---

# MULTIPLE TEST RUNS

Do not rely on a single benchmark run.

Whenever practical, perform multiple runs.

Prefer at least 3 runs for important throughput measurements.

Calculate or report:

- average result
- best result
- worst result

If one result is significantly different from the others, investigate whether it is an outlier.

Do not silently discard poor results.

Document them.

---

# CPU MONITORING

Tunnel performance can be heavily affected by router CPU.

During throughput tests, monitor CPU usage on BOTH routers.

Record CPU load.

If CPU reaches or approaches 100%, document that the test may be CPU-limited rather than network-limited.

Where possible, inspect per-core CPU behavior.

Do not report a throughput number as the pure network capacity if the router CPU is clearly the bottleneck.

---

# MTU

Pay attention to MTU.

Different tunnels introduce different overhead.

Inspect MTU settings for:

- WireGuard
- SSTP
- 6to4

If fragmentation or MTU-related issues appear, investigate them.

Do not randomly reduce MTU just to make a test work.

Determine the reason first.

If MTU must be changed, document:

- original MTU
- new MTU
- reason
- impact on test

---

# ROUTING VALIDATION

Before each benchmark, prove that traffic is using the intended tunnel.

Use RouterOS tools where appropriate, such as:

- ping with source address
- traceroute
- interface counters
- routes
- torch
- traffic monitoring

Do not benchmark traffic accidentally traveling over the public/default route.

---

# RAW DATA STORAGE

Create a local project directory for all benchmark results.

Use a clean structure similar to:

mikrotik-tunnel-benchmark/

    README.md

    reports/

        baseline.md

        wireguard.md

        sstp-iran-server.md

        sstp-germany-server.md

        6to4.md

        final-comparison.md

    results/

        baseline.csv

        wireguard.csv

        sstp-iran-server.csv

        sstp-germany-server.csv

        6to4.csv

    configs/

        iran-before.rsc

        germany-before.rsc

        relevant-final-configs.md

The exact structure may be improved if necessary, but keep it organized and understandable.

---

# CSV OUTPUT

Store benchmark measurements in CSV format so they can later be analyzed or plotted.

Use useful columns such as:

timestamp

tunnel

server_location

direction

test_type

transport

duration

target

throughput_mbps

packet_loss_percent

min_latency_ms

avg_latency_ms

max_latency_ms

iran_cpu_percent

germany_cpu_percent

notes

Do not fabricate missing measurements.

Use blank/null values when a measurement genuinely cannot be obtained.

---

# INDIVIDUAL REPORTS

Create a Markdown report for every tunnel.

Each report should contain:

## Configuration Summary

Explain how the tunnel was configured.

## Verification

Explain how tunnel operation was confirmed.

## Benchmark Method

Explain exactly how the tests were performed.

## Results

Present the collected measurements clearly.

## CPU Behavior

Document CPU utilization.

## Stability

Document disconnects, packet loss, errors, or unusual behavior.

## Observations

Explain anything technically interesting about the tunnel.

Do not write marketing-style conclusions.

Base observations on measured results.

---

# FINAL COMPARISON REPORT

After all tests are completed, create:

reports/final-comparison.md

The report should compare all four scenarios:

1. WireGuard
2. SSTP – Iran Server
3. SSTP – Germany Server
4. 6to4

Include a clear comparison table.

Suggested structure:

| Tunnel | Direction | Avg Throughput | Avg Latency | Packet Loss | CPU Iran | CPU Germany |
|---|---|---:|---:|---:|---:|---:|

Then analyze the results.

Determine:

- Which tunnel achieved the highest throughput?
- Which tunnel had the lowest latency?
- Which tunnel had the lowest packet loss?
- Which tunnel used the least CPU?
- Which tunnel showed the best stability?
- Did SSTP server location significantly affect performance?
- Was any test CPU-limited?
- Were there meaningful MTU differences?
- Were there asymmetric results between Iran → Germany and Germany → Iran?

---

# FINAL RANKING

Provide a ranking based ONLY on the collected data.

Create separate rankings for:

## Throughput

## Latency

## Packet Loss

## CPU Efficiency

## Stability

## Overall Performance

Do not automatically declare WireGuard the winner because it is expected to be faster.

The final conclusion must come from the actual benchmark results.

If WireGuard wins, explain exactly why based on measurements.

If SSTP or another tunnel performs better in a specific category, report that honestly.

---

# IMPORTANT: DO NOT FABRICATE RESULTS

Every number in the final report must come from an actual test.

Never invent:

- throughput
- latency
- packet loss
- CPU utilization
- handshake information
- tunnel state

If a test cannot be completed, clearly mark it as:

FAILED

INCOMPLETE

or

NOT TESTED

and explain why.

---

# TROUBLESHOOTING POLICY

If a tunnel does not work:

1. Inspect current state.
2. Collect evidence.
3. Check logs.
4. Check interface state.
5. Check routing.
6. Check firewall.
7. Check NAT.
8. Check tunnel parameters.
9. Determine the most probable root cause.
10. Apply the smallest reasonable fix.
11. Retest.

Do not perform destructive troubleshooting.

Do not reset either router.

Do not remove unrelated firewall rules.

Do not change unrelated routing.

Do not reboot routers unless there is a technically justified reason.

If you believe a reboot is required, explain why BEFORE doing it.

---

# CHANGE MANAGEMENT

Keep track of every configuration change made during this project.

At the end, create a summary showing what was added to each router.

Separate:

Existing Configuration

from

Benchmark Configuration

This is important because we may want to remove the lab configuration later.

Where practical, add useful comments to RouterOS objects created for this benchmark so they can easily be identified later.

Use a consistent naming/comment convention.

For example:

AI-BENCH-WG

AI-BENCH-SSTP

AI-BENCH-6TO4

Do not rename existing objects merely to match this convention.

---

# CLEANUP

Do NOT automatically remove the benchmark configuration after testing.

Leave the working tunnel configurations in place unless explicitly instructed otherwise.

However, document exactly which:

- interfaces
- IP addresses
- routes
- firewall rules
- PPP profiles
- PPP secrets
- certificates
- WireGuard peers
- other objects

were created during this project.

Provide cleanup commands separately, but DO NOT execute them automatically.

---

# EXECUTION BEHAVIOR

You are not merely writing instructions for me.

You are expected to actively perform the work through the available terminal/SSH environment.

However:

Do not rush.

Do not execute a huge script against both routers.

Do not make assumptions when RouterOS can be queried directly.

Inspect the routers first.

Use the actual state of the routers as the source of truth.

If RouterOS returns an error, read and understand the error before trying another command.

Do not repeatedly execute slightly different commands hoping that one works.

---

# ROUTEROS VERSION

Both routers are expected to run RouterOS 7.23.2.

Use syntax appropriate for RouterOS 7.23.2.

Do not blindly use RouterOS 6 syntax.

When uncertain about a command or feature, verify the RouterOS 7 syntax before applying it.

---

# TEST IMPACT

Bandwidth testing can generate significant CPU and network load.

Therefore:

Start tests conservatively.

Monitor router health.

Do not intentionally saturate management connectivity to the point where SSH access is lost.

Between intensive tests, allow router CPU and network conditions to stabilize.

If either router becomes unstable, stop the benchmark and investigate.

---

# FINAL DELIVERABLES

At the end of the project I expect:

1. Verified working WireGuard tunnel.

2. Verified working SSTP tunnel with Iran as server.

3. Verified working SSTP tunnel with Germany as server.

4. Verified working 6to4 tunnel.

5. Baseline connectivity measurements.

6. Bidirectional latency tests.

7. Bidirectional throughput tests.

8. Packet-loss measurements.

9. CPU measurements during benchmarks.

10. Raw CSV benchmark data.

11. Individual Markdown reports.

12. A final Markdown comparison report.

13. A data-based ranking of the tunnel technologies.

14. Documentation of every configuration change made.

15. Cleanup commands, documented but NOT executed.

---

# STARTING INSTRUCTION

Start with discovery ONLY.

Do not configure any tunnel yet.

First:

1. Connect to both MikroTik routers via SSH.
2. Confirm that both routers are reachable.
3. Confirm RouterOS versions.
4. Inspect the existing relevant configuration.
5. Identify anything that could conflict with this project.
6. Test direct connectivity between the two routers.
7. Create the baseline measurements.
8. Create backups and configuration exports.

Then show me a concise summary of what you discovered and your proposed addressing/configuration plan.

After the environment has been safely inspected, continue with the tunnel implementation and benchmarking process step by step.

Throughout the project, prioritize:

SAFETY

ACCURACY

REPEATABILITY

MEASURABLE RESULTS

and

MINIMUM IMPACT ON EXISTING CONFIGURATION.