VirtualBox Ubuntu 22.04: Is it safe to switch between NAT and Bridged networking using two adapters and ip route without rebooting?

by

Summary

A user reported slow download speeds when using VirtualBox’s Bridged networking mode on an Ubuntu 22.04 VM compared to NAT mode. To avoid the time-consuming process of rebooting the VM to switch modes, they implemented a workaround involving two virtual NICs (one Bridged, one NAT) and manually switching the default route using ip route. While functional, this approach introduces significant stability and reliability risks. The root cause of the slowness is likely MTU mismatch or packet filtering on the physical interface, but the proposed fix violates standard networking principles by relying on an unmanaged, static routing configuration that breaks essential services like DHCP and DNS.

Root Cause

The user’s issue stems from a performance discrepancy between VirtualBox network modes, and their solution creates a fragile network stack.

  • Performance Degradation in Bridged Mode:

    • MTU Mismatch: The physical network adapter (on the host) likely has a standard MTU of 1500, but the VirtualBox bridged driver or the underlying switch infrastructure might be fragmenting packets or dropping larger frames (Jumbo Frames) if not configured correctly.
    • Promiscuous Mode Overhead: Bridged mode requires the host interface to process promiscuous traffic, which can increase CPU load and latency on older hardware or drivers.
    • Driver/Protocol Issues: IPv6 Router Advertisements or specific offloading features (like GRO/GSO) on the host NIC might conflict with VirtualBox’s bridged packet injection.

  • Fragility of the Workaround:

    • Broken DHCP: Manually setting routes via ip route replace does not trigger a DHCP renewal. The VM retains the IP lease obtained when the interface came up. If the lease expires, the IP may be lost, or the static route may point to a stale gateway.
    • Bypassed NetworkManager: Ubuntu 22.04 relies heavily on NetworkManager. By bypassing it for routing decisions, the user creates a “split-brain” scenario where the UI (nm-applet) shows one state (e.g., “Connected to Bridged”), while the actual routing table is pointing to the NAT interface.
    • DNS Failure: When switching the default route to the NAT interface, the VM might still be trying to resolve DNS queries via the DNS servers learned on the Bridged interface (or /etc/resolv.conf might be static), leading to intermittent resolution failures if the NAT gateway’s DNS differs.

Why This Happens in Real Systems

Network engineers often encounter scenarios where “dual-homing” a system seems like a logical solution for traffic segmentation. However, asymmetric routing and stateful firewalls make this dangerous.

In this specific case, the user is forcing all outbound traffic (default route) through NAT, while the Bridged interface remains active. If an incoming connection arrives on the Bridged interface (e.g., an SSH session from a LAN client), the return traffic is forced out the NAT interface due to the default route. The remote LAN client will drop the packet because it expects a reply from the Bridged IP, not the NAT IP. This results in “hanging” connections and timeouts.

Real-World Impact

Implementing this dual-NIC + static route approach long-term carries several risks:

  • Connection Drops: Existing TCP sessions (SSH, SCP) will break the moment the user switches the default route.
  • Service Unavailability: Services listening only on the “active” interface IP will be unreachable on the other. For example, a web server listening on the Bridged IP will be invisible to the internet if the default route is on NAT, and vice versa.
  • Software Updates Fail: apt update might fail if the DNS server configured for the current default route is unreachable or if the routing table causes a loop.
  • VPN Incompatibility: VPN clients (OpenVPN/WireGuard) manipulate routing tables aggressively. A manual static route will be overwritten or conflict with the VPN, causing the tunnel to fail or leak traffic.

Example or Code

The user’s proposed method uses raw ip commands. While functional, it lacks context awareness. Below is the command structure used, which highlights the manual nature of the fix.

# Switch default route to Bridged (Manual Static Configuration)
sudo ip route replace default via  dev enp0s3

# Switch default route to NAT (Manual Static Configuration)
sudo ip route replace default via  dev enp0s8

Note: This code bypasses the OS’s standard connection management logic.

How Senior Engineers Fix It

Instead of relying on manual routing hacks, a senior engineer would address the root performance issue or use policy-based routing.

  1. Fix the Bridged Performance: The correct fix is to solve the slowness, not work around it.

    • MTU Adjustment: Reduce the MTU on the Ubuntu VM’s Bridged interface to 1400 or 1500 to prevent fragmentation issues. 
      sudo ip link set dev enp0s3 mtu 1450
    • Disable Checksum Offloading: VirtualBox often fails with hardware offloading. 
      sudo ethtool -K enp0s3 tx-checksumming off

  2. Policy-Based Routing (PBR): If dual-homing is strictly required for traffic types (e.g., LAN traffic via Bridged, Web traffic via NAT), use IP Rules and multiple routing tables, not just the main table.

    • Mark packets based on source or destination.
    • Create a dedicated routing table for the NAT interface.
    • This ensures that even if the default route is Bridged, specific traffic can be forced through NAT without breaking connection states.

  3. Use netplan or NetworkManager: Define the interfaces in /etc/netplan/ with specific metrics. Give the Bridged interface a lower metric (higher priority) for general traffic, but use policy definitions within Netplan to route specific ports or IPs via the NAT interface.

Why Juniors Miss It

Junior engineers often prioritize immediate “it works” results over system stability and long-term maintainability.

  • Obsession with Commands: They focus on learning specific CLI commands (ip route) rather than understanding the abstraction layers (NetworkManager, Netplan, DHCP client behavior).
  • Ignoring the OSI Model: They treat “internet access” as a binary state (works/doesn’t work) rather than checking layers 1 through 4. They often forget that DNS (Layer 7) relies on IP routing (Layer 3), and changing the default gateway without updating DNS settings causes silent failures.
  • Procedural Thinking: They solve the specific symptom (slow download) rather than the architectural constraint (why is Bridged slow?). A senior engineer investigates the cause of the slowness; a junior engineer finds a shortcut to bypass it.