SC.L2-3.13.7 Split tunneling: requirements and evidence

What SC.L2-3.13.7 split tunneling requires and why assessors check it

SC.L2-3.13.7 requires that a remote device connected to a CUI system cannot also reach external networks through a second connection at the same time. Picture a defense contractor whose engineers work from home over a VPN. The laptop is inside the corporate tunnel to the enclave, but its VPN client also sends general web traffic straight to the internet over the home network. That second path is the problem. Data can leave the device through a route the organization does not monitor, filter or log. The requirement is a derived control from NIST SP 800-171 Rev. 2, and it is one of the simplest items in the Level 2 set, but assessors still test it because it is easy to get wrong. The requirement carries a single assessment objective in NIST SP 800-171A (June 2018): remote devices must be prevented from split tunneling, meaning from connecting to the system while simultaneously communicating with external networks through another connection. It is worth 1 point under 32 CFR 170.24. Because it is a 1-point requirement and is not on the exclusion list in 32 CFR 170.21, it can go on a POA&M for Conditional Level 2 status if the total score is at least 88 of 110, with closeout due within 180 days. Confirm the current POA&M rules against the eCFR text before relying on them, since the Level 2 timeline has been changing.

The difficulty is rarely the setting itself. Endpoints are often configured by users, so a laptop may have a local firewall rule, a browser proxy or a personal VPN that bypasses the corporate tunnel. Many VPN clients expose a split tunnel option, sometimes enabled by default or by a profile pushed from a vendor template, and administrators may not know it is switched on. Split routing also appears by accident, for example when a home router advertises a route that wins over the tunnel, or when a client gets a route for a local subnet and forwards other traffic outside the tunnel. Assessors look for the configured mechanism on the VPN gateway and endpoints, the policy that enforces it, and evidence from testing that traffic from a remote device goes through the tunnel. Confirm with your VPN vendor which settings control split tunneling and whether the gateway can enforce full tunneling centrally.

Which remote devices, VPNs and teams fall inside split tunneling scope

Split tunneling scope starts with one question: which connections reach systems in the CUI assessment boundary. Each card below is a scoping decision that changes which devices, VPN configurations and people the split tunneling control must cover, and what evidence an assessor will ask to see.

Remote devices reaching the CUI boundary

Start with the system security plan's boundary diagram and list every path that lets a remote device reach a CUI system. Any device that can establish a non-remote connection to those systems falls inside SC.L2-3.13.7 scope, even if it is used only occasionally. Confirm that the boundary is drawn from actual network paths, not from intent, because a laptop that can reach a file share through a second route changes the answer.

VPN concentrators and client types

Inventory each VPN concentrator, gateway and client package that terminates remote sessions. The split tunneling setting often lives in the client profile, the concentrator policy or both, and a mismatch between them leaves a gap. Record which client versions and operating systems each profile covers so the assessor can see that the setting is enforced on every client type, not only on the reference build.

Managed versus personally owned devices

Company-managed endpoints can have full tunneling enforced through configuration policy and checked by endpoint management. Personally owned or unmanaged devices that connect to CUI systems are harder to control, so decide whether they are permitted at all. If they are permitted, document how the organization forces traffic through the VPN and how it verifies that the setting is active before a session opens.

Contractor and subcontractor access

Third-party staff and subcontractor personnel who reach CUI systems remotely are in scope when their devices or accounts touch the boundary. Their endpoints are often outside the organization's management tooling, which changes how the setting is enforced and evidenced. Put the split tunneling requirement into access agreements and confirm how the contractor's devices are checked, rather than assuming the subcontractor's own controls match.

Internal-only remote access

Decide whether remote sessions that reach only internal, non-CUI resources sit outside the CUI boundary. If a remote session can reach a CUI system at all, the requirement applies to that session, so a split tunnel that bypasses the VPN for general internet traffic still matters. Ask the assessor how they will treat remote access that is labeled internal, and confirm that the boundary definition matches how staff actually connect.

