← ikonstas70.github.io

Technical Report: Network Automation Stack Project

Author: Ioannis Alexander Konstas
Organization: IT Solutions USA
Published: 2026
Repository: github.com/ikonstas70/technical-articles

ⓘ  Accuracy Disclaimer

Technical content in this article was researched and compiled with AI assistance under the direct supervision of the author. While every effort has been made to ensure accuracy, errors may still be present. If you spot an inaccuracy or have a correction, the author welcomes feedback — please reach out at github@it-solutionsusa.com or open an issue at github.com/ikonstas70.

Date: February 17, 2026
Subject: Implementation of an Isolated Programmatic Gateway for Cisco CSR1000v Infrastructure
Prepared by: Network Engineering Division


Executive Summary

This project establishes a high-security, automated management layer for network device fleets. By leveraging a Flask-based API Gateway, we have transitioned from manual CLI management to a structured programmatic HTTP-to-Telnet bridge. This architecture allows for the automated configuration and monitoring of 10–20 Cisco Cloud Services Routers (CSR1000v) accessible via Telnet on forwarded ports, ensuring zero external exposure while maintaining granular control.

Platform-agnostic design: No hypervisor is required. The stack works with any appliance reachable via Telnet on a forwarded TCP port — physical hardware, virtual machines, console servers, or any platform that maps devices to TCP ports.


1. Infrastructure Architecture

The foundation of the stack is built on a "Total Isolation" principle to prevent unauthorized lateral movement and protect the management plane.


2. The Automation Stack Components

The system functions as a multi-tier bridge, converting stateless HTTP requests into stateful terminal sessions.

2.1 The Middleware (Flask API)

The start_csr_api.sh script initializes a Python virtual environment to host the Flask service on port 8080. This serves as the "Middleman," receiving structured JSON payloads and triggering the automation engine.

2.2 The Automation Engine (csr_api_secure.py)

This core component acts as a Transport Bridge and Timing Controller. It manages the inherent timing sensitivity of Telnet console sessions through a precisely timed execution sequence:

Session = Connect → Sleep 1s → WakeUp → Sleep 1s → Execute → Sleep 2s → Exit

Key Logic Block:

# Timed delays for Telnet/serial buffer stability
shell_cmd = f'(sleep 1; printf "\\r\\n"; sleep 1; printf "terminal length 0\\r\\n"; \
             sleep 1; printf "{command}\\r\\n"; sleep 2; printf "exit\\r\\n") | \
             telnet {ROUTER_IP} {port}'

The terminal length 0 command disables IOS output paging, ensuring the full command output is returned without --More-- prompts.


3. Security and Defensive Design

The gateway implements a multi-layered defense strategy to protect the isolated infrastructure:

Feature Mechanism Purpose
Authentication X-API-KEY Header Prevents unauthorized entities from hitting the API
Port Restriction ALLOWED_PORTS List Limits access strictly to active console ports (2301–2310)
Network Isolation L3 Point-to-Point Ensures management traffic cannot be routed to the public internet
Output Sanitization scrub_output() regex Strips Telnet banners and escape characters for clean JSON output

4. Architectural Shift: CLI to API

The primary achievement of this project is the transformation of legacy CLI nodes into RESTful endpoints.

  1. Input: The user sends a POST request with a command (e.g., show ip int brief).
  2. Processing: The Gateway validates the API key, checks the port range, and handles the Telnet timing via a timed subshell.
  3. Output: The system returns a structured JSON object:
{
  "port": 2301,
  "router": "R1",
  "output": "Interface IP-Address OK? Method Status Protocol..."
}

5. Security Limitations and Recommendations

This implementation successfully solves the "Last Mile" automation problem for Cisco hardware accessible via Telnet. It mitigates console timing issues, bypasses paging prompts, and provides a secure, programmatic interface for higher-level orchestration.

Security Note: While the current stack relies on API keys and port restrictions, future iterations should implement command sanitization to mitigate risks associated with shell=True execution in Python subprocesses, ensuring that injected shell characters cannot escape the printf buffer.


6. Transport Layer Orchestration: The socat Gateway

While the Flask API handles logic and security, the Network Transport Layer is managed by a dedicated utility script, telnet.sh. This script transforms the management workstation (Mac Mini) into a TCP relay station.

6.1 Functionality Overview

The script utilizes socat (Socket Cat) to establish bidirectional byte streams between the local environment and the remote target host at <target-host-ip>. It maps a range of local TCP ports (2301–2310) to the corresponding Telnet ports on the target device.

6.2 Operational Modes

The gateway provides three distinct operational states to balance accessibility with security:


7. Technical Logic Breakdown

The script performs a "Clean State" initialization before establishing the bridge:

1. Process Cleanup: Identifies and terminates any existing listeners on the target range:

sudo lsof -t -iTCP:$PORT | xargs -r sudo kill

2. Socket Forking: The socat command is executed with the fork option:

socat TCP-LISTEN:$PORT,bind=$BIND_IP,fork TCP:<target-host-ip>:$PORT

8. Integrated Automation Flow

With both the Flask API and the socat forwarder active, the full automation stack functions as follows:

Layer Component Action
Orchestration External Client Sends POST request with X-API-KEY
Logic Flask API (Port 8080) Validates command and targets localhost:2301
Transport socat Bridge Relays localhost:2301 traffic to <target-host-ip>:2301
Execution Target Device Receives and executes the command via Telnet on the forwarded port

9. Modular Design Conclusion

