VLAN setup on Proxmox: VLAN aware bridge, tags and trunk in 20 minutes
VLAN setup on Proxmox happens in three places: the switch port in trunk mode, the vmbr0 bridge with the VLAN aware flag, and the tag on the VM’s network adapter. A mistake in any of the three gives the same symptom: a VM with no network. Below is a recipe with a check for each link.
- Switch the port on the switch where the server is plugged in to trunk: the required VLANs tagged, the management VLAN untagged.
- In /etc/network/interfaces on the host, add bridge-vlan-aware yes and bridge-vids with the list of VLANs to vmbr0, apply with ifreload -a.
- In the network adapter settings for the VM or container, set the bridge to vmbr0 and the VLAN number in the VLAN Tag field.
- Check with bridge vlan show and tcpdump on the physical port that frames leave with the correct tag.
No time to read, here’s the minimal working setup. Host config and VM tag. Before applying, set up a rollback timer, described in step 2, otherwise you risk losing access to the server.
# Файл /etc/network/interfaces на хосте Proxmox
auto vmbr0
iface vmbr0 inet static
address 192.168.10.5/24
gateway 192.168.10.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40
# Где выполнять: хост Proxmox, shell под root
ifreload -a
bridge vlan show dev eno1
qm set 101 --net0 virtio,bridge=vmbr0,tag=20
Diagnosis: enabled VLAN aware on Proxmox, VM has no network
VLAN setup on Proxmox looks like one checkbox in the web interface. You enable VLAN aware on vmbr0, enter tag 20 on the VM’s adapter, click OK. The VM doesn’t get an address, ping to the gateway doesn’t go through. Sound familiar?
VLAN is simple: tag, bridge, switch. Three places where you can make a mistake. You’ll make it in the fourth one.
The fourth place is the order of actions. Half of Proxmox access losses happen not because of a wrong config, but because of a correct config applied in the wrong sequence. First the host, then the switch, or the other way around, and in between you have no connection. We’ll cover this sequence separately, with automatic rollback.
What you’ll get at the end
- A vmbr0 bridge with VLAN filtering on a single physical port or on a bond of two ports.
- VMs and LXC containers in their own VLANs, the tag set with one parameter.
- A trunk with a limited set of VLANs into a virtual router or firewall.
- Host management in a separate tagged VLAN, with no untagged traffic on the port.
- Named networks through an SDN VLAN zone, identical across all cluster nodes.
- Checks with tcpdump, monitoring of bridge state, network config backup and a rollback plan.
- Ready port configs for MikroTik RouterOS 7 and Cisco IOS.
Time wise: 20 minutes for the basic setup with tags for VMs. Another 15 minutes if you move host management into a tagged VLAN. I’m not counting the time to walk to the server, because with a rollback timer you won’t need it.
What you’ll need
A managed switch with 802.1Q support and access to its settings. Without it, VLANs on Proxmox only work inside a single host. An unmanaged switch will either pass tagged frames as is or drop them, and you can’t predict which in advance.
Access to the host console besides the network: a monitor with keyboard, IPMI, iDRAC or iLO. Root on the host. A VLAN plan on paper or in a spreadsheet: which number, which subnet, who’s the gateway.
| Component | Version at publication time | Minimum | Comment |
|---|---|---|---|
| Proxmox VE | 9.2, base Debian 13 | 7.x | Commands are the same for 7.x, 8.x and 9.x |
| ifupdown2 | Installed by default with Proxmox | Proxmox VE 7 | Needed for ifreload -a without rebooting |
| SDN | Included in Proxmox VE | 8.1 | Only for the VLAN zone variant |
| Switch | MikroTik RouterOS 7.x, Cisco IOS | Any with 802.1Q | Port in trunk mode |
| Network card | Intel, Mellanox, Broadcom, Realtek | 802.1Q support | Some cards have a limit on hardware VLAN filters |
| iproute2, tcpdump | From Debian repository | – | tcpdump installed separately |
At the time of publication, Proxmox VE 9.2 is current. Check for new releases before installing. The network config syntax has been stable since version seven, but SDN is actively developed, and menu items in the web interface may be named differently.
What’s in this article
- Reasons why VLAN on Proxmox doesn’t work after setup.
- Switch port configuration for MikroTik and Cisco.
- VLAN aware bridge, tags for VMs and LXC, trunk into a VM router.
- Moving host management into a tagged VLAN with a rollback timer.
- SDN VLAN zone for a cluster and bonding with LACP.
- Verification, eleven common mistakes and alternative setups.
- Monitoring, security, backup, upgrades and FAQ.
Why VLAN on Proxmox doesn’t work after setup
Go through the list. In practice, eight out of ten causes sit in the first three rows of the table.
| Cause | Why it breaks | Symptom |
|---|---|---|
| Switch port in access mode | Switch drops tagged frames or doesn’t pass the needed VLAN | VM has no address, tcpdump on the host sees requests without responses |
| VLAN not allowed on the trunk | The required number isn’t in the allowed vlan list | One VLAN works, the other doesn’t |
| VLAN number not in bridge-vids | The bridge doesn’t add this VLAN to the physical port | The frame doesn’t leave the host |
| Untagged VLAN mismatch | PVID 1 on the host, native VLAN 10 on the switch, or vice versa | Host management drops after ifreload |
| Double tag | Tag set in Proxmox and again on a subinterface inside the VM | The frame leaves with two tags, the switch doesn’t understand it |
| Network card VLAN filter limit | The card can’t accept filters for all 4093 VLANs in the 2-4094 range | Error on ifreload, some VLANs don’t work |
| Different bridges on cluster nodes | On one node vmbr0 is VLAN aware, on another it isn’t | VM loses network after migration |
| MTU mismatch | Jumbo frames enabled on the switch but not on the bridge, or vice versa | Ping works, large packets and iSCSI hang |
How it works: a frame’s path through a VLAN aware bridge
A bridge in VLAN aware mode works like a small managed switch inside the host. Each bridge port has a VLAN list and a PVID, the VLAN for untagged frames. A VM port with tag 20 is an access port for VLAN 20. The physical eno1 is a trunk going outward.
%%{init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#ffffff',
'primaryTextColor': '#1e293b',
'primaryBorderColor': '#94a3b8',
'lineColor': '#64748b',
'fontSize': '15px',
'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
},
'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
SW["Switch, trunk port"] --> NIC["eno1 physical port"]
NIC --> BR["vmbr0 VLAN aware"]
BR --> MGMT["vmbr0.10 host management"]
BR --> VM1["VM web, tag 20"]
BR --> VM2["VM db, tag 30"]
BR --> CT["LXC, tag 40"]
BR --> RT["VM router, trunk 20 and 30"]
style SW fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
style NIC fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
style BR fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
style MGMT fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
style RT fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
Here’s the path of one frame from a VM with tag 20 to the gateway. The VM itself knows nothing about VLANs, it sends a regular untagged frame. The bridge adds the tag.
%%{init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#f8fafc',
'primaryTextColor': '#1e293b',
'primaryBorderColor': '#94a3b8',
'noteBkgColor': '#fefce8',
'noteTextColor': '#713f12',
'noteBorderColor': '#fbbf24',
'actorBkg': '#f8fafc',
'actorBorder': '#94a3b8',
'actorTextColor': '#1e293b',
'fontSize': '15px',
'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
},
'sequence': {
'mirrorActors': false,
'messageAlign': 'center',
'actorMargin': 120,
'width': 160,
'noteMargin': 12
}
}}%%
sequenceDiagram
participant V as VM web
participant B as Bridge vmbr0
participant S as Switch
participant G as Gateway VLAN 20
V->>B: Frame without tag
Note over B: PVID of VM port is 20
B->>S: Frame tagged 20 through eno1
S->>G: Frame in VLAN 20
G->>S: Reply in VLAN 20
S->>B: Reply tagged 20
Note over B: Tag stripped on VM port
B->>V: Frame without tag
VLAN plan for the examples
All commands in this article use this plan. Substitute your own numbers and subnets, but keep the management VLAN separate from everything else.
| VLAN | Purpose | Subnet | Gateway |
|---|---|---|---|
| 10 | Management: Proxmox, IPMI, switches | 192.168.10.0/24 | 192.168.10.1 |
| 20 | Application servers | 192.168.20.0/24 | 192.168.20.1 |
| 30 | Databases | 192.168.30.0/24 | 192.168.30.1 |
| 40 | DMZ, outward facing services | 192.168.40.0/24 | 192.168.40.1 |
| 999 | Empty native VLAN | – | – |
And a port table, so you know where what should be accessible. The rule is simple: all management only from VLAN 10.
| Port | Protocol | Purpose | VLAN | Accessible from outside? |
|---|---|---|---|---|
| 8006 | TCP | Proxmox web interface | 10 | No |
| 22 | TCP | Host SSH | 10 | No |
| 3128 | TCP | SPICE proxy | 10 | No |
| 5405-5412 | UDP | Corosync, cluster | 10 or a separate cluster VLAN | No |
| 60000-60050 | TCP | Live migration | 10 or a separate VLAN | No |
| 80, 443 | TCP | DMZ services | 40 | Yes, via router |
Recipe: VLAN setup on Proxmox step by step
Preparation: check the host and network card
Why: find out port names, make sure ifupdown2 is installed, and figure out whether the card supports hardware VLAN filtering. The names eno1 and vmbr0 in this article are examples.
# Где выполнять: хост Proxmox, shell под root
pveversion
dpkg -l ifupdown2 | grep ^ii
ip -br link
ethtool -i eno1 | grep -E 'driver|version'
ethtool -k eno1 | grep -i vlan
cat /etc/network/interfaces
Expected result: pveversion shows 7.x or newer, ifupdown2 is installed. In ethtool -k, look for rx-vlan-filter: on. This means the card filters VLANs in hardware, which may come with a limit on the number of filters. Remember the driver, it’ll be useful in the troubleshooting section.
If ifupdown2 isn’t there, which happens on hosts upgraded from version six, install it. On a working host, install it only from the local console: the package restarts networking during install.
# Где выполнять: хост Proxmox, только из локальной консоли
apt update && apt install -y ifupdown2 tcpdump
Step 1. Save configs and set a rollback timer
Why: next you’ll be editing the host’s network, the same network you’re connected through. A systemd timer will restore the old config in five minutes if you don’t cancel it manually. This is a production trick: don’t touch a remote network without a rollback plan.
# Где выполнять: хост Proxmox
cp /etc/network/interfaces /root/interfaces.bak
systemd-run --on-active=300 --unit=net-rollback \
/bin/sh -c 'cp /root/interfaces.bak /etc/network/interfaces; ifreload -a'
systemctl list-timers net-rollback.timer
Result: net-rollback.timer appears in the timer list with a countdown. If the timer fires and you need more time, set it again with the same command. Don’t overwrite /root/interfaces.bak, it’s your return point.
Step 2. Set the switch port to trunk
Why: Proxmox will send frames tagged 20, 30 and 40, while management stays untagged for now. So the switch port needs to accept tags while still keeping VLAN 10 as native. This way the transition happens without a connection drop.
Example for MikroTik RouterOS 7, where the server is plugged into ether5 of bridge1. If vlan-filtering isn’t yet enabled on bridge1, enable it last, and only in Safe Mode. In the terminal that’s Ctrl+X, and if the session drops, RouterOS rolls back the changes itself.
# Где выполнять: коммутатор MikroTik, терминал RouterOS 7, Safe Mode включён
/interface bridge port set [find interface=ether5] pvid=10 frame-types=admit-all ingress-filtering=yes
/interface bridge vlan add bridge=bridge1 vlan-ids=20,30,40 tagged=bridge1,ether5
/interface bridge vlan print where vlan-ids=10
/interface bridge vlan set [find vlan-ids=10] untagged=ether5
/interface bridge set bridge1 vlan-filtering=yes
If there’s no entry for VLAN 10 yet, create one with the add command using vlan-ids=10, tagged=bridge1 and untagged=ether5. The bridge VLAN table is described in detail in the MikroTik Bridge VLAN Table documentation.
Example for Cisco IOS, port GigabitEthernet1/0/5. On older switches you’ll need the line switchport trunk encapsulation dot1q before trunk mode.
# Где выполнять: коммутатор Cisco, режим configure terminal
interface GigabitEthernet1/0/5
description proxmox-pve1
switchport mode trunk
switchport trunk native vlan 10
switchport trunk allowed vlan 10,20,30,40
spanning-tree portfast trunk
end
write memory
Result: access to Proxmox isn’t lost, since management is still untagged and lands in VLAN 10. On Cisco, check show interfaces trunk, on MikroTik /interface bridge vlan print. The port you need should show up in the VLAN 20, 30 and 40 lists as tagged.
Step 3. Enable VLAN aware on the vmbr0 bridge
Why: without this flag the bridge knows nothing about tags and passes frames as is. With it, the bridge filters VLANs per port and adds and strips tags itself.
Open /etc/network/interfaces and bring the vmbr0 block to this form. Keep your own address and gateway. List VLANs in bridge-vids explicitly, not as a 2-4094 range: it’s safer and avoids hitting network card limits.
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.10.5/24
gateway 192.168.10.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40
#Trunk, управление пока нетегированное
source /etc/network/interfaces.d/*
This part matters. The host’s address stays directly on vmbr0. Untagged frames on the bridge land in its PVID, which defaults to VLAN 1. The switch also delivers management untagged. Inside the host, the number of the untagged VLAN doesn’t matter as long as nothing is connected there except the host itself.
# Где выполнять: хост Proxmox
ifreload -a
cat /sys/class/net/vmbr0/bridge/vlan_filtering
bridge vlan show dev eno1
ping -c 3 192.168.10.1
systemctl stop net-rollback.timer
Result: vlan_filtering equals 1. For eno1, the list includes VLAN 1 with PVID and Egress Untagged flags, plus 10, 20, 30 and 40. Ping to the gateway works. Only stop the timer after that.
Through the web interface it’s the same thing: node, System, Network, vmbr0, Edit, check VLAN aware, Apply Configuration. The VLAN IDs field appears there under advanced settings. The difference is that editing the file makes it easier to carry the config over to a second node.
Step 4. Assign VLANs to virtual machines
Why: the tag on a VM’s adapter turns its port into an access port for that VLAN. Nothing needs to be configured inside the guest OS: it sees a regular untagged network.
Note, when changing adapter parameters through qm set it’s important to keep the MAC address. Otherwise, the interface name inside the VM might change, or its DHCP binding breaks. Take the MAC from the current config.
# Где выполнять: хост Proxmox, номер ВМ и MAC подставь свои
qm config 101 | grep ^net
qm set 101 --net0 virtio=BC:24:11:AA:AA:01,bridge=vmbr0,tag=20
qm set 102 --net0 virtio=BC:24:11:AA:AA:02,bridge=vmbr0,tag=30
qm config 101 | grep ^net
Result: the VM config now has tag=20. The tag change applies to a running VM without a reboot. Inside the VM, renew the address: restart the DHCP client or switch the static IP to the new VLAN’s subnet.
In the web interface: VM, Hardware, Network Device, Edit, VLAN Tag field. An empty field means no tag, and here’s where you can get it wrong: such a VM on a VLAN aware bridge receives more than just untagged traffic. More on that in step 6.
Step 5. Assign VLANs to LXC containers
Why: containers connect to the same bridge, and the tag is set the same way. There’s a catch: pct set replaces the entire net0 line. If you don’t repeat ip and gw, the container ends up without an address.
# Где выполнять: хост Proxmox, номер контейнера подставь свой
pct config 201 | grep ^net
pct set 201 --net0 name=eth0,bridge=vmbr0,tag=40,hwaddr=BC:24:11:CC:CC:01,ip=192.168.40.10/24,gw=192.168.40.1
pct config 201 | grep ^net
pct exec 201 -- ping -c 3 192.168.40.1
Result: the container config has tag=40, and ping to the VLAN 40 gateway works. If the container gets its address via DHCP, use ip=dhcp instead of ip and gw.
Step 6. Give a trunk to a virtual router
Why: a router or firewall inside a VM needs several VLANs on one adapter. No tag is set here, instead a trunks parameter limits the list of VLANs.
# Где выполнять: хост Proxmox, точка с запятой внутри кавычек обязательна
qm set 100 --net1 "virtio=BC:24:11:BB:BB:01,bridge=vmbr0,trunks=20;30;40"
qm config 100 | grep ^net1
Those quotes aren’t decoration. Without them bash treats the semicolon as the end of the command and tries to run 30 as a separate program. Result: the config shows trunks=20;30;40.
Set up subinterfaces inside the guest OS. Example for Debian or Ubuntu with ifupdown, where the trunk arrives on ens19. On OpenWrt the same thing is done through 802.1q devices in LuCI or uci.
# Где выполнять: гостевая ВМ-роутер на Debian, файл /etc/network/interfaces
auto ens19.20
iface ens19.20 inet static
address 192.168.20.1/24
auto ens19.30
iface ens19.30 inet static
address 192.168.30.1/24
auto ens19.40
iface ens19.40 inet static
address 192.168.40.1/24
# Где выполнять: хост Proxmox, проверка списка VLAN на порту ВМ
bridge vlan show | grep -A4 tap100i1
Result: port tap100i1 shows VLANs 20, 30 and 40 without the Egress Untagged flag. That’s a trunk. The tap number is made up of the VM number and the adapter number.
Step 7. Move host management into a tagged VLAN
Why: an untagged VLAN on a trunk port is a classic VLAN hopping attack surface and a source of confusion. The correct setup: everything travels tagged, the native VLAN on the port is empty and unused. This step is optional, but I always do it for production.
# Где выполнять: хост Proxmox, из локальной консоли или IPMI
cp /etc/network/interfaces /root/interfaces.bak
systemd-run --on-active=300 --unit=net-rollback \
/bin/sh -c 'cp /root/interfaces.bak /etc/network/interfaces; ifreload -a'
New config. The address moves from vmbr0 to the vmbr0.10 interface. The bridge itself stays without an address and works as a pure trunk.
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40
auto vmbr0.10
iface vmbr0.10 inet static
address 192.168.10.5/24
gateway 192.168.10.1
#Управление хостом, VLAN 10 с тегом
source /etc/network/interfaces.d/*
# Где выполнять: хост Proxmox
ifreload -a
ip -br addr show vmbr0.10
Right after this, change the switch. On MikroTik, VLAN 10 becomes tagged, and the PVID moves to the empty VLAN 999. On Cisco, the native VLAN is switched to 999.
# Где выполнять: коммутатор MikroTik, Safe Mode включён
/interface bridge vlan set [find vlan-ids=10] tagged=bridge1,ether5 untagged=""
/interface bridge port set [find interface=ether5] pvid=999 frame-types=admit-only-vlan-tagged
# Где выполнять: коммутатор Cisco, configure terminal
vlan 999
name native-unused
interface GigabitEthernet1/0/5
switchport trunk native vlan 999
end
write memory
# Где выполнять: хост Proxmox
ping -c 3 192.168.10.1
tcpdump -e -ni eno1 -c 10 vlan 10
systemctl stop net-rollback.timer
Result: ping works, tcpdump shows frames with vlan 10 in the header. Timer is stopped. Open the Proxmox web interface from a machine in VLAN 10 and confirm it works. The host’s address hasn’t changed, so there’s no need to touch /etc/hosts.
Step 8. SDN VLAN zone for a cluster
Why: in a multi-node cluster, writing VLAN numbers into every single VM is inconvenient and risky. SDN creates named networks, for example srv20, identical across all nodes. A VM connects to the network by name, while the VLAN number lives in one place. The mechanism is described in detail in the official Proxmox SDN documentation.
Requirements: all nodes have a bridge named vmbr0, and /etc/network/interfaces contains the line source /etc/network/interfaces.d/*. SDN writes its config exactly there. Zone and network names are limited to eight characters.
# Где выполнять: любой узел кластера Proxmox, конфиг общий для всех
grep 'interfaces.d' /etc/network/interfaces
pvesh create /cluster/sdn/zones --zone vlanzone --type vlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet srv20 --zone vlanzone --tag 20 --alias "Серверы приложений"
pvesh create /cluster/sdn/vnets --vnet db30 --zone vlanzone --tag 30 --alias "Базы данных"
pvesh set /cluster/sdn
The last command applies the config across all nodes. Without it, the networks only exist in /etc/pve/sdn files and show up in the interface as pending.
# Где выполнять: хост Proxmox, проверка и подключение ВМ
cat /etc/network/interfaces.d/sdn
ip -br link show srv20
qm set 101 --net0 virtio=BC:24:11:AA:AA:01,bridge=srv20
Result: the sdn file describes the srv20 bridge, the interface exists, and the VM is connected to it without a tag parameter. The VLAN number now changes in one place for every VM on that network. Permissions for the srv20 network can be given to a separate user, which is handy for dev teams.
Step 9. Bonding two ports with LACP
Why: the server has two ports, and you want redundancy. Bonding combines them, and the VLAN aware bridge works on top of the bond exactly like on a single port. 802.3ad mode requires LACP configuration on the switch.
auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer3+4
auto vmbr0
iface vmbr0 inet manual
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40
auto vmbr0.10
iface vmbr0.10 inet static
address 192.168.10.5/24
gateway 192.168.10.1
source /etc/network/interfaces.d/*
# Где выполнять: коммутатор MikroTik, ether5 и ether6 в сторону сервера
/interface bonding add name=bond-pve1 slaves=ether5,ether6 mode=802.3ad transmit-hash-policy=layer-3-and-4
/interface bridge port add bridge=bridge1 interface=bond-pve1 pvid=999 frame-types=admit-only-vlan-tagged
/interface bridge vlan set [find vlan-ids=10] tagged=bridge1,bond-pve1
/interface bridge vlan set [find vlan-ids=20,30,40] tagged=bridge1,bond-pve1
Before creating the bond on MikroTik, remove ether5 and ether6 from the bridge ports, otherwise RouterOS will refuse to add them to the bonding. On Proxmox, apply this config with a rollback timer too.
# Где выполнять: хост Proxmox
ifreload -a
grep -E 'Bonding Mode|MII Status|Aggregator ID|Partner Mac' /proc/net/bonding/bond0
Result: mode IEEE 802.3ad, both ports show MII Status up and the same Aggregator ID, Partner Mac isn’t all zeros. A zero partner MAC means the switch isn’t responding over LACP.
How to verify that VLAN on Proxmox works correctly
Check bottom up: bridge, physical port, frames on the wire, guest OS. If a link is green, move to the next one.
# Где выполнять: хост Proxmox
cat /sys/class/net/vmbr0/bridge/vlan_filtering
bridge vlan show
bridge -d vlan show dev eno1
ip -d link show vmbr0 | grep -o 'vlan_filtering [0-9]'
journalctl -b -u networking --no-pager | tail -20
# Где выполнять: хост Proxmox, смотрим теги на проводе
tcpdump -e -ni eno1 -c 20 vlan
tcpdump -e -ni eno1 vlan 20 and icmp
In a second window, ping the gateway from inside the VM tagged 20. The tcpdump output should show lines with vlan 20 in both directions. If you only see outgoing requests, the problem is on the switch or gateway. If you see nothing at all, the problem is on the bridge.
# Где выполнять: гостевая ВМ с тегом 20, Linux
ip -br addr
ip route | grep default
ping -c 3 192.168.20.1
ping -c 3 ya.ru
| Check | Expected result | If not |
|---|---|---|
| vlan_filtering | 1 | Missing bridge-vlan-aware yes line or ifreload not run |
| bridge vlan show dev eno1 | All VLANs from bridge-vids | Card limit or typo in the list |
| bridge vlan show, VM’s tap port | One VLAN with PVID and Egress Untagged flags | Tag not set, or VM didn’t restart its adapter |
| tcpdump vlan 20 | Requests and replies tagged 20 | Only requests: check the switch |
| Ping to gateway from VM | Replies with no loss | VM’s address isn’t in the VLAN subnet |
| /proc/net/bonding/bond0 | Both ports up, same Aggregator ID | LACP not configured on the switch |
And one test that’s rarely done. Create a temporary VM without a tag and check if it sees anything on the network. If it sees VLAN 10, the switch port still has an untagged management VLAN. It’s not a disaster, but it’s a hole.
Troubleshooting: common VLAN mistakes on Proxmox
It’s not as bad as you think. It’s actually worse: these errors also involve a switch, which you probably didn’t configure yourself.
Go through the tree top to bottom. Don’t jump straight into switch settings before checking the bridge.
%%{init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#ffffff',
'primaryTextColor': '#1e293b',
'primaryBorderColor': '#94a3b8',
'lineColor': '#64748b',
'fontSize': '15px',
'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
},
'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
A["VM tagged, no network"] --> B{"vlan_filtering equals 1?"}
B -->|No| C["Enable VLAN aware"]
B -->|Yes| D{"VLAN present on eno1?"}
D -->|No| E["Add to bridge-vids"]
D -->|Yes| F{"tcpdump sees the tag?"}
F -->|No| G["Check the VM's tag"]
F -->|Yes| H{"Any replies?"}
H -->|No| I["Switch port isn't trunk"]
H -->|Yes| J["Check VM's address"]
style A fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
style C fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#b91c1c
style E fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#b91c1c
style G fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#b91c1c
style I fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#b91c1c
style J fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
Mistake 1. Tagged VM has no address, tcpdump sees only requests
Cause: the switch port is in access mode, or the VLAN isn’t in the trunk’s allowed list. Tagged frames leave the host and vanish at the switch.
Fix: check the trunk on the switch and add the VLAN. On the host, confirm that requests leave with the correct tag.
# Где выполнять: хост Proxmox
tcpdump -e -ni eno1 -c 10 vlan 20 and port 67
# Где выполнять: коммутатор Cisco
show interfaces GigabitEthernet1/0/5 trunk
configure terminal
interface GigabitEthernet1/0/5
switchport trunk allowed vlan add 20
end
Mistake 2. ifreload complains about VLAN, some VLANs don’t work
Cause: a network card with hardware VLAN filtering has a filter limit, while bridge-vids has the default 2-4094 range. The card accepts part of the filters and silently drops the rest, or ifreload fails with an error like No space left on device.
Fix: list only the VLANs you actually use. If there are many, disable hardware filtering on the port, keeping in mind it adds a bit of CPU load.
# Где выполнять: хост Proxmox
journalctl -b -u networking --no-pager | grep -iE 'vlan|error'
ethtool -k eno1 | grep rx-vlan-filter
sed -i 's/bridge-vids 2-4094/bridge-vids 10 20 30 40/' /etc/network/interfaces
ifreload -a
# Альтернатива: отключить аппаратный фильтр, строка в блоке iface eno1 inet manual
post-up /usr/sbin/ethtool -K eno1 rx-vlan-filter off
Mistake 3. Lost host access after ifreload
Cause: the untagged VLAN doesn’t match. The host moved its address to vmbr0.10 and sends tagged frames, but the switch expects them untagged. Or the opposite: the switch already expects a tag, but the host doesn’t yet send one.
# Где выполнять: хост Proxmox, локальная консоль
cp /root/interfaces.bak /etc/network/interfaces
ifreload -a
systemctl restart pveproxy
After restoring, compare the setup: an address on vmbr0 means untagged management, an address on vmbr0.10 means tagged management. The switch has to expect exactly the same thing.
Mistake 4. Double tag: a VM with a subinterface doesn’t work
Cause: the Proxmox adapter has tag=20 set, while inside the VM ens18.20 is also brought up. The frame leaves with two 802.1Q tags, the switch sees the outer tag 20 plus inner garbage.
Fix: the tag goes in one place only. Either tag in Proxmox and a regular interface inside the VM, or trunks in Proxmox and subinterfaces inside the VM.
# Где выполнять: хост Proxmox, ловим двойные теги
tcpdump -e -ni eno1 -c 10 'vlan and vlan'
Mistake 5. LXC container lost its address after a VLAN change
Cause: pct set replaces the entire net0 line. If the command didn’t include ip, gw and hwaddr, they’re gone.
Fix: always pass the full adapter line. The easiest way is to take the current one from pct config and only change the tag.
# Где выполнять: хост Proxmox
CUR=$(pct config 201 | awk -F': ' '/^net0/{print $2}')
echo "$CUR"
NEW=$(echo "$CUR" | sed 's/tag=[0-9]*/tag=40/')
pct set 201 --net0 "$NEW"
pct config 201 | grep ^net0
Mistake 6. bash: 30: command not found when setting trunks
Cause: the trunks list contains semicolons, and without quotes the shell splits the string into several commands. Proxmox only gets trunks=20, the rest disappears.
# Где выполнять: хост Proxmox
qm set 100 --net1 "virtio=BC:24:11:BB:BB:01,bridge=vmbr0,trunks=20;30;40"
Mistake 7. VM lost network after migrating to another node
Cause: on the second node the bridge has a different name, VLAN aware isn’t enabled, or bridge-vids is missing the needed VLAN. Or the second node’s switch port isn’t configured the same way as the first.
Fix: compare network configs across nodes. For a cluster, switch to SDN from step 8: it rolls out identical networks to all nodes.
# Где выполнять: любой узел кластера, имена узлов подставь свои
for n in pve1 pve2 pve3; do echo "== $n"; ssh root@$n "grep -E 'vlan-aware|vids' /etc/network/interfaces"; done
Mistake 8. Ping works, but iSCSI and large files hang
Cause: MTU mismatch somewhere along the chain. Jumbo frames need to be enabled everywhere: on the physical port, the bridge, the VLAN interface, inside the VM, and on the switch.
# Фрагмент /etc/network/interfaces на хосте Proxmox
iface eno1 inet manual
mtu 9000
auto vmbr0
iface vmbr0 inet manual
mtu 9000
bridge-ports eno1
bridge-vlan-aware yes
bridge-vids 10 20 30 40
# Где выполнять: хост Proxmox, тест без фрагментации до хранилища
ping -M do -s 8972 -c 3 192.168.40.20
For a VM adapter, MTU is set with the mtu=9000 parameter in the net line. A value of mtu=1 means the VM inherits the bridge’s MTU.
Mistake 9. SDN network created, but missing from the bridge list
Cause: the config wasn’t applied with pvesh set /cluster/sdn, or /etc/network/interfaces is missing the line source /etc/network/interfaces.d/*.
# Где выполнять: хост Proxmox
grep -q 'source /etc/network/interfaces.d/\*' /etc/network/interfaces || echo 'source /etc/network/interfaces.d/*' >> /etc/network/interfaces
pvesh set /cluster/sdn
ls -l /etc/network/interfaces.d/
Mistake 10. 802.3ad bond is running on a single port
Cause: the switch ports aren’t combined with LACP, or they’re combined into a static bond without LACP. The partner doesn’t respond, and Linux ends up using just one port.
# Где выполнять: хост Proxmox
grep -E 'Slave Interface|Aggregator ID|Partner Mac' /proc/net/bonding/bond0
If the ports show different Aggregator IDs or a zero Partner Mac, configure LACP on the switch. If the switch doesn’t support LACP, use bond-mode active-backup: no load balancing, but still a failover.
Mistake 11. Untagged VM ended up in the management network
Cause: on the switch’s trunk port, VLAN 10 is untagged, and the VM’s VLAN Tag field is empty. Its untagged traffic goes into the bridge’s PVID and then into the switch’s native VLAN, which is management.
# Где выполнять: хост Proxmox, ищем ВМ без тега и без trunks
for f in /etc/pve/nodes/*/qemu-server/*.conf; do grep -H '^net' "$f" | grep -vE 'tag=|trunks='; done
Fix: set a tag on every VM from the list and move management into a tagged VLAN following step 7.
| Mistake | Cause | Fix |
|---|---|---|
| VM with no address, only requests | Switch port isn’t trunk | Trunk, VLAN in allowed list |
| ifreload error, some VLANs dead | Card filter limit | Explicit bridge-vids list |
| Lost access to the host | Untagged VLAN mismatch | Rollback and synchronized config |
| Nothing works on a VM with a subinterface | Double tag | Tag in one place only |
| LXC has no address after VLAN change | pct set replaced the net0 line | Full adapter line |
| command not found with trunks | Semicolon without quotes | Quoted string |
| No network after migration | Different bridges on nodes | SDN VLAN zone |
| Large packets hang | MTU mismatch somewhere | Same MTU everywhere |
| SDN network missing | Config not applied or no source line | pvesh set /cluster/sdn |
| LACP on one port | Switch without LACP | LACP or active-backup |
| VM in management network | No tag, native VLAN 10 | Tags for everyone, tagged management |
Alternatives: classic bridges, Open vSwitch, SDN
The VLAN aware bridge isn’t the only way to do VLANs on Proxmox. Here are the rest and when they make more sense.
Classic setup: one bridge per VLAN
This is how it was done before VLAN aware bridges existed, and it’s still how a lot of older hosts work. For each VLAN you create a subinterface eno1.20 and a separate vmbr20 bridge. A VM connects to the bridge without a tag.
auto eno1.20
iface eno1.20 inet manual
auto vmbr20
iface vmbr20 inet manual
bridge-ports eno1.20
bridge-stp off
bridge-fd 0
#VLAN 20 серверы
auto eno1.30
iface eno1.30 inet manual
auto vmbr30
iface vmbr30 inet manual
bridge-ports eno1.30
bridge-stp off
bridge-fd 0
#VLAN 30 базы данных
Pro: clear and visual, a VM physically can’t end up in a different VLAN. Con: with 20 VLANs you end up with 40 interfaces, and you can’t hand a trunk to a VM this way. You can’t mix this setup with a VLAN aware bridge on the same port.
Open vSwitch
OVS can do everything the Linux bridge does, plus port mirroring, OpenFlow and finer grained statistics. It’s installed with the openvswitch-switch package. Worth it if you already have an OVS ecosystem or need a SPAN port for IDS.
# Где выполнять: хост Proxmox, из локальной консоли
apt install -y openvswitch-switch
auto eno1
iface eno1 inet manual
ovs_type OVSPort
ovs_bridge vmbr0
auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports eno1 mgmt10
auto mgmt10
iface mgmt10 inet static
address 192.168.10.5/24
gateway 192.168.10.1
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=10
For a VM, the tag is set the same way, via the tag parameter. Diagnostics go through ovs-vsctl show, not bridge vlan show. That’s a second utility you need to remember at three in the morning. More details on the Open vSwitch website.
SDN VLAN zone and QinQ
SDN doesn’t replace the VLAN aware bridge, it builds on top of it. For a single host it’s an extra layer you don’t need. For a cluster of two or more nodes it’s the right choice: named networks instead of numbers, access rights per network, identical config everywhere. A QinQ zone comes in handy for providers and anyone who needs more than 4094 networks, it adds a second tag.
A separate network card per network
The simplest and most expensive option. Storage on one card, management on a second, VMs on a third. Justified for storage and Corosync: they care about latency, not convenience. Everything else is better off separated by VLAN.
| Option | Complexity | Trunk into a VM | Scale | When to choose |
|---|---|---|---|---|
| VLAN aware Linux bridge | Low | Yes, trunks | Single host, small cluster | Default choice for most tasks |
| One bridge per VLAN | Medium | No | A handful of VLANs | Older hosts, strict isolation without tags inside VMs |
| Open vSwitch | Medium | Yes | Any | Need SPAN, OpenFlow or already run OVS |
| SDN VLAN zone | Low on top of a bridge | Via an untagged VNet | Cluster | Multiple nodes, per-network permissions |
| SDN QinQ | Medium | Yes | Large | Multi-tenancy, more than 4094 networks |
| A separate card per network | Low | No | Limited by ports | Storage and Corosync |
Why this recipe uses the VLAN aware bridge. It’s a standard Linux kernel mechanism with no extra packages, the Proxmox web interface understands it, and diagnosing it takes two commands. If a cluster shows up tomorrow, SDN slots on top without any rework.
Prevention: network monitoring, security, backup
One switch port switched to access “for five minutes” back in 2019 is still alive today. It’ll break your migration right on a Friday at 6:02 pm.
Monitoring
VLAN network problems are quiet: the bridge is up, the link is there, but the needed VLAN is no longer on the port. A script on the host checks, once a minute, the filtering status, the link, the presence of each VLAN on the physical port, and the management gateway. Errors go into the system log.
# Где выполнять: хост Proxmox
cat > /usr/local/bin/vlan-watch.sh </dev/null)" = "1" ] || logger -t vlan-watch "$BR: vlan_filtering выключен"
[ "$(cat /sys/class/net/$UP/carrier 2>/dev/null)" = "1" ] || logger -t vlan-watch "$UP: нет линка"
J=$(bridge -j vlan show dev "$UP")
for v in $VIDS; do
echo "$J" | grep -q "\"vlan\":$v[,}]" || logger -t vlan-watch "$UP: нет VLAN $v"
done
ping -c 2 -W 2 "$GW" >/dev/null 2>&1 || logger -t vlan-watch "Шлюз управления $GW недоступен"
EOF
chmod +x /usr/local/bin/vlan-watch.sh
echo '* * * * * root /usr/local/bin/vlan-watch.sh' > /etc/cron.d/vlan-watch
/usr/local/bin/vlan-watch.sh; journalctl -t vlan-watch --since "5 min ago"
An empty journal output after a manual run means everything’s fine. If your uplink is a bond, set the UP variable to bond0. If you use Zabbix, attach the Linux by Zabbix agent template to the host and add an item reading the journal filtered by the vlan-watch tag. Add ICMP checks for each VLAN’s gateway from a monitoring box that can see them through the router.
On the switch, enable SNMP or syslog forwarding: port mode changes and LACP drops should end up wherever your on-call engineer is watching.
Security
Firewall. Don’t install UFW on the Proxmox host: Proxmox has its own pve-firewall, and two rule managers will overwrite each other. Enable the firewall at the datacenter level and restrict management to VLAN 10 using a management IP set.
# Файл /etc/pve/firewall/cluster.fw на хосте Proxmox
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
[IPSET management]
192.168.10.0/24
# Где выполнять: хост Proxmox
pve-firewall compile | head -40
pve-firewall status
VLAN isolation. Do inter-VLAN filtering on the router, not on the Proxmox bridges. On the host, three rules matter: the native VLAN on the trunk port is empty, every VM has either a tag or an explicit trunks list, and bridge-vids only contains the VLANs you actually use. A VLAN that’s not in bridge-vids can’t reach any VM, even by mistake.
fail2ban for the web interface. On Debian 13, logs live in journald, so the systemd backend is required.
# Где выполнять: хост Proxmox
apt install -y fail2ban python3-systemd
cat > /etc/fail2ban/filter.d/proxmox.conf <<'EOF'
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost= user=.* msg=.*
ignoreregex =
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
EOF
cat > /etc/fail2ban/jail.d/proxmox.local <<'EOF'
[DEFAULT]
backend = systemd
ignoreip = 127.0.0.1/8 ::1
[sshd]
enabled = true
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
maxretry = 3
findtime = 2d
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status proxmox
SSH hardening. Leave root login via key, the cluster needs it for migrations. Disable password login. First make sure your own key already works.
# Где выполнять: хост Proxmox
cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
EOF
sshd -t && systemctl reload ssh
A separate user. There's no database in this setup, Proxmox accounts play that role. Keep root@pam for emergencies. Set up your own user with VM permissions, give monitoring a read only role. Permissions for a specific SDN network are granted separately, which is handy for a team that shouldn't touch other VLANs.
# Где выполнять: хост Proxmox
pveum user add andrey@pve --comment "Ежедневная работа"
pveum passwd andrey@pve
pveum acl modify /vms -user andrey@pve -role PVEVMAdmin
pveum user add monitor@pve --comment "Только чтение для мониторинга"
pveum acl modify / -user monitor@pve -role PVEAuditor
pveum acl modify /sdn/zones/vlanzone/srv20 -user andrey@pve -role PVESDNUser
IP restrictions. Port 8006 and SSH are reachable only from VLAN 10, enforced by the management set. On the switch, block access to its own management from every VLAN except 10.
Backup
| What to back up | How often | Where to store | How to restore |
|---|---|---|---|
| /etc/network/interfaces and interfaces.d | Daily and before changes | Host, then NAS or PBS | Copy back, ifreload -a |
| /etc/pve/sdn and /etc/pve/firewall | Daily | Off the cluster | Copy back, pvesh set /cluster/sdn |
| VM and container configs | Daily | Off the cluster | Copy into /etc/pve/nodes/node/ |
| Switch config | After every change and weekly | Off the switch | /import on MikroTik, copy on Cisco |
# Где выполнять: хост Proxmox
cat > /usr/local/bin/net-backup.sh </dev/null
bridge -d vlan show > "$DST/bridge-vlan-$(date +%F).txt"
find "$DST" -mtime +30 -delete
EOF
chmod +x /usr/local/bin/net-backup.sh
echo '15 3 * * * root /usr/local/bin/net-backup.sh' > /etc/cron.d/net-backup
/usr/local/bin/net-backup.sh && ls -lh /root/backup/net/
A text snapshot of bridge vlan show in your backup is invaluable. When something breaks six months from now, you compare the current state with the last known good one using a single diff command.
# Где выполнять: коммутатор MikroTik, бэкап конфига
/export file=sw-backup-2026-10-22
Restoring on the host. Unpack the archive into a temp folder, compare the files against the current ones, and restore only what's broken. Then reload the network and apply SDN.
# Где выполнять: хост Proxmox, имя архива подставь своё
mkdir -p /root/restore && tar xzf /root/backup/net/net-pve1-ДАТА.tar.gz -C /root/restore
diff /root/restore/etc/network/interfaces /etc/network/interfaces
cp /root/restore/etc/network/interfaces /etc/network/interfaces
ifreload -a
pvesh set /cluster/sdn
Upgrades
Proxmox upgrades touch the kernel, network card drivers and ifupdown2. These are exactly the moments when things that worked for years tend to break. Save a state snapshot before upgrading, compare after.
# Где выполнять: хост Proxmox, до обновления
bridge -d vlan show > /root/vlan-before.txt
ethtool -i eno1 > /root/nic-before.txt
apt update
apt list --upgradable | grep -E 'pve-kernel|proxmox-kernel|ifupdown2|pve-network'
apt full-upgrade
# Где выполнять: хост Proxmox, после перезагрузки
bridge -d vlan show > /root/vlan-after.txt
diff /root/vlan-before.txt /root/vlan-after.txt
/usr/local/bin/vlan-watch.sh; journalctl -t vlan-watch --since "5 min ago"
Always use apt full-upgrade, never apt upgrade: Proxmox changes dependencies, and a plain upgrade leaves the system half updated. In a cluster, upgrade nodes one at a time, migrating VMs off beforehand.
Rollback, if the network breaks after a new kernel: boot the previous kernel and pin it. Take the version from the list, the one in the command below is just an example.
# Где выполнять: хост Proxmox
proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 6.17.2-1-pve
reboot
Once a fixed kernel comes out, unpin it with proxmox-boot-tool kernel unpin. Upgrade the switch separately, and not on the same day: if something breaks after two upgrades, you won't know which one caused it.
Autostart
The host's network configuration comes up on its own at boot through ifupdown2, no separate autostart is needed. But a VM running a VLAN router should start before the others, otherwise guests in VLAN 20 and 30 will boot without a gateway or DHCP.
# Где выполнять: хост Proxmox, номера ВМ подставь свои
qm set 100 --onboot 1 --startup order=1,up=30
qm set 101 --onboot 1 --startup order=2
qm set 102 --onboot 1 --startup order=2
FAQ: common questions about VLAN on Proxmox
Why doesn't VLAN on Proxmox work after setup?
Most often the switch port is still in access mode, or the needed VLAN isn't allowed on the trunk. The second most common cause: the VLAN number isn't in bridge-vids, so the bridge doesn't pass it to the physical port. Run tcpdump filtering on that VLAN on eno1: if requests go out but there are no replies, look at the switch.
How do you verify that VLAN on Proxmox works correctly?
Confirm that /sys/class/net/vmbr0/bridge/vlan_filtering is set to 1, and that bridge vlan show lists the right VLANs on the physical port with the correct PVID on the VM's port. Then tcpdump with the -e flag on eno1 should show tagged frames in both directions. The final check is pinging that VLAN's gateway from inside the VM.
What do I do if access to Proxmox disappears after enabling VLAN aware?
Connect through the local console or IPMI, restore the saved /etc/network/interfaces, and run ifreload -a. The usual cause is a mismatch between the untagged VLAN on the host and on the switch. Next time, set a rollback timer with systemd-run, it'll restore the config automatically.
What's the difference between a VLAN aware bridge and SDN VLAN on Proxmox?
A VLAN aware bridge is a kernel mechanism on a single host, the VLAN number is written into each VM. An SDN VLAN zone works on top of such a bridge and creates named networks, identical across all cluster nodes. A single host only needs the bridge, a cluster is better off with SDN.
How do you pass a trunk with all VLANs into a Proxmox virtual machine?
Leave the VLAN Tag field empty and specify the VLAN list with the trunks parameter, for example trunks=20;30;40, always in quotes on the command line. Without trunks, the VM would get every VLAN from bridge-vids, which isn't secure. Inside the VM, bring up subinterfaces for each VLAN.
Can you set up VLAN on Proxmox with a single network card?
Yes, that's the main scenario: one card in trunk mode, a VLAN aware bridge, and tags on the VMs. Host management is moved to the vmbr0.10 interface, and the provider connection can come in on a separate VLAN through a managed switch. The one limitation: all traffic goes through that single port.
How do you assign a VLAN to an LXC container on Proxmox?
In the web interface: container, Network, adapter, VLAN Tag field. On the command line, use pct set with the tag parameter, but pass the full adapter line, including ip, gw and hwaddr. Otherwise the container ends up without an address.
Do you need Open vSwitch for VLAN on Proxmox?
No, the standard Linux bridge in VLAN aware mode covers nearly every use case. Open vSwitch makes sense for port mirroring, OpenFlow, or if your whole infrastructure already runs on it. Adding it just for VLANs is unnecessary complexity.
Outcome: a network you can explain
We set the switch port to trunk, enabled VLAN aware on vmbr0 with an explicit VLAN list, and spread VMs and containers across networks with a single parameter each. The router got a trunk with a limited VLAN set, host management moved to tagged VLAN 10, and the native VLAN became empty. Every network change went through with a rollback timer, and the cluster has an SDN zone with named networks.
Now the host's network is described by a single VLAN table and verified with two commands. A script checks every minute that the VLANs are in place, and a nightly backup saves configs plus a bridge snapshot. The next step is inter-VLAN rules on the router: databases should only be reachable from the application VLAN. High technology, enterprise segmentation, a proper enterprise approach. In practice it's four lines in a config and one checkbox nobody used to check.
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