Evidence for each in-scope path

Scope decisions only help if each in-scope path has evidence of the setting. Plan a repeatable check, such as a configuration export from the VPN and endpoint policy records, and a test that a remote session cannot communicate with an external network through a second connection while connected. Keep the scope list and the evidence list in the same document so changes to either are visible during the assessment.

How an assessor tests split tunneling against objective 3.13.7

This table compares the four ways an assessor can test whether remote devices are prevented from split tunneling under the single NIST SP 800-171A objective for 3.13.7. Read each row as a test method, the evidence it asks for, and the gap that most often causes a finding. The main takeaway is that a configuration setting alone rarely satisfies the objective without a live session showing all remote traffic routed through the VPN.

Test approach	Evidence requested	Common findings
Review VPN and endpoint configuration	VPN server and client profile settings, endpoint policy exports showing split tunneling disabled, and the configuration baseline for remote devices	Split tunneling is disabled on the VPN server but the client profile on some laptops still permits it, or the setting is documented but not enforced on managed devices
Test a live remote session for simultaneous external connectivity	Observed session results with the remote device connected to the VPN, showing whether it can reach external addresses through a second connection while the tunnel is up	Assessor finds a remote device with a second active interface, such as a Wi-Fi or cellular connection, that reaches the internet outside the tunnel
Review boundary device and architecture documentation	Boundary protection procedures, system architecture diagrams showing where remote access terminates, and the hardware and software list for boundary devices	Architecture diagrams show the VPN concentrator but not the egress path for remote users, so the assessor cannot confirm that all traffic traverses the boundary
Check audit records	Audit records from the VPN or boundary device showing remote sessions and the routes or destinations they used, plus any logs of connections made outside the tunnel	No logs exist to show session routing, so the organization cannot demonstrate that the restriction operated during the assessment period

Evidence that passes split tunneling and how to keep it current

An assessor testing SC.L2-3.13.7 looks for proof that remote sessions cannot reach the organization and the internet at the same time. The artifacts below show the configuration, the endpoint state, the architecture and a dated record of a live test, and each one goes stale when the environment changes.

VPN and client configuration exports

Export the VPN server and client profiles showing that split tunneling is disabled and that a default route sends all traffic through the tunnel. Capture the firewall or VPN gateway settings alongside the client profile, because a server setting that is overridden by a client setting does not meet the objective. Keep the export with the file name, version and date of the configuration. After any change to routes, tunnel modes, client templates or gateway software, export again and replace the old file in the evidence folder, retaining the superseded version so the change history is visible.

Endpoint policy results

Show that managed endpoints enforce the tunnel requirement, for example through a policy that flags devices whose routing or network adapter settings allow a second path to external networks. A policy result is only useful if it shows the device name, the check, the pass or fail state and the date it ran. Check which devices are failing and record the remediation. Re-run the policy after every client build, OS update or group policy change, since a passing result from an older build does not prove the current one.

Boundary architecture diagrams

Provide a current diagram showing remote endpoints, the VPN gateway, the firewall, internal enclaves and the internet egress path, with the single path for remote traffic marked. Assessors compare the diagram to the configuration exports, so any mismatch, such as a diagram showing a split path that the export does not show, raises a finding. Version the diagram, state its approval date and update it whenever a gateway, egress point or remote access method is added or retired.

Live remote session test records

Record a test from a remote device that connects to the VPN and then attempts to reach an external address outside the tunnel, showing the attempt fails or is routed through the tunnel. Screenshots, command output and a test log with the tester, the device, the time and the result are the evidence. Only the final, signed or approved record counts; a draft or an unreviewed working copy will not satisfy the assessment objective. Repeat the test after configuration changes and keep each dated record rather than overwriting the earlier one.

Dated firewall and VPN audit records