The combination of csr_api_secure.py and telnet.sh creates a robust, professional-grade network lab environment. By separating the Transport (socat) from the Logic (Flask), the system remains modular. This architecture allows the physical connection method to be changed — from Telnet to SSH, or from a Point-to-Point link to a VPN — by simply updating telnet.sh without rewriting the core automation API.

Final Security Posture: The system is protected by Tailscale's WireGuard encryption at the transport level and API key authentication at the application level, providing defense-in-depth for the isolated Cisco infrastructure.


10. External Access Layer: Cloudflare Tunnel

The final piece of the Network Automation Stack is the External Access and Invocation Layer. This allows for secure, global management of the isolated router environment without opening any inbound firewall ports.

10.1 Cloudflare Tunnel (cloudflared)

To extend the reach of the local Flask API beyond the isolated Mac Mini and Tailscale network, a Cloudflare Tunnel is implemented.

cloudflared tunnel --url http://localhost:8080

Important: The --url flag creates a temporary "quick tunnel." The URL changes on every restart. Keep the terminal window open — hitting ^C kills the tunnel immediately. For production use, configure a named persistent tunnel.

10.2 Cloudflare vs. Tailscale: Architectural Distinction

A critical design distinction: Cloudflare and Tailscale solve different problems and do not overlap.

Cloudflare Tunnel Tailscale / WireGuard
Target localhost:8080 (Flask API) Raw console ports 2301–2310 (socat)
Role Public HTTPS access, WAF, Zero Trust Private mesh VPN for engineering access
Access Internet-facing (any authenticated client) Private network only (authorized devices)
Encryption TLS via Cloudflare WireGuard end-to-end

Together they provide defense-in-depth: an encrypted, authenticated public surface for automated operations, and an encrypted private surface for direct engineering access.

10.3 Command Execution via curl

curl -X POST http://127.0.0.1:8080/telnet \
     -H "X-API-KEY: YOUR_SECRET_KEY_HERE" \
     -H "Content-Type: application/json" \
     -d '{"port": 2301, "command": "show version"}'
Parameter Purpose
-X POST HTTP method — POST is required when sending a JSON body
-H "X-API-KEY: ..." Custom authentication header validated by Flask
-H "Content-Type: application/json" Informs Flask the body is JSON
-d '{"port": 2301, "command": "..."}' Specifies target router (port) and IOS command

11. Complete End-to-End Data Flow

The entire project represents a sophisticated protocol conversion across multiple layers:

  1. Trigger: Administrator runs a curl command from anywhere via Cloudflare.
  2. Ingress: Cloudflare Tunnel forwards the request to localhost:8080 on the Mac Mini.
  3. Processing: Flask API validates the API key and parses the JSON payload.
  4. Transport: Python executes a timed subshell that talks to the socat bridge at localhost:2301.
  5. Relay: socat forwards TCP traffic across the Point-to-Point link to the target host.
  6. Execution: The Cisco CSR1000v receives the command as if typed directly into a serial console.
  7. Return: Output is scrubbed by scrub_output(), converted to JSON, and returned to the client.

12. Troubleshooting: Reset Sequence

When the tunnel or serial connections enter an inconsistent state (e.g., "Connection closed" immediately on connect, or Cloudflare Error 1033 after ^C), use this three-step reset sequence:

Step 1 — Force-Clear Stuck Serial Lines

# Kill any processes holding socat sockets open
sudo pkill -f "socat TCP-LISTEN"
killall telnet

# Restart the forwarding script
sh telnet.sh

Step 2 — Restart the API Service

sudo launchctl unload /Library/LaunchDaemons/com.csr.api.plist
sudo launchctl load /Library/LaunchDaemons/com.csr.api.plist

Step 3 — Start a Fresh Tunnel

Open a new terminal tab and run — do not close this window:

cloudflared tunnel --url http://localhost:8080

Grab the new URL, update any automation scripts, then verify locally:

curl -X POST http://127.0.0.1:8080/telnet \
     -H "X-API-KEY: YOUR_SECRET_KEY_HERE" \
     -H "Content-Type: application/json" \
     -d '{"port": 2301, "command": "show ip interface brief"}'

13. Summary: The Alexander Full-Stack Project

This architecture represents a complete, ground-up reimagining of network lab management. It moves beyond the limitations of standard out-of-the-box solutions to provide a tailored, highly secure, and programmatic environment.

Component Technology Role
Foundation Cisco CSR1000v (any Telnet-accessible appliance) Isolated network device fleet
Transport socat + Tailscale WireGuard Private mesh TCP relay
Logic Flask + Python (csr_api_secure.py) Secure command timing controller
Edge Cloudflare Tunnel Global zero-trust HTTPS access
Interaction curl / Python requests / AI agents Universal programmatic interface

Result: Legacy serial consoles become RESTful API endpoints. The fleet is no longer managed console-by-console — it is managed as a programmatic infrastructure.


14. Advanced Integration: AI and Orchestration

14.1 AI and Machine Learning Integration

By exposing the Cisco CSR infrastructure as a set of RESTful endpoints, it becomes immediately compatible with Large Language Models and AI agents:

14.2 Orchestration Libraries

The stack is fully compatible with industry-standard Python automation frameworks. By replacing curl with a Python script using the requests library — or integrating with NAPALM or Ansible — configurations can be pushed across the entire fleet in parallel.

Final Status: Functional & Secure.
This full-stack project successfully bridges the gap between legacy networking hardware and modern cloud-native automation. It stands as a robust template for secure, remote, and automated network infrastructure management.