Policy and Routing Design for Dual-Use Tactical 5G Networks with Classified and Unclassified Separation

Tactical 5G network segregation is one of the harder architectural problems in deployed federal and defense environments. It is not simply a matter of configuring separate SSIDs or applying access control lists at the edge. When a single physical infrastructure must carry both classified and unclassified traffic simultaneously, the design decisions made at the enclave boundary, the routing layer, the management plane, and the gateway directly determine whether the network is operationally viable or a latent cross-domain risk waiting to surface during an assessment or, worse, an actual spill event.

The challenge is compounded in tactical deployments where infrastructure is shared, staffing is lean, and the operational tempo does not allow for extended troubleshooting windows. A design that works cleanly in a lab environment can break down quickly when a unit is operating from a forward location with a single network engineer managing both the classified and unclassified stacks simultaneously. The architecture has to enforce separation by design, not by discipline alone.

This article addresses the specific problem of dual-use tactical 5G and WWAN environments where classified and unclassified missions share physical transport, radio access infrastructure, or core network components. The focus is on routing policy, enclave topology, traffic classification, firewall and gateway placement, management-plane isolation, and the operational controls that prevent cross-domain spill. This is distinct from general control-plane and user-plane separation, which is a 5G core architecture concept, and from WAN failover path steering, which is a resilience concern. The problem here is domain separation under shared infrastructure constraints.

Federal and DoD architects working in this space are navigating requirements from multiple directions at once: mission owners who need connectivity across classification levels, program offices managing a single equipment budget, cybersecurity personnel responsible for maintaining authorization boundaries, and assessors who will scrutinize every routing table and firewall rule during an RMF review. Getting the architecture right from the start reduces risk across all of those stakeholder groups.

Enclave Topology and Trust Boundary Design

The starting point for any dual-use tactical 5G architecture is a clear, documented enclave topology that defines where each classification domain begins and ends, what physical or logical components sit within each domain, and where the trust boundaries are enforced. This sounds straightforward, but in practice the topology is often ambiguous at the edges, particularly where shared transport or shared radio access infrastructure creates a gray zone between domains.

In a tactical 5G deployment, the radio access network typically consists of a base station or small cell array connected to a mobile core. The mobile core handles session management, user plane functions, and policy enforcement. When the deployment must support both classified and unclassified missions, the question is where in that stack the domain separation is enforced. Separating at the radio layer is expensive and operationally complex. Separating at the core is more practical but requires the core architecture to enforce isolation reliably across all sessions.

A common approach is to define two logical enclaves that share physical transport and radio infrastructure but maintain separate user plane function instances, separate data network names, and separate IP address spaces. The classified enclave terminates into a classified gateway with its own routing domain. The unclassified enclave terminates into a separate gateway with no routing adjacency to the classified side. The physical transport between the radio access network and the core carries both traffic streams, but they are separated by VLAN tagging or equivalent encapsulation from the point of origin.

The trust boundary is not just a logical construct. It has to be represented in the network diagram, the system security plan, and the actual device configuration. Assessors will ask where the boundary is enforced, what controls prevent traffic from crossing it, and how the organization detects a crossing event. If the answer to any of those questions is “we rely on configuration discipline,” the architecture has a documentation and assurance problem even if the configuration is currently correct.

Enclave topology decisions also affect how the network scales. Adding a new mission partner, a new user group, or a new application to the classified enclave should not require changes to the unclassified enclave’s routing or firewall policy. Designing the enclaves to be independently extensible reduces operational risk during the lifecycle of the deployment.

VRF and Routing Policy Isolation

Virtual routing and forwarding instances provide logical routing table separation within a single physical device. In a dual-use tactical network, VRFs are a practical mechanism for keeping classified and unclassified routing domains isolated at the infrastructure layer without requiring fully separate routing hardware for every segment. The classified enclave operates in one VRF, the unclassified enclave operates in another, and the global routing table is reserved for management or transport functions that are themselves isolated from both mission domains.