Retain logs showing VPN sessions, the traffic they carried and any blocked attempts to reach external destinations from a remote session outside the tunnel. Confirm that the logging is enabled on the rule set that enforces the tunnel and that the logs are protected and retained for the period your assessment plan states. Ask your assessor or C3PAO which retention period they expect to see, and confirm the time stamps are synchronized across the gateway and the log store.

Refresh cycle and change control

Tie each artifact to a change record so that a configuration change triggers an update to the export, the endpoint policy, the diagram and the test record in one workflow. Assign an owner for each artifact and set a review date. Drafts stay out of the evidence package: move an artifact into final form only after review and approval, and keep the previous approved version. An assessor who finds a diagram or export older than the configuration it describes will treat the requirement as unproven.

Steps to implement split tunneling controls in a CMMC environment

This sequence takes an organization from knowing where its remote access enters the system to a documented, enforced setting that blocks split tunneling on every remote device, with evidence an assessor can review in final form.

Inventory every remote access path
The IT or network team lists each route by which a remote device reaches organizational systems: VPN gateways, remote desktop or virtual desktop brokers, zero trust access proxies, and any vendor or administrator access paths. For each path, record the gateway, the authentication method, the device types allowed, and the owner. The output is a remote access register that the rest of the sequence uses as its scope. Done when every path that can carry CUI sessions appears on the register and the owner has signed off.
Define the CUI boundary for remote sessions
The security team uses the system boundary documented in the system security plan to mark which systems hold or process CUI and which remote sessions reach them. This sets the point where split tunneling matters most. The output is a boundary diagram showing the remote access entry points, the internal enclaves they reach, and the external networks a remote device could otherwise reach. Done when the diagram matches the register from the previous step and the security lead has approved it.
Configure gateways and endpoints to route all traffic through the VPN
Engineers set the VPN or remote access client profile so that all traffic from the remote device, including general internet traffic, passes through the organizational tunnel. On the gateway, they confirm the route and policy settings, and on managed endpoints they apply the client configuration through the device management tool. Firewall rules on the gateway, such as OPNsense rules for pass, block and reject by source, destination, port and protocol, enforce the boundary for the tunnel. The output is a saved configuration export or screenshot for each gateway and client profile. Done when a test client receives the full-tunnel profile and no local exception routes remain.
Test for simultaneous external connectivity
A tester connects a managed remote device to the VPN, then attempts to reach external websites, public DNS and other external networks while the session is active, and also checks the device's routing table and active connections. The test should also cover a device that has a local network connection, such as a home router, to confirm that no second path exists. The output is a dated test record listing each attempted destination, the result, and the captured routing output. Done when no external connection succeeds outside the tunnel and the record shows the method used.
Enforce the setting across all remote devices
The endpoint team applies the full-tunnel profile to every device in the remote access register, and configuration management checks that unmanaged or personal devices cannot connect without it. Endpoint compliance tools can run a check that a device is passing a policy, for example a Fleet policy written as a yes or no query that shows which devices pass or fail. Wazuh Security Configuration Assessment can scan endpoints against YAML policies for misconfigurations and recommend remediation. The output is a compliance report showing the share of devices passing and a remediation list for those failing. Done when failing devices are either fixed or blocked from connecting.
Document the configuration in the system security plan
The compliance lead writes the split tunneling setting into the system security plan, naming the gateways, client profiles, enforcement method, responsible owners and the boundary diagram. The plan should reflect what the systems actually do, so the documentation is checked against the exported configurations and test records from earlier steps. The output is an updated system security plan section for SC.L2-3.13.7. Done when the plan describes the implemented state and the reviewer has confirmed it matches the configuration.
Collect final-form evidence for assessment
The team gathers the evidence an assessor will review: the boundary diagram, gateway and client configuration exports, dated test results, the endpoint compliance report, audit records of remote sessions where available, and the updated plan section. Each item should be in final form, not a draft, and dated and attributed to an owner. The output is an evidence package indexed to SC.L2-3.13.7. Done when every item is final and the compliance lead has checked that the package answers the single assessment objective for this requirement. Ask the independent assessor which evidence formats they accept before the package is finalized.

