RouterOS 7.24 privileged containers — how far can network access actually go?
Hi MikroTik team and community,
I am researching the new privileged=yes container capability introduced in the RouterOS 7.24 development cycle, and I would like to clarify exactly what capabilities it provides, especially for advanced networking applications such as SD-WAN, multi-WAN routing, NAT, packet processing, and programmable routing.
I understand that privileged=yes significantly reduces container isolation and allows access to additional Linux kernel capabilities/devices. However, I would like to understand precisely where the boundary is between the container and the RouterOS host.
1. Physical Ethernet interfaces
Can a privileged container directly access or control physical Ethernet interfaces such as:
ether1
ether2
ether3
ether4
For example, can the container obtain direct packet-level access to a physical interface rather than receiving traffic only through a RouterOS VETH interface?
If direct physical NIC access is not supported, is there any supported mechanism planned for:
ether1 → container interface 1
ether2 → container interface 2
ether3 → container interface 3
without RouterOS performing L3 routing/NAT between them?
2. VLAN-based interface passing
If physical interface passthrough is not supported, can VLANs be used to provide isolated WAN interfaces to a privileged container?
For example:
ether1 → VLAN 101 → Container WAN1
ether2 → VLAN 102 → Container WAN2
ether3 → VLAN 103 → Container WAN3
Would this allow the Linux networking stack inside the container to independently perform:
- routing
- NAT
- connection tracking
- policy routing
- failover
- load balancing
while RouterOS remains primarily an L2 transport?
3. CAP_NET_ADMIN and Linux networking
Exactly which Linux capabilities are granted when:
privileged=yes
is enabled?
In particular, does the container receive capabilities such as:
CAP_NET_ADMIN
CAP_NET_RAW
CAP_SYS_ADMIN
CAP_SYS_MODULE
or an equivalent unrestricted capability set?
Can the container use:
iproute2
ip rule
ip route
ip neigh
ip link
nftables
conntrack
tc
network namespaces
TUN/TAP
WireGuard
VXLAN
when supported by the RouterOS kernel?
4. Kernel access
Does privileged=yes allow the container to interact directly with the RouterOS host kernel?
For example:
/proc/sys/dev- network-related kernel interfaces
- netlink
- eBPF
- tc/eBPF
- kernel networking subsystems
If some of these are restricted, could MikroTik provide a documented list of what is allowed and what is blocked?
5. nftables / iptables
Can a privileged container create and manage its own:
nftables
iptables
ipset
conntrack
rules independently from RouterOS?
More specifically, if the container receives traffic from multiple WAN interfaces, can it perform NAT and connection tracking entirely inside the container?
For example:
WAN1 ─┐
WAN2 ─┼──> Linux networking inside container ──> LAN
WAN3 ─┘
with RouterOS not performing the L3 NAT/routing?
6. Multi-WAN / SD-WAN use case
Would MikroTik consider the following architecture supported?
RouterOS
┌─────────────────────────────────────────┐
│ │
│ ether1 ─ WAN1 ─┐ │
│ ether2 ─ WAN2 ─┼──> Privileged Container│
│ ether3 ─ WAN3 ─┘ │ │
│ │ │
│ Linux Data Plane │
│ │ │
│ Routing / NAT / LB │
│ │ │
│ LAN │
└─────────────────────────────────────────┘
The goal would be to implement an SD-WAN engine inside the container rather than using RouterOS PCC/NTH/mangle for the entire data plane.
7. Hardware acceleration
If the container performs the L3 processing, would it be possible for traffic processed by the container to still benefit from any RouterOS hardware acceleration?
Or would traffic entering a privileged container necessarily be processed by the CPU?
This is particularly important for devices with switch chips and hardware offloading.
8. Packet performance
Is there an expected or supported high-performance packet path between:
Physical NIC ↔ privileged container
that avoids unnecessary copies between RouterOS and the container?
For example, is there any supported mechanism similar to:
- AF_XDP
- DPDK
- SR-IOV
- virtio
- packet mmap
- zero-copy networking
or any MikroTik-specific mechanism?
9. eBPF
Does the RouterOS kernel used by 7.24 support eBPF functionality that can be used from a privileged container?
If yes, which subsystems are available?
For example:
XDP
TC-BPF
socket filters
cgroup BPF
Could a privileged container use eBPF for high-performance packet classification/load balancing?
10. RouterOS configuration API vs direct kernel networking
Does MikroTik intend privileged containers to remain independent Linux environments, or is there any future plan to expose a controlled API allowing a container to interact directly with RouterOS networking objects?
For example:
/interfaces
/routes
/firewall
/queues
/VRFs
/VLANs
without requiring the container to connect through the normal RouterOS API/REST interface?
11. Security model
Since privileged=yes significantly reduces container isolation, what exactly prevents a compromised privileged container from:
- modifying RouterOS firewall behavior
- accessing host devices
- modifying host networking
- accessing RouterOS storage
- escaping the container
- affecting other RouterOS processes
Is privileged=yes intended to be considered equivalent to giving the application trusted access to the RouterOS host?
12. Future roadmap
Finally, is MikroTik planning to expand container networking capabilities in future RouterOS releases?
In particular, is direct access to physical network interfaces or a more advanced packet-processing framework for containers on the roadmap?
The use case I am investigating is a SASMAN SD-WAN Agent running directly inside a MikroTik router.
The concept would be:
SASMAN CLOUD
│
Policies / Config
│
▼
SASMAN EDGE AGENT
│
┌─────────────┼─────────────┐
│ │ │
WAN1 WAN2 WAN3
│ │ │
└─────────────┼─────────────┘
│
Linux Data Plane
│
Routing / NAT / LB
│
LAN
The main objective is to determine whether RouterOS 7.24+ can support a container acting as a programmable network data plane, while RouterOS itself provides the underlying hardware, switching, and physical interfaces.
I would greatly appreciate clarification from MikroTik developers on which parts of this architecture are currently supported, which are technically possible but unsupported, and which are not possible due to the RouterOS/container isolation model.
Thank you.