Virtual routers and separate networks: limiting the impact of an incident

Series II: From infrastructure to agentic projects in production. Episode 03 of 20.

In the previous episode, we chose where the components of a fictional B2B requests and documents portal might run. Now we decide which components may communicate. The main decision is not how many networks to draw, but which connections each function needs and where to block all others. Useful segmentation reduces the paths through which an incident could spread, but its effectiveness depends on configuration and testing.

What a virtual router, a VLAN and a firewall do

A virtual router is software that usually runs in a virtual machine and directs traffic between networks. It may include a firewall, which applies rules allowing or blocking connections by source, destination, protocol and port. pfSense is one example of a product that can run in a virtual environment; mentioning it illustrates an option, not a universal recommendation.

A VLAN logically separates traffic over shared switching infrastructure. It helps organize zones, but a VLAN tag does not itself decide which connections are accepted between them. Rules must be applied along the traffic's actual path. Furthermore, two processes in the same network or on the same host can communicate without crossing the router between VLANs. Host or container platform rules may be necessary there. Netgate's documentation also highlights risks from misconfigured ports and untagged traffic.

By segmentation, we mean both separating zones and enforcing policy at their boundaries. NIST treats segmentation, traffic control, path redundancy and monitoring as parts of secure virtual network configuration. An academic study on protecting local networks explains why monitoring only the internet link can miss traffic moving inside a network. That is a reason to consider internal controls, not proof that any particular topology stops every attack.

Zones for our example portal

Hypothetical scenario: a company receives requests through the portal's public interface, processes them in an API and stores documents in a separate service. The team uses AI development agents to write code and run tests; the portal might later use an integrated agent to propose a request category. These agents serve different purposes. They should not automatically share a network zone or be treated as having identical rights.

We propose five working zones: a public entry point for the interface, an application zone for the API and its processes, a data zone for the database and documents, a management zone for operators, and a development and testing zone for the team's tools. If the integrated agent runs separately, we inventory its own connections to the API and any model provider. We do not give it a direct route to the entire data zone simply because it is part of the portal.

The zones can be implemented with VLANs, virtual networks, dedicated interfaces or a cloud provider's controls. The precise form depends on the environment chosen in the first two episodes. The principle is the same: allow only justified flows and check where packets actually travel. A private database is not secure solely because its address is not public.

In a hybrid architecture, the link between the company's site and the cloud is another boundary to track. A protected tunnel does not justify giving every system on one side access to every system on the other. Inventory the connection endpoints, rules in both environments, and who can change routing. If the link fails, the portal should behave predictably for users.

The minimum traffic matrix

Before implementation, the team describes flows in a matrix. The ports below are illustrative; the real ones must be confirmed against the application configuration, including supporting services. “Allowed” means a rule restricted to the stated destination and purpose, not general access to a zone.

A VPN is a protected private connection for operator access. The table is not a complete rule set: DNS, time synchronization, updates, monitoring and backups may need their own flows. Add each with a destination, port, reason and owner. Internet egress deserves the same scrutiny as ingress: a development agent may need a code repository and a model service, but not unrestricted access to production networks. The agent integrated into the portal may need a different destination list. Network restrictions do not replace identities and permissions, which the next episode addresses.

What to verify before claiming isolation

Start with a default deny policy: only documented traffic is allowed, while the rest is blocked. Do not assume that installing a product automatically applies this policy everywhere. For example, Netgate describes configurations that allow outbound LAN traffic by default. Check the effective rules on every interface, including automatic exceptions and IPv6 traffic.

The test has two parts. Confirm that legitimate flows work, then attempt connections from each zone that must be rejected: public interface to management, development environment to the production database, and portal agent to unapproved services. Examine the logs and repeat the test after changes. A failed connection can have many causes; the log and traffic path help show that the intended rule acted. On the same host, also check the hypervisor's virtual network, network bridges and any process or container policies.

A virtual router also creates an operational dependency. If it runs on the same host as the portal, stopping that host may interrupt both the application and routing. Keep a protected configuration backup, controlled recovery access and a rollback plan for mistaken rules. Design and test redundancy if availability requirements justify it; two interfaces on a diagram do not automatically make a resilient system.

The practical output is a map of zones and real paths, accompanied by the source, destination, port, reason and owner matrix. For every exception, record who approves it, when it will be reviewed and how to test its removal. This gives the team a verifiable basis for implementation and incident analysis without promising perfect isolation. In the next episode, we will define the identities and secrets that authorize these connections.

Sources

• NIST SP 800-125B, Secure Virtual Network Configuration for VM Protection (March 2016), on segmentation, firewalls, redundancy and monitoring.
• Netgate, Virtualization and VLANs and Security, documentation checked on October 5, 2026.
• Netgate, Firewall Rule Best Practices, on default deny and LAN configuration.
• Rietz et al., An SDN-Based Approach to Ward Off LAN Attacks, Journal of Computer Networks and Communications (2018), academic context on internal traffic and the limits of perimeter monitoring.

Next step

Want to review your network separation and data access paths? Talk with i8 about a flow map and a testing plan.