Self-hosted open-source tools that produce split tunneling evidence

Split tunneling is a configuration decision that spans the firewall, the endpoint and the device inventory, so the evidence is usually spread across several systems. The three tools below each show one slice of that picture: traffic rules and logs at the boundary, configuration checks on endpoints, and yes or no device policy results. None of them replaces the organization's own VPN client settings, which the organization must configure and document.

Firewall rules and rule-match logs

OPNsense is a stateful packet filter that passes, blocks or rejects traffic by source, destination, port and protocol. For SC.L2-3.13.7, the useful evidence is a rule set that forces remote client traffic through the VPN tunnel and blocks any path that would let a remote device reach external networks by a second route, with each rule match logged. Confirm in your own environment that the rules you export match the configuration your VPN client actually uses. Licensed under BSD-2-Clause.

Aliases and address groups

OPNsense aliases group remote client address pools, internal resources and permitted external destinations into named objects that rules reference. This makes the boundary easier for an assessor to read: one alias for the VPN pool, one for internal systems, and no alias that quietly grants general internet access to remote clients. Keep alias changes under change control so the rule history can be shown during the assessment. Confirm how your version exports alias definitions for the evidence file. Licensed under BSD-2-Clause.

Endpoint configuration checks

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports failed checks with remediation guidance. Organizations can add custom policies that check the settings used to prevent split tunneling on laptops, such as whether the VPN client forces full tunnel routing. The scan shows configuration state at a point in time, so schedule it and keep the reports. Confirm that your endpoint policy can read the specific client setting you rely on. Licensed under GPL-2.0-only, which applies to the agent and server software you distribute or modify.

Yes or no device policies

Fleet policies ask each enrolled device a yes or no question written as an osquery query, and the policies page shows which devices in each fleet pass or fail. A policy can ask whether the VPN client is running with full tunnel routing enabled, or whether a second active network interface with a default route exists while the VPN is connected. Failing devices give the organization a list to remediate, and the pass history shows the check was run. Confirm that your osquery tables expose the interface and route data your policy depends on. Licensed under MIT.

What meeting split tunneling costs in money and effort

This table compares the cost components of disabling split tunneling for SC.L2-3.13.7, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No price or duration is stated because none is supplied, so use the table to shape the questions you put to a quote. The main takeaway is that the configuration work is largely one-time, while evidence upkeep and endpoint enforcement recur.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to keep it down
VPN and firewall configuration	One-time build, paid to the implementation partner or internal engineers	Number of VPN gateways, remote access paths, and whether tunnel routing is set per group or per device	Use one documented tunnel policy and address groups in the firewall rule set so changes are made once
Endpoint policy tooling or licenses	Recurring if commercial, paid to the software vendor per device or per seat	Device count, operating systems in use, and whether the tool also covers other requirements	Confirm whether open-source agents already in use can enforce the routing setting and check the device list monthly
Engineering time for testing	One-time for the initial test, then periodic regression testing paid from internal or partner hours	Number of remote user profiles, client versions, and split tunnel exceptions requested by business units	Keep a short test script that confirms traffic to external sites traverses the VPN, and rerun it after client updates
Evidence upkeep	Recurring, paid from internal compliance or security staff time	How often configuration changes, and whether logs and screenshots are gathered on demand or continuously	Export firewall rule and endpoint policy results on a fixed schedule and store them in final form, not drafts
External review	Optional and recurring if used, paid to an independent consultant or partner for readiness checks	Number of remote access paths, complexity of the architecture, and how much of the evidence is new	Limit review to the remote access design and the evidence set, and ask for a written scope before work starts
Assessor time	Paid to the assessor during the assessment, typically a C3PAO for Level 2 certification or your own staff for self-assessment	Number of systems in scope, quality of evidence, and how quickly the assessor can verify configuration	Prepare a single evidence package that shows the routing setting, the tunnel rule and test results for the same remote devices