The critical design requirement is that route leaking between VRFs must be explicitly prohibited. Route leaking is the intentional or accidental redistribution of routes from one VRF into another. In a commercial enterprise context, controlled route leaking is sometimes used to allow shared services to be reachable from multiple VRFs. In a classified and unclassified dual-use environment, any route leaking between the two mission VRFs is a potential cross-domain exposure. The design must default to no leaking, and any exception must be explicitly authorized, documented, and technically enforced through route policy filters rather than left to operator discretion.

Route advertisement controls extend beyond the VRF boundary. If the tactical network connects to a wider area network, the routing protocol configuration must ensure that classified enclave prefixes are never advertised into unclassified routing domains and vice versa. This requires explicit route filtering at every peering point, not just at the edge of the tactical deployment. A route filter that exists at the tactical core but is absent at an upstream aggregation point creates a gap that may not be visible from within the tactical environment.

Traffic Classification at the Data Plane

Traffic classification in a 5G environment relies on the data network name assigned to each PDU session, the user plane function instance handling the session, and the VLAN or tunnel encapsulation applied to the traffic as it traverses the transport network. The classified enclave’s traffic should be identifiable at every hop by a consistent marking or encapsulation that allows infrastructure devices to enforce routing and forwarding policy without inspecting the payload.

Where VLAN tagging is used, the VLAN assignment must be consistent from the radio access network through the core and out to the gateway. A VLAN misconfiguration at any intermediate device can cause classified traffic to be forwarded into the unclassified path. This is not a theoretical risk. It is the kind of failure that occurs during maintenance windows, equipment replacements, or configuration pushes that touch multiple devices simultaneously. The operational procedure for any configuration change that affects VLAN assignments must include a verification step that confirms traffic is still reaching the correct enclave gateway before the change is closed out.

Deployment Patterns by Cross-Domain Connectivity Requirement

Not all dual-use deployments have the same cross-domain connectivity requirements. Some environments prohibit any connectivity between the classified and unclassified enclaves. Others permit tightly mediated data transfer through an approved mechanism. A small number of environments operate under temporary authorizations that allow limited cross-domain connectivity for a specific mission period. The routing and VRF design should reflect which of these patterns applies, because the architecture is materially different in each case.

Firewall and Gateway Placement at the Domain Boundary

Firewall placement in a dual-use tactical 5G network is not simply about where to put a device. It is about what the firewall is authoritative for, what it can see, and what happens when it fails. Each enclave boundary requires a firewall that enforces a default-deny policy for traffic attempting to cross between classification domains. The firewall must be positioned so that no traffic path exists between the classified and unclassified enclaves that does not pass through it.

In practice, this means the firewall sits between the enclave gateway and any shared transport segment. Traffic from the classified user plane function exits through the classified gateway, passes through the classified enclave firewall, and reaches its destination within the classified domain. It never touches the unclassified gateway or the unclassified routing domain. The same logic applies in reverse for unclassified traffic. The two firewalls are separate devices or separate logical instances with no shared policy configuration.

Fail-closed behavior is a design requirement, not a configuration option. If the classified enclave firewall loses power, loses its configuration, or enters a fault state, the default behavior must be to drop all traffic rather than to pass traffic in an uncontrolled state. This requires explicit configuration and testing. Many firewall platforms default to fail-open behavior for availability reasons. In a classified enclave boundary, that default is not acceptable and must be overridden during initial configuration and verified during operational testing.

Gateway design affects both security and operational continuity. A classified enclave gateway that is sized only for current traffic loads with no redundancy creates a single point of failure for classified mission traffic. Redundancy within the classified enclave is acceptable and encouraged, but the redundant path must remain within the classified domain. Failover to an unclassified path is not an acceptable continuity mechanism regardless of operational pressure.

Management-Plane Separation and Operational Controls

