Network Connectivity Options for On-Premises Environments

Overview

This article summarizes common ways to connect Reindeer to systems that run in an on-premises or customer-managed network. It is intended for infrastructure, network, and security teams evaluating how Reindeer can reach internal systems such as ERP platforms, AS/400 or IBM i environments, databases, file shares, SFTP servers, internal APIs, and legacy applications.

The right option depends on traffic direction, security policy, latency, throughput, routing ownership, and whether inbound connectivity from a Reindeer environment is allowed.

Questions This Article Answers

• Does Reindeer require inbound access to the customer network?
• Can connectivity be outbound-only from the customer environment?
• Which VPN or private-network options are supported?
• What firewall, routing, DNS, and access-control details are required?
• What does the customer security or network team need to provide?
• How should connectivity be scoped for legacy and fragmented on-premises environments?

Common Connectivity Patterns

Site-to-Site IPsec VPN

A site-to-site IPsec VPN connects the Reindeer network environment to the customer network through VPN gateways or firewall appliances. This pattern is commonly used when Reindeer needs private access to internal APIs, databases, file shares, message queues, ERP systems, or legacy applications.

Design considerations:

• Use redundant tunnels where possible.
• Prefer dynamic routing with BGP when supported by the customer network.
• Define exact CIDR ranges that should be reachable across the tunnel.
• Avoid overlapping IP ranges between environments.
• Restrict firewall rules to the minimum required hosts, ports, and protocols.
• Monitor tunnel status, route health, latency, packet loss, and failover behavior.

Cloud-Managed VPN Gateway

Some customers prefer to terminate Reindeer connectivity through an existing cloud-to-on-premises network path that their network team already operates. Reindeer remains hosted in Reindeer's cloud environment, and the customer defines the approved network entry point into their on-premises environment.

Typical requirements include VPN gateway public IPs, routing mode, BGP settings if used, firewall rules, private DNS behavior, and the customer-side network path that should receive Reindeer traffic.

Dedicated Private Connectivity

For higher throughput, lower latency, or stricter network separation, customers may use a private circuit instead of VPN.

This option is usually appropriate when traffic volume is high, latency is sensitive, VPN overhead is not acceptable, or the customer already operates private cloud connectivity. A private circuit still requires routing, firewall, DNS, monitoring, and access-control design. It should be treated as a network path, not as an authorization boundary by itself.

Outbound-Only Connector or Relay

Some customer environments do not allow inbound connectivity from external cloud networks. In that case, a connector or relay can be deployed inside the customer network. The connector initiates outbound TLS connections and can perform approved workflow actions against internal systems.

This pattern is useful when:

• Inbound firewall openings are not allowed.
• The customer wants direct control over egress rules.
• Reindeer only needs access through approved connector actions.
• Network teams prefer an agent-based integration model over routed network access.

Security controls should include scoped credentials, connector-level permissions, audit logging, patching ownership, and clear limits on which systems the connector can reach.

Software-Defined VPN and Reverse Tunnel Options

Some customers prefer a software-defined VPN or tunnel instead of a traditional site-to-site VPN. Reindeer can work with customer-approved patterns such as Tailscale or WireGuard-based mesh VPNs, Cloudflare Tunnel-style reverse tunnels, or a standard VPN endpoint exposed for service clients.

For production use, the tunnel should be configured for service-to-service access rather than human remote access. Prefer certificate-based, token-based, or device-identity-based authentication where possible. Username and password authentication can be supported when required, but security teams often prefer non-human service identity, scoped access, and rotation controls.

The tunnel should only expose the internal systems required for the workflow, such as an approved web application, AS/400 TN5250 endpoint, internal API, SFTP server, database, or file share. Avoid broad routes to the full internal network.

Bastion or Connector Host Inside the Customer Network

A common pattern is to place a small bastion or connector host inside the customer network. That host has access to the approved internal systems, and Reindeer reaches the bastion through the selected VPN or tunnel path.

The customer network team should define:

• Where the bastion or connector runs, such as a VM, server, container host, or cloud VM connected to the on-premises network.
• Which internal destinations it can reach.
• Which outbound or inbound network path is allowed between Reindeer and the bastion.
• Which ports and protocols are permitted from the bastion to each target system.
• Who owns patching, monitoring, restart behavior, and access review for the bastion.

Client VPN and Remote Access VPN

Client VPN tools such as OpenVPN, WireGuard-based VPNs, or managed remote access platforms can be useful for development, testing, or troubleshooting. They are usually not the right production path for automated workflows because they depend on user or device sessions and can be harder to operate consistently.

Use this pattern only for temporary or administrative access unless the customer explicitly approves it for production operations.

Private Endpoint and Peering Patterns

When both Reindeer and the customer system run in cloud networks, private connectivity may be possible through VPC/VNet peering, PrivateLink, Private Service Connect, or similar provider-specific mechanisms. These patterns avoid exposing services over the public internet and can be combined with private DNS and strict security groups or firewall rules.

Information Required from the Customer Security or Network Team

Reindeer should not be given broad network access by default. For each connectivity option, the customer security or network team should define the minimum required routes, hosts, ports, protocols, DNS behavior, and approval process before implementation. Credentials and secrets should be scoped to the specific workflow or connector that needs them.

Application Access After Network Connectivity

Network connectivity only establishes a path. The customer still controls application-level access. For each target system, define the user, service account, role, and credential policy that Reindeer agents may use.

For web interfaces, the customer security team should provide the login method, service account policy, MFA expectations, allowed roles, session timeout rules, and any IP or device restrictions. If MFA is required, the implementation should define whether the workflow uses a service account, delegated human approval, or another approved authentication pattern.

For AS/400 or IBM i environments, the integration team should confirm whether access is through TN5250/TN5250S, an API, database access, file exchange, or another interface. For TN5250-style access, provide the host, port, TLS requirement, terminal type, device-name policy if applicable, CCSID requirements, allowed user profile, and permitted menus or commands. TLS/TN5250S is preferred over plaintext Telnet where supported.

For APIs, databases, SFTP servers, or file shares, provide endpoint details, authentication method, allowed operations, service account ownership, credential rotation process, and audit requirements.

Security and Operational Checklist

Before enabling connectivity, confirm:

• Which systems Reindeer needs to reach.
• Required source and destination CIDR ranges.
• Required hosts, ports, and protocols.
• Authentication method for each target system.
• DNS resolution path for private hostnames.
• Whether traffic is initiated by Reindeer, by the customer network, or both.
• Whether a proxy or TLS inspection device is in the path.
• Logging and audit requirements.
• Monitoring and alerting ownership.
• Failover behavior for VPN or circuit outages.
• Key, certificate, and credential rotation procedures.
• Data handling and retention requirements.

Legacy and Fragmented On-Premises Environments

In environments built through acquisitions or long-running legacy programs, connectivity should be scoped one workflow at a time. Start by identifying the specific system of record, the required action or query, and the smallest network path needed for that workflow. Avoid creating a broad flat network connection to every internal system.

For legacy platforms, the security and infrastructure teams should also confirm whether access is through an API, database connection, file exchange, terminal protocol, message queue, SFTP location, or vendor gateway. Each access method may require a different routing, credential, and audit design.

Recommended Selection Guide

• Use site-to-site IPsec VPN for standard production access to on-premises systems.
• Use cloud-managed VPN when the customer already manages an approved cloud-to-on-premises connectivity path and wants Reindeer traffic to enter through that path.
• Use a dedicated private circuit when throughput, latency, or network-isolation requirements exceed what VPN can provide.
• Use an outbound-only connector when inbound connectivity from Reindeer is not allowed.
• Use client VPN only for temporary access, testing, or troubleshooting.
• Use private endpoint or peering patterns when target systems are reachable through a private network path and private routing is preferred.

Related Articles

• Building and Deploying Agents on Reindeer: CLI, Harness, and Runtime Overview
• Data Privacy, Isolation, and LLM Provider Controls
• Integrating Reindeer AI with Existing Enterprise Tools