Who owns split tunneling controls, who can help, and where the assessor draws the line

Your organization owns SC.L2-3.13.7. It is accountable for deciding that remote devices must not split tunnel, for setting the policy, and for showing that the mechanisms enforce it on every device that connects to organizational systems. Those decisions cannot be handed to a vendor or consultant, and the assessor will ask the people who run the environment to explain them.

Policy decision: Record that split tunneling is disabled for remote access and that all traffic from remote devices, including internet traffic, must pass through the VPN.
System security plan entry: Describe how the requirement is implemented, which VPN and firewall components enforce it, and who maintains them.
Operational ownership: Assign an owner for VPN configuration, firewall rules and endpoint policy, and review changes through your change control process.
Staff knowledge: Make sure administrators can explain the setting and show it live during an assessment interview.
Ongoing checks: Schedule recurring verification that the setting still holds after upgrades, new device images and VPN client updates.

Before engaging anyone, confirm that your own team can name the owner of each mechanism and produce current configuration evidence without a consultant present.

Where organizations usually fail split tunneling and how to close each gap

Split tunneling failures rarely come from a missing policy. They come from one profile, one device class or one undocumented exception that quietly lets remote traffic leave the VPN. The cards below cover the gaps assessors most often find and the checks that close each one.

Split tunnel left on in one profile

Organizations often disable split tunneling in the main VPN profile but leave it enabled in a secondary profile, a legacy group or a client template used by one team. SC.L2-3.13.7 is tested across all remote access paths, so one permissive profile fails the requirement. Export every client profile from the VPN server and confirm that each one routes all traffic through the tunnel, including internet-bound traffic.

Unmanaged personal devices

A remote device that is not managed by the organization can run its own VPN client, bridge to a home network or keep a second internet connection active. Policy alone does not stop this. Limit remote access to managed endpoints, and use endpoint configuration checks to confirm that client settings and network adapters match the approved baseline before access is granted.

Undocumented exceptions

Some teams need local network access for printers, lab equipment or a vendor tool, and an informal exception becomes permanent. Assessors look for a written, approved exception with an owner, a business reason and a review date. Record each exception in the system security plan, and confirm that the boundary rules that permit it are tied to that record rather than to a general allow rule.

Evidence from a draft configuration

A screenshot of a VPN setting taken during design, or a configuration file that was never deployed, does not show what the live system does. Assessors accept final-form evidence only. Capture the running configuration from the production VPN server and endpoint policy, date it, and keep the export with the assessment package so it matches what users actually connect with.

No test of a live session

Reviewing settings does not show that split tunneling is blocked in practice. The assessment objective concerns whether a remote device can connect to the system while also communicating with external networks through another connection. Connect a test device to the VPN, attempt an outbound request to an external address through the local connection, and record that it fails. Repeat this after each client or policy change.

Split tunneling questions buyers ask before hiring outside help

How much does it cost to disable split tunneling for CMMC SC.L2-3.13.7?

The configuration change itself is often small, but the total cost depends on what you already run and who does the work. Costs come from three places: your internal staff time to inventory remote access paths, the VPN and firewall changes, and any outside partner fees for a fixed-scope engagement. Recurring costs include reviewing policy exceptions and keeping endpoint evidence current. The 32 CFR 170.24 scoring treats this requirement as 1 point, which tells you the assessment weight, not the price. Ask any partner for a written scope listing each system affected, the deliverables and what you must supply, then compare quotes on that basis. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does it take to implement split tunneling controls?

The duration depends mainly on how many remote access paths and device types you have, not on the requirement itself. Timelines usually stretch when VPN configurations are spread across several gateways, when remote users rely on local services that a full tunnel will break, or when change control requires approvals. No duration figure is supplied for this requirement, so ask a partner to state the phases, dependencies and client-side tasks in the written scope. Plan time for a test window where remote staff confirm that business applications still work through the tunnel.