The management plane is the most consistently underdesigned aspect of dual-use tactical 5G networks. Architects spend significant effort on data-plane separation and routing policy, then connect both the classified and unclassified infrastructure to a shared out-of-band management network, a shared element manager, or a shared credential store. That shared management plane creates a lateral movement path between the two domains that bypasses all of the data-plane controls.

Management-plane separation means that the devices serving the classified enclave are managed through a management network that is itself classified or at minimum physically and logically separate from the management network used for unclassified infrastructure. Jump hosts, management consoles, and network management systems for the classified enclave must not be accessible from the unclassified management network. Credentials used to manage classified infrastructure must not be shared with or reusable on unclassified infrastructure.

In a tactical deployment with a small team, this creates real operational friction. A single network engineer who manages both the classified and unclassified stacks must physically or logically switch between two separate management environments to perform routine tasks. That friction is real, but it is the correct operational posture. Attempts to reduce that friction by bridging the management planes introduce risk that is disproportionate to the convenience gained.

Logging and auditing requirements for dual-use networks are more demanding than for single-domain environments. Every configuration change to a device that participates in either enclave is a security-relevant event. Log collection must be separated by domain, and the log management infrastructure for the classified enclave must reside within the classified domain. Forwarding classified enclave logs to an unclassified log aggregator is a data handling problem regardless of whether the log content is itself classified.

Operational controls for preventing spill extend beyond the technical architecture. Procedures must address what happens when a user reports that a device connected to the wrong enclave, what the escalation path is when a routing anomaly is detected, and how the team confirms that traffic is flowing through the correct enclave gateway after a configuration change. These procedures should be written, rehearsed, and available to the team without requiring access to a system that might itself be unavailable during an incident.

For organizations building out or evaluating their Tactical 5G and WWAN architecture, management-plane design decisions made early in the program are difficult and expensive to correct after deployment. The cost of getting this right during the design phase is a fraction of the cost of remediating a management-plane exposure discovered during an assessment or after an incident.

Cross-Domain Transfer Mechanisms and Exception Handling

Some tactical environments require the ability to move specific data between the classified and unclassified enclaves under controlled conditions. This might be a mission summary that needs to be shared with an unclassified partner, sensor data that is collected on the classified network but needs to be aggregated in an unclassified system, or operational reporting that must flow from a classified source to an unclassified destination. When this requirement exists, it must be addressed through an approved cross-domain solution, not through ad hoc network configuration.

Approved cross-domain solutions are purpose-built systems that enforce content inspection, data filtering, and transfer logging between classification domains. They are not firewalls. They are not VPN gateways. They are not file transfer servers. They are specifically designed and evaluated for the cross-domain transfer mission, and their use requires authorization from the appropriate authority. The design of the tactical 5G network must account for where the cross-domain solution sits in the topology, how traffic reaches it from the classified enclave, and how the output is delivered to the unclassified enclave without creating a direct routing path between the two domains.

Exception handling is the operational process for managing requests to move data across the domain boundary that fall outside the normal cross-domain solution workflow. In a tactical environment, these requests often arrive under time pressure. The operational procedure must define who can authorize an exception, what technical controls are applied during the exception period, how the exception is documented, and when the exception expires. An exception that is granted verbally, implemented by modifying a firewall rule, and never documented is not an exception. It is an unauthorized configuration change that creates an undocumented cross-domain exposure.

The architecture should also address what happens when the cross-domain solution is unavailable. If the cross-domain solution goes offline, the correct behavior is that cross-domain transfers stop until the solution is restored. The architecture must not include a fallback path that allows transfers to continue through an unapproved mechanism when the approved mechanism is unavailable. That fallback path, even if it is intended as temporary, becomes a persistent vulnerability once it exists in the configuration.

Common Mistakes

The most consequential mistake in dual-use tactical 5G design is treating the architecture as complete once the data-plane separation is configured. Organizations that invest heavily in VRF design and firewall placement but leave the management plane shared are building a network that looks secure in a diagram but has a significant operational exposure. The management plane is where administrators actually touch the network, and a shared management plane means that a compromise or misconfiguration on the unclassified side can affect classified infrastructure.

