Many machines, one VPN tunnel

A common confusion: customers believe each machine needs its own VPN tunnel. Not true. A VPN tunnel is one physical site — not one machine. Behind that tunnel you can hang as many devices as you want, of different protocols, without touching the VPN router.

What this case is for

To get the right mental model before scaling a bakery, factory, or office from 1 to N connected machines. People coming from the "one VPN per vendor" world expect to configure a tunnel per machine — we work the opposite way: one tunnel per site, N sources per tunnel.

How it works

The WireGuard tunnel carries arbitrary IP packets. When our worker sends Modbus to 192.168.1.51:502, your Mikrotik router:

1. Receives the packet on the rela-vpn interface.
2. Checks its routing table: 192.168.1.0/24 lives on ether1 (your LAN).
3. Forwards it to the switch, which delivers it to the right PLC.

To the PLC, it's a normal TCP connection from 10.200.7.2 (the VPN IP assigned to your site). It doesn't know or care there's a tunnel in between.

If you want to read 15 PLCs in parallel, the worker opens 15 different TCP connections — all crossing the same tunnel. Aggregate bandwidth is typically under 1 Mbps: Modbus and OPC UA are light traffic.

                        ┌─────────────────────────┐
 [Rela AI Worker] ─────▶│ WireGuard tunnel (UDP)  │
                        └──────────┬──────────────┘
                                   │
                         ┌─────────▼──────────┐
                         │   Mikrotik hAP ac3 │
                         │   (your plant)     │
                         └─────────┬──────────┘
                                   │  LAN 192.168.1.0/24
          ┌────────────┬───────────┼───────────┬────────────┐
          ▼            ▼           ▼           ▼            ▼
       Chamber       Oven       Mixer     Compressor    Temp sensor
    Modbus TCP   Modbus TCP     S7comm    EtherNet/IP     OPC UA
        .50         .51          .52          .53           .60

Benefits

When ONE tunnel is enough

When you need MULTIPLE tunnels

The rule: one tunnel = one physical site with a shared LAN. If the networks don't physically connect, you need one tunnel per each.

Step by step — Add a machine to the existing tunnel

Assuming you already have the proofing chamber running over VPN. Now you want to monitor the rotary oven too.

1. Assign fixed IP to the oven (10 min)

From the oven's panel (or manufacturer software), give it a static IP on the same subnet as the chamber:

• IP: 192.168.1.51
• Mask: 255.255.255.0
• Gateway: ISP router's IP (same as the chamber)

2. Verify reachability from the Mikrotik

From the Mikrotik console:

/tool ping count=4 address=192.168.1.51

All 4 pings should succeed. If they don't:

• The oven doesn't have Modbus/OPC UA service active — check equipment config.
• There's an internal plant firewall between switches — consult IT.

3. Identify the oven's protocol

Industrial ovens usually speak:

• Modbus TCP (90% of cases post-2015).
• OPC UA (premium equipment, e.g. Miwe or Revent smart panels).
• S7comm (Siemens specifically).

Check the manual or PLC label. If you don't know, try Modbus TCP first — fails fast.

4. Dashboard → New source

Don't change anything on the Mikrotik. The same tunnel already covers 192.168.1.0/24, so the new IP rides the same path.

5. Register map

If the oven exposes chamber temperature and heater state:

6. Create a differentiated agent

Create a separate agent for the oven:

• Name: Oven Agent
• Min severity: warning
• Specific rules:
  • oven.chamber_temperature > 280 during 2min → high (dangerous over-temperature).
  • oven.chamber_temperature < 150 AND oven.heaters_on == true during 10min → warning (power problem).
  • oven.fan_on == false AND oven.chamber_temperature > 200 → critical (fan dead under load).

7. Validate

Turn the oven on. Within 30 seconds you should see oven.chamber_temperature events in the inbox with rising values. If you do, you're done.

Plan limits and peers

A bakery with 1 location + 50 machines is on Essential. A 5-bakery chain with 10 machines each, on Enterprise. A 20-bakery chain, custom pricing.

Multi-machine specific troubleshooting

I added a new source but the test fails

Try from the Mikrotik:

/tool ping count=4 address=<new-machine-IP>

If ping fails, the problem is in your LAN (segregated VLAN, plant firewall, wrong IP). If ping works but the Modbus test fails, check the register map and unit_id.

All sources show connected but one doesn't reach the inbox

That specific source has its own problem. Most common causes:

• Emit policy threshold_crossed and the value never crosses the threshold.
• Assigned agent has min_severity=critical and events are info.
• Poll interval too long (e.g. 60s) — not enough events yet.

Latency grows as I add machines

Each source's polling is independent and asynchronous. Adding 10 machines to a VPN doesn't add significant latency to each — unless they saturate the tunnel's bandwidth (>10 Mbps sustained).

If you see latency rising, the bottleneck is usually the slow PLC, not the VPN. Check Prometheus timings modbus_poll_latency_seconds{source_id="<id>"}.

Limitations

• Fixed VPN subnet: your site has 10.200.X.0/24 assigned permanently. We can't change it without removing and recreating the peer.
• Routing from Mikrotik to all OT LANs: if your plant has multiple OT subnets (192.168.1.0/24, 192.168.2.0/24, 10.10.0.0/24), the Mikrotik needs routes to all of them.
• Multicast does NOT go through: WireGuard only carries unicast. Multicast-based protocols (BACnet broadcast, EtherNet/IP discovery) don't cross the tunnel — each device must have a directly reachable IP.

See also: VPN Connectivity — technical guide, Bakery from scratch, Modbus TCP connection.