What does my team need to provide when a partner disables split tunneling?

Your team must provide access to the VPN gateway, firewall and endpoint management consoles, a current list of remote access methods, and a named owner who can approve changes to production access. Engineers also need the list of applications that remote users depend on, so the change does not block legitimate work. Expect to supply screenshots or exports of current configuration as baseline evidence. Confirm in the scope which of these items the partner needs and which your staff will perform themselves.

Can our internal IT team implement split tunneling controls without outside help?

Yes, many internal teams can make this change, provided they have administrative access to the VPN and endpoint policies and can test the result. The harder part is evidence: the assessor will look for configuration, boundary and architecture records that show the restriction is enforced on every remote device. If your team has not documented this before, an outside partner can help define the evidence set. Whether to bring in help depends on your staff capacity and whether they can produce evidence an independent assessor will accept. The organization owns its controls, and only an independent assessor issues a conclusion.

Can we put SC.L2-3.13.7 on a POA&M instead of fixing it now?

Under 32 CFR 170.21, SC.L2-3.13.7 is a 1-point requirement not on the exclusion list, so it may be placed on a POA&M for Conditional Level 2 status if your score is at least 88 of 110, with closeout due within 180 days. Treat this as a short-term option, not a plan. Your overall score must still meet the threshold, and a deferred control still needs a documented plan and a real closeout date. Because the CMMC phase schedule is in flux, confirm current status with your contracting officer and the DoW CIO guidance before relying on a POA&M.

What should we ask a partner to include in a written scope for split tunneling?

A useful written scope names the systems in scope, the remote access paths covered and the specific configuration changes. It should also list the evidence the partner will prepare, such as boundary protection procedures, configuration exports, architecture diagrams and audit records, mapped to the assessment objective in NIST SP 800-171A. Ask who tests the change, how user disruption is handled, what is excluded, and what you must supply. Confirm whether the partner prepares evidence only or also supports ongoing review. DeployOpen plans and implements these changes under fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts.

Which open-source tools help show that split tunneling is blocked?

OPNsense can enforce stateful rules by source, destination, port and protocol and can log each rule match for review, which supports boundary evidence. Wazuh Security Configuration Assessment can check endpoint configuration against YAML policies, and Fleet policies can show which devices pass or fail a yes or no check written as an osquery query. Confirm with each vendor that the specific check you need is supported in your version before you commit to it. Your team owns the decision on which tools fit your environment, and an independent assessor determines whether the evidence meets the objective.

How DeployOpen works on this

DeployOpen approaches SC.L2-3.13.7 Split tunneling as an engineering and evidence task inside your own infrastructure. We set up the remote access path so that remote devices cannot reach organizational systems and external networks through a second connection at the same time, then document how an assessor can verify it.

How we scope

Inventory every remote access path, VPN gateway and remote device class that touches systems in the CUI boundary.
Agree in writing which devices, operating systems and tunnel configurations the fixed scope covers and which it excludes.
Confirm with your assessor or auditor which evidence types they expect for the single assessment objective of 3.13.7.

How we build

Configure the VPN and endpoint settings so all traffic from remote devices routes through the tunnel, with no local internet breakout.
Enforce deny-by-default outbound rules at the gateway using OPNsense aliases and rule logging for the remote access segment.
Test split tunneling from a managed remote device and confirm that a parallel external connection is blocked, then record the results.

How we hand over

Deliver configuration exports, rule sets and network diagrams showing where the tunnel boundary sits and how it is enforced.
Provide test scripts, screenshots and log excerpts that show the blocked parallel connection, with dates and the tester named.
Map the artifacts to the 3.13.7 entry in your system security plan so the organization can review and own the final evidence.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-check split tunneling settings after VPN client, gateway or endpoint policy changes, using scheduled Fleet policy queries where your environment supports them.
Ask your assessor, not DeployOpen, for any formal finding. Independent auditors and certification bodies issue reports and certificates.