This has nothing to do with CheckMK.
It is only a configuration on container level and network traffic routing.
As you know the VyOS you can say if the writing from Claude can be valid 
############# AI Output #############
Yes, this is doable. The approach: the container gets two Podman networks, one per VRF, and therefore two interfaces. VyOS lets you bind a container network to a VRF (set container network <name> vrf <vrf>). You can check whether your release supports it with set container network TEST vrf ?. It should be available in 1.4/1.5 or rolling.
Layout
VRF MGMT VRF PROD
MGMT clients ──► eth1 ──DNAT──► pod-mgmt pod-prod ──► eth2 ──► other devices
172.16.10.0/24 172.16.20.0/24
│ │
eth0 (container) eth1 (container)
172.16.10.10 172.16.20.10
└── Apache :8000 ──┘
Configuration (example)
# VRFs (if not already present)
set vrf name MGMT table 100
set vrf name PROD table 200
set interfaces ethernet eth1 vrf MGMT
set interfaces ethernet eth2 vrf PROD
# Container networks, each bound to a VRF
set container network mgmt prefix 172.16.10.0/24
set container network mgmt vrf MGMT
set container network prod prefix 172.16.20.0/24
set container network prod vrf PROD
# Container attached to both networks
set container name web image <your-image>
set container name web network mgmt address 172.16.10.10
set container name web network prod address 172.16.20.10
VyOS creates the bridges pod-mgmt and pod-prod for these, each placed in the matching VRF.
Inbound via MGMT: DNAT
set nat destination rule 10 inbound-interface name eth1
set nat destination rule 10 protocol tcp
set nat destination rule 10 destination port 8000
set nat destination rule 10 translation address 172.16.10.10
set nat destination rule 10 translation port 8000
Use DNAT here rather than Podman port mapping (port). Port mapping would otherwise listen in the default VRF, not in MGMT.
The real catch: asymmetric routing
The container should have its default route via PROD (172.16.20.1). Replies to MGMT clients would then also leave via PROD and get dropped. There are three ways to fix this:
Option A: SNAT on VyOS (simplest, recommended). VyOS masquerades MGMT requests to the gateway IP 172.16.10.1. The container then only sees a directly connected network and replies correctly via eth0.
set nat source rule 10 outbound-interface name pod-mgmt
set nat source rule 10 protocol tcp
set nat source rule 10 destination port 8000
set nat source rule 10 translation address masquerade
The downside: Apache only sees 172.16.10.1 in its logs instead of the real client IP.
Option B: Policy routing inside the container. This requires set container name web capability net-admin and an entrypoint script, for example:
ip route add default via 172.16.10.1 dev eth0 table 100
ip rule add from 172.16.10.10 table 100
This preserves the real client IPs.
Option C: Static routes inside the container. Here you route only the MGMT subnets via 172.16.10.1 and everything else by default via PROD. This works as long as MGMT and PROD destinations don’t overlap.
Making PROD the default route
With multiple networks, Podman/netavark sets a default route for each one, and the metric depends on the order. Check it with:
sudo podman exec web ip route
If the wrong route wins, fix it in the entrypoint (with net-admin): delete the default route via eth0 and keep only default via 172.16.20.1.
Outbound via PROD
On the VyOS side, VRF PROD must either route 172.16.20.0/24 to its peers (statically or via BGP/OSPF in the VRF) or masquerade it on eth2:
set nat source rule 20 outbound-interface name eth2
set nat source rule 20 source address 172.16.20.0/24
set nat source rule 20 translation address masquerade
Hardening
Since Apache listens on 0.0.0.0:8000, it’s also reachable via the PROD IP. Either set Listen 172.16.10.10:8000 in Apache, or block inbound traffic to port 8000 from PROD toward 172.16.20.10 in the VyOS firewall.
If you tell me your VyOS version and your actual subnets, I can put together the exact configuration for you.
