Not every enterprise network project starts with a clean whiteboard and a full procurement budget.
Some of them start with a site visit, a list of camera locations spread across a compound, and the understanding that anything that goes wrong is going to be your problem until it doesn’t go wrong anymore.
The Aramco branch project was that kind of engagement - and it taught me more about practical network engineering than almost anything I’d done before it.
Here’s what we actually did.
┌───────────────────────────────┐
│ Security Control Center │
│ (SCC Room) │
│ Camera Management Software │
│ Wazuh • pfSense • Cisco FW │
└──────────────┬────────────────┘
│
IPsec VPN Hub (IKEv2)
│
────────────────────────────┼────────────────────────────
│ │ │ │
│ │ │ │
IPsec Tunnel IPsec Tunnel IPsec Tunnel IPsec Tunnel
│ │ │ │
┌────────▼───────┐ ┌────────▼───────┐ ┌────────▼───────┐ ┌────────▼───────┐
│ Teltonika │ │ Teltonika │ │ Teltonika │ │ Teltonika │
│ RUTX11/RUTX12 │ │ RUTX11/RUTX12 │ │ RUTX11/RUTX12 │ │ RUTX11/RUTX12 │
└───────┬────────┘ └───────┬────────┘ └───────┬────────┘ └───────┬────────┘
│ │ │ │
192.168.10.0/24 192.168.20.0/24 192.168.30.0/24 192.168.40.0/24
│ │ │ │
PTZ Cameras PTZ Cameras PTZ Cameras PTZ CamerasThe Problem We Were Solving
The client needed a functional video surveillance system across a multi-location site, monitored from a centralized Security Control Center (SCC) room. PTZ (Pan-Tilt-Zoom) cameras were to be installed at various positions across the compound, and operators in the SCC needed live visibility into all of them - with enough network reliability that a connection drop wasn’t just an inconvenience but a compliance and security failure.
The cameras weren’t co-located with the SCC. They sat at distributed points across the site, connected back over a network we were responsible for designing and securing. That’s the core architectural challenge: how do you get reliable, secure, managed video feeds from geographically spread endpoints back to a single monitoring room?
The answer was IPsec VPN tunnels from each site back to an in-house server that acted as the central aggregation and management point.
The Hardware: Teltonika RUTX11 and RUTX12
For edge routers at each camera location, we deployed Teltonika RUTX11 and RUTX12 units. These are industrial-grade LTE routers - compact, rugged, and built with remote deployments in mind. The RUTX11 handles single-modem LTE with dual-SIM failover; the RUTX12 adds a second modem for true dual-LTE operation, which we used at higher-priority locations where connectivity redundancy was non-negotiable.
What made Teltonika the right choice here wasn’t just the hardware form factor. The RutOS firmware has solid built-in IPsec support, a clean web management interface, and remote management capability through Teltonika’s RMS (Remote Management System) platform - meaning we could push configuration changes, check interface status, and pull diagnostics from any router on the deployment without needing physical access. On a site like this, that matters.
Each router was configured with a primary LTE connection and a failover path. The IPsec tunnel would ride whichever interface was active, with automatic failover logic defined in the routing table.
VPN Architecture: IPsec Back to the In-House Server
The security backbone of the whole setup was a hub-and-spoke IPsec VPN architecture. Each Teltonika router at a camera location formed an IPsec tunnel back to our in-house server, which served as the hub - the central point where all tunnels terminated, camera feeds were accessible, and management traffic was controlled.
We used IKEv2 for the key exchange, with pre-shared keys per site. Tunnel mode IPsec encapsulated all traffic between the remote site subnet and the central server, so camera streams, management traffic, and any monitoring data all flowed encrypted across the cellular network.
The in-house server ran the VPN concentrator role alongside the camera management software, handling simultaneous tunnel sessions from all remote locations. Because each site had its own subnet (more on the subnetting in a moment), traffic routing on the server side was straightforward - each tunnel interface had a specific route back to its corresponding site network, and the camera management system accessed each camera by its internal IP directly.
Access to the SCC room operators was scoped tightly - only the ports and protocols needed for camera feed viewing and PTZ control were permitted. No unnecessary exposure of the management interfaces. These ports are usually mentioend clearly in Hikconnect’s datasheet.
Subnetting: Managing Multiple Cameras Across Multiple Locations
This was one of the more careful planning exercises on the project. With cameras distributed across several locations, each site needed its own IP subnet - both to keep address spaces clean and to prevent any possibility of IP overlap between sites sharing the same VPN hub.
We assigned dedicated /24 subnets to each site. The subnetting was managed centrally from the in-house server, which maintained the routing table for all tunnel-connected segments. Camera IPs within each site were statically assigned and documented - PTZ cameras don’t benefit from DHCP, and knowing exactly which IP maps to which physical camera position on the compound is operationally essential when you need to troubleshoot a specific feed at 11 PM.
The discipline here paid off later. Where we did run into problems was - as often happens - not in the original design but in the expansion. Additional sites were brought into scope during the project, and a couple of them were added without initially checking for subnet conflicts with existing allocations. That brought us to one of the more memorable debugging sessions of the engagement.
The BGP Problem: IP Collision and Routing Confusion
Let me be direct about this because it’s the kind of thing that gets glossed over in project retrospectives but is genuinely useful to understand.
As we expanded the deployment and introduced BGP routing into portions of the network - particularly where we needed dynamic route exchange between the central server and certain upstream connectivity - we hit a problem that is embarrassingly common but not always obvious until you’re in it: IP address collision.
Two sites ended up with overlapping subnet assignments. When both tunnels were active, the routing table on the hub server had two competing routes for the same destination prefix. BGP, doing exactly what it’s supposed to do, was receiving route advertisements from both peers for the same space and struggling to resolve a clean forwarding path. The result was intermittent connectivity to affected cameras - traffic would reach one site correctly, then flip unpredictably.
The diagnostic process involved looking at the BGP routing table output, cross-referencing the advertised prefixes from each peer, and tracing the collision back to the subnet allocation. Once identified, we renumbered the offending site - updated the Teltonika router LAN configuration, updated the IPsec tunnel parameters to match the new subnet, and updated the static assignments for cameras on that site. Tunnel came back clean, routes resolved without conflict, and we added a subnet tracking sheet as a mandatory step for any future site addition.
It wasn’t elegant, but working through it properly rather than applying a quick workaround meant the fix was durable.
Firewall Setup: Cisco and pfSense
We ran a layered firewall approach. Cisco firewall handled the perimeter - ingress and egress control at the network boundary, access control lists scoped to the expected traffic patterns for this deployment. No unnecessary ports open. VPN traffic in and management traffic out, with explicit deny on everything else.
pfSense was integrated for internal segmentation and as an additional control layer between the VPN-connected subnets and the SCC management environment. pfSense’s flexibility made it particularly useful here - we could define granular rules between internal segments, run traffic shaping to prioritize camera stream traffic over background management polling, and use its logging capability to maintain a record of internal traffic flows.
The combination worked well in practice. Cisco at the edge for robustness and vendor support expectation from the client; pfSense internally for flexibility and cost-effectiveness. Both logging to a central destination.
Security Monitoring: Wazuh SIEM and Tenable for VAPT
With a deployment of this nature - edge devices running over cellular networks, a central server with multiple inbound tunnel connections, and camera infrastructure that the client considered operationally sensitive - security visibility was a genuine requirement, not a checkbox.
We deployed Wazuh as the SIEM platform. Wazuh agents were installed on the in-house server and any host-level components we controlled, shipping logs and security events to the Wazuh manager. The rules we tuned covered authentication events, configuration change detection, and network connection anomalies. For a deployment where most legitimate traffic is highly predictable (camera streams and VPN management), deviations stand out quickly if you’re actually watching.
For VAPT - Vulnerability Assessment and Penetration Testing - we used Tenable-based tooling to run authenticated scans against the server infrastructure and network devices where we had access. The scan results fed into a vulnerability register that we reviewed with the client’s security team, prioritizing anything remotely exploitable given the network topology. Edge devices like the Teltonika routers were assessed for firmware version currency and unnecessary exposed services.
The combination of continuous monitoring through Wazuh and periodic assessment through Tenable gave the client both real-time alerting capability and a structured vulnerability management process - which is exactly the posture a facility like this needs.
What the SCC Room Actually Looked Like Operationally
The Security Control Center operators had a straightforward experience on their end, which is the point. They connected to a camera management interface hosted on the in-house server, which presented all PTZ camera feeds organized by site location. Pan, tilt, and zoom commands went back through the same VPN tunnel to the camera at the edge, with response times that were acceptable given the LTE hop.
Monitoring the monitoring infrastructure - making sure all tunnels were up, all cameras reachable, all routers responsive - was handled through a combination of the Teltonika RMS platform for router-level status [we ditched it later though :p ] and Wazuh alerts for any host-level anomalies on the server. If a tunnel dropped, we knew about it through alerting before the SCC operators noticed a dead feed.
What I’d Tell Someone Walking Into This Project
The technical components - Teltonika, IPsec, pfSense, Wazuh - are all individually well-documented. The hard part isn’t any one of them. It’s the integration, and specifically the assumptions you make during initial setup that come back to bite you when the scope expands.
Subnet planning sounds trivial until you’re renumbering a live site because someone added a location without checking for conflicts. BGP routing sounds advanced until you realize the problem is something as fundamental as two networks claiming the same address space. The tools expose the problems clearly enough - if you’re actually looking at the routing table and reading what it’s telling you.
Document everything before you need it. Maintain your subnet allocations centrally from day one. And make sure your remote management capability (RMS, in our case) is working before the site is physically inaccessible - because it will become inaccessible.