A lab WAN from one VLAN: flat segment or routed transport

One managed switch and a spare VLAN will give you two VPN gateways talking across an isolated segment in an afternoon. What that segment proves is narrower than what people expect from the word WAN. It reproduces a direct Ethernet path, which is useful, and it omits nearly everything the internet does to packets on the way. Choosing between a flat segment and a routed lab transport is really a question about which behaviours you intend to test.

Two designs, two different lessons

A flat segment puts both WAN interfaces and a test host in one VLAN, with addresses from the same prefix. Everything reaches everything directly, and the only thing between the gateways is the switch. That is a real topology, just not a very interesting one.

A routed transport adds a lab router and at least two segments, so the gateways sit on different subnets with a default gateway in between. That arrangement costs another device and a routing table, and it buys the behaviours a single broadcast domain cannot produce.

What the flat segment proves

It proves reachability, authentication, proposal agreement, and that traffic enters and leaves the tunnel where you expect. Those are the failures that consume most troubleshooting time, and a flat segment finds them without any routing complexity in the way. If the tunnel will not come up here, no amount of internet realism will help.

It is also the right shape for a repeatable baseline. When a later test fails, you can rerun the flat case and know whether the change or the new condition caused it. Write the baseline down with its addresses, because you will need to rebuild it later.

What routing adds

Different WAN subnets mean the gateways have to route rather than address each other on-link, which is where default-gateway mistakes and asymmetric return paths appear. Intermediate filtering and a hop in between let you test what happens when a path is not direct.

The cost is more places to be wrong. Every extra device is another configuration that can disagree with the drawing, and a lab that nobody can rebuild from notes stops being a lab. Keep the router's configuration in those notes rather than only in its running state.

What neither design reproduces

Carrier translation is the big omission. A gateway that works on-link can fail behind address translation, and a flat segment has no translation at all. Changing source addresses, a cellular handover and the queuing that makes a call stutter are equally absent.

Path size is the second omission. A lab with one switch and one router almost never produces the smaller maximum size that a real path imposes, so a fragmentation bug stays hidden until the equipment reaches a site. That gap explains how a tunnel passes every lab test and still fails at the first installation. It also sets expectations for what the lab is allowed to promise.

Add one condition at a time when the exercise needs it, and keep a run without that condition as the baseline. Otherwise a failure gets blamed on an internet behaviour the lab never implemented. Label each run with the condition it added, or the baseline stops meaning anything.

Keeping the lab bounded

Use an approved private range that does not overlap production and record the assignment. Documentation ranges are examples for diagrams, not addresses for a working lab, and an overlap discovered later produces a routing fault that looks like a VPN bug.

Keep the test client's position visible. A host on the private side exercises a different path from a host on the simulated WAN, and an accidental switch interface or second uplink can bypass the firewall you meant to test. A drawing with the client position marked prevents most of those surprises.

Before any of the equipment goes back to a real uplink, remove the lab-specific configuration and have the production owner review it. A segment is valuable because its behaviour is known and bounded, which is exactly what makes it unsafe to carry into production unchanged.