A related mistake is assuming that VLAN separation is sufficient without validating that the VLAN assignment is enforced consistently across every device in the path. VLANs are a logical construct. They are only as reliable as the configuration of every switch, router, and gateway that handles the tagged traffic. A single device with an incorrect trunk configuration or a missing VLAN filter can silently forward classified traffic into the unclassified path. This type of failure is often invisible until a traffic analysis or an audit reveals it.

Organizations frequently underestimate the operational burden of maintaining two separate management environments. When that burden becomes unsustainable, teams begin looking for shortcuts. The shortcuts typically involve bridging the management planes in ways that were not authorized and are not documented. This is not a staffing problem that can be solved by adding personnel. It is a design problem that requires the management architecture to be operationally sustainable from the beginning.

Treating the RMF authorization as the end state rather than the starting point is another common failure. An authorization documents the security posture of the system at a point in time. In a tactical environment, the configuration changes, equipment is replaced, and software is updated. Each of those changes has the potential to affect the domain separation controls. Organizations that do not maintain continuous configuration management and change control for their dual-use networks will find that the authorized configuration and the operational configuration diverge over time, sometimes significantly.

Finally, organizations often fail to plan for what happens when the cross-domain solution is unavailable or when an exception request arrives under operational pressure. Without documented procedures and pre-authorized response options, teams improvise. Improvised cross-domain transfers in tactical environments are a primary source of spill events. The procedure for handling these situations must exist before the situation arises, not after.

Recommended Federal Approach

Start with a mission requirements analysis that identifies every user group, application, and data flow that will operate on the network, and assigns each one to a classification domain. This analysis should be done before any architecture decisions are made, because the number of classification domains, the traffic patterns between them, and the cross-domain transfer requirements all affect the fundamental design choices. A network designed for two enclaves with no cross-domain connectivity is architecturally different from one designed for two enclaves with an approved transfer mechanism.

Engage the authorizing official and the ISSO early in the design process. The enclave boundary definitions, the VRF design, the firewall placement, and the management-plane architecture all have authorization implications. Waiting until the system is built to involve the cybersecurity team creates rework risk and can delay authorization. The cybersecurity team’s input on what controls are required and how they will be assessed should shape the architecture, not be applied to it after the fact.

Design the management plane with the same rigor applied to the data plane. Define separate management networks for each classification domain, assign separate credentials and access controls, and document the management architecture in the system security plan with the same level of detail as the data-plane architecture. Verify that no management path crosses the domain boundary before the system is declared operational.

Conduct operational testing that goes beyond connectivity verification. Test fail-closed behavior on every enclave boundary firewall. Test that classified traffic cannot reach the unclassified gateway under fault conditions. Test the configuration change procedure to verify that the verification step catches VLAN or routing errors before they are closed out. Test the exception handling procedure with a simulated time-pressure scenario to verify that the team follows the documented process rather than improvising.

Establish configuration change controls before the system enters operation. Define which configuration changes are security-relevant, who must review them, how they are documented, and how the post-change state is verified. Apply these controls consistently across both enclaves. A change control process that applies to the classified enclave but not to the unclassified enclave creates an asymmetric risk posture that will surface during an assessment.

Plan for sustainment from the beginning. The team that operates the network after deployment may not be the same team that designed it. The architecture documentation, the operational procedures, and the configuration baseline must be complete enough that a qualified network engineer who was not involved in the original design can operate and maintain the network without introducing cross-domain risk. That standard of documentation is higher than what most programs produce, but it is the correct target for a dual-use classified environment.

Review the configuration baseline on a defined schedule, not only when an assessment is approaching. Routing tables, firewall rule sets, VLAN assignments, and management-plane configurations should be compared against the authorized baseline at regular intervals. Discrepancies should be investigated and resolved, not simply accepted as operational drift. In a dual-use network, configuration drift is a security event, not a maintenance backlog item.