Bridged networking creates direct layer-2 connectivity between the VM and physical network, while NAT establishes a private network behind the host's IP. This fundamental architectural difference explains why bridged VMs are reachable from other LAN devices but NAT VMs aren't.

Consider this simplified network diagram for NAT:

Internet Router (192.168.1.1)
       |
Host Machine (192.168.1.100) 
       | NAT Gateway (192.168.122.1)
       |
VM (192.168.122.100)

Versus bridged mode:

Internet Router (192.168.1.1)
       |
       +-- Host Machine (192.168.1.100)
       |
       +-- VM (192.168.1.101)

Here's how these appear in libvirt XML configurations:

<!-- NAT Configuration -->
<interface type='network'>
  <source network='default'/>
  <model type='virtio'/>
</interface>

<!-- Bridged Configuration -->
<interface type='bridge'>
  <source bridge='br0'/>
  <model type='virtio'/>
</interface>

The accessibility difference stems from how iptables/nftables handles each mode:

# NAT rules (auto-generated by libvirt)
-A FORWARD -d 192.168.122.0/24 -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -j ACCEPT
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

Bridged mode has no such filtering - packets flow directly through the bridge interface.

To test connectivity between hosts, use these commands:

# On NAT VM (checking outward connectivity)
ping 8.8.8.8
traceroute 8.8.8.8

# From external host testing bridged VM
nmap -Pn 192.168.1.101

NAT is ideal when:
- Running test environments needing internet access
- Security isolation is critical
- IP address conservation is needed

Bridged works better for:
- Hosting services accessible from LAN
- Multicast/broadcast-dependent applications
- Cluster configurations needing direct node communication

To expose specific NAT VM ports to external networks:

virsh net-edit default
<forward mode='nat'>
  <nat>
    <port start='1024' end='65535'/>
  </nat>
  <port protocol='tcp'>
    <host port='8080' to='80'/>
  </port>
</forward>

NAT creates a private network inside your host machine where virtual machines get private IP addresses. The host acts as a router, translating private VM addresses to the host's public IP when communicating with external networks.

# Example NAT configuration in libvirt XML
<interface type='network'>
  <source network='default'/>
  <model type='virtio'/>
</interface>

Bridge mode connects your VM directly to the physical network by creating a virtual switch. The VM gets an IP from your LAN's DHCP server (just like physical devices) and appears as a standalone machine on the network.

# Bridged networking configuration example
<interface type='bridge'>
  <source bridge='br0'/>
  <virtualport type='openvswitch'/>
  <model type='virtio'/>
</interface>

What makes NAT inaccessible from external networks? The answer lies in three layers:

• IP Address Scope: NAT uses RFC 1918 private addresses (e.g., 192.168.122.0/24) while bridged gets public/LAN addresses
• Packet Routing: NAT modifies packet headers (source/destination IP/port) while bridge passes them unchanged
• ARP Handling: Bridged VMs respond to ARP requests directly, NAT VMs don't

When you'd choose each mode:

For NAT environments where you need selective external access:

# virsh port forwarding command example
virsh nat-add vmname tcp --hostport 8080 --guestport 80
# Equivalent in VirtualBox CLI
VBoxManage modifyvm "VM name" --natpf1 "guesthttp,tcp,,8080,,80"

Test why external machines can't see your NAT VM:

# On host machine:
iptables -t nat -L -v -n
# Check NAT rules and port forwarding
bridge link show
# Verify bridge configurations

The key takeaway: Bridged networking makes VMs first-class network citizens while NAT creates an isolated network with the host as gateway. The choice depends on your development requirements for accessibility versus security.