CRS304 VLANs and Linux egress control

Local traffic and egress on CRS304

I designed RouterOS VLANs and firewall policy to preserve Mac-to-Linux 10GbE transfers while limiting Linux egress. The infrastructure setup separates local development traffic from package updates.

On VDSL, CRS304 acts as router and switch. Port2 and Port3 carry local wired traffic, while a Wi-Fi AP serves household internet clients. Linux uses allowlists, Mac is less restricted, ISP inbound is dropped, and Prometheus and Loki provide monitoring.

Background and Goals

Linux normally handles local development and transfers, with occasional updates. Daily clients, Wi-Fi, and IoT need different policies.

The goals are:

• preserve high-speed local transfer between Mac and Linux
• keep Linux offline by default or restricted to a very small allowlist
• avoid over-restricting the Mac for normal daily work
• separate IoT and mobile Wi-Fi traffic from the wired local segment
• drop all inbound traffic from the ISP side
• keep enough metrics and logs to audit what the policy is actually doing

The design combines VLANs, stateful firewalling, destination controls, fixed physical port roles, and a later FTTH migration path.

Overall Design Summary

Port roles:

• Port1 = WAN
• Port2 = Mac or wired client side
• Port3 = Linux
• Port4 = Wi-Fi AP trunk
• Port5 = console / management

Baseline VLANs:

• VLAN10 = Wired-LAN
• VLAN20 = Trusted Wi-Fi
• VLAN30 = IoT Wi-Fi

Wired traffic stays local-first. Linux new connections use allowlists, WAN input is dropped, and SNMP exporter and Syslog/Loki provide monitoring.

1) Address Plan (Example)

The baseline address plan:

• 10.10.10.0/24 for wired LAN
• 10.20.20.0/24 for trusted Wi-Fi
• 10.30.30.0/24 for IoT Wi-Fi
• DHCP on the WAN side

The operational note also uses a shorthand for device roles:

10.x denotes implementation subnets; 1.10 through 1.13 denotes operational roles.

2) RouterOS v7 Configuration Script (Draft)

The baseline script defines bridge, VLAN, DHCP, DNS, NAT, and firewall rules.

  # ========== インタフェースとブリッジ ==========
/interface bridge add name=br-core vlan-filtering=yes protocol-mode=none

# 物理ポート割当（例）
# ether1=Port1(WAN), sfp-sfpplus1=Port2(Mac), sfp-sfpplus2=Port3(Linux),
# sfp-sfpplus3=Port4(AP), sfp-sfpplus4=Port5(Console)
# 実機のif名に合わせて修正
/interface bridge port
add bridge=br-core interface=sfp-sfpplus1 pvid=10  # Mac: access VLAN10
add bridge=br-core interface=sfp-sfpplus2 pvid=10  # Linux: access VLAN10
add bridge=br-core interface=sfp-sfpplus3          # AP: trunk (tagged)
add bridge=br-core interface=sfp-sfpplus4 pvid=10  # Console: access VLAN10（管理をLANから）
# WAN はブリッジに入れない（ルーターポートとして独立）
# ether1 は WAN 専用

# ========== VLAN インタフェース ==========
/interface vlan
add name=vlan10-LAN interface=br-core vlan-id=10
add name=vlan20-TRUST interface=br-core vlan-id=20
add name=vlan30-IOT interface=br-core vlan-id=30

# ========== VLAN タグ付与設定 ==========
/interface bridge vlan
# VLAN10: access on Port2/3/5 (untagged), tagged on bridge-cpu
add bridge=br-core vlan-ids=10 tagged=br-core untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus4
# VLAN20: tagged on AP trunk + bridge-cpu
add bridge=br-core vlan-ids=20 tagged=br-core,sfp-sfpplus3
# VLAN30: tagged on AP trunk + bridge-cpu
add bridge=br-core vlan-ids=30 tagged=br-core,sfp-sfpplus3

# ========== IP アドレス ==========
/ip address
add address=10.10.10.1/24 interface=vlan10-LAN comment="LAN gw"
add address=10.20.20.1/24 interface=vlan20-TRUST comment="Trusted gw"
add address=10.30.30.1/24 interface=vlan30-IOT comment="IoT gw"

# WAN は DHCP
/ip dhcp-client add interface=ether1 use-peer-dns=no use-peer-ntp=yes add-default-route=yes

# ========== DHCP サーバ（Wi-Fi用。LANは固定でも可） ==========
/ip pool add name=pool-trust ranges=10.20.20.100-10.20.20.199
/ip pool add name=pool-iot ranges=10.30.30.100-10.30.30.199
/ip dhcp-server add name=dhcp-trust interface=vlan20-TRUST address-pool=pool-trust lease-time=12h
/ip dhcp-server add name=dhcp-iot interface=vlan30-IOT address-pool=pool-iot lease-time=12h
/ip dhcp-server network
add address=10.20.20.0/24 gateway=10.20.20.1 dns-server=10.20.20.1
add address=10.30.30.0/24 gateway=10.30.30.1 dns-server=10.30.30.1

# ========== DNS（ルータを唯一のDNSに） ==========
/ip dns set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes use-doh-server="" verify-doh-cert=no

# ========== アドレスリスト（Port3-Linuxの許可先） ==========
# 直接IPで許可したい先
/ip firewall address-list
add list=allowlist-Linux comment="例: Gitホスト" address=203.0.113.10
add list=allowlist-Linux comment="例: R2/Cloud" address=198.51.100.20

# もしドメイン許可が必要なら（動的解決）：
# RouterOS v7は /ip/firewall/address-list add address=example.com でFQDN可（DNS依存）
add list=allowlist-Linux address=github.com
add list=allowlist-Linux address=registry-1.docker.io
add list=allowlist-Linux address=ghcr.io

# ========== NAT ==========
# Trusted/IOT → WAN のみマスカレード（LAN→WANは不可にするので不要でも良いが保険でON）
/ip firewall nat
add chain=srcnat src-address=10.20.20.0/24 out-interface=ether1 action=masquerade comment="Trusted -> WAN"
add chain=srcnat src-address=10.30.30.0/24 out-interface=ether1 action=masquerade comment="IoT -> WAN"
# VLAN10(LAN) はインターネット禁止のため NAT しない（誤設定時の外出し防止）

# ========== Firewall 基本ポリシー ==========
# 1) 既定：全部閉じる（最後に drop）
# 2) state: established, related は許可。invalidはdrop
# 3) WAN→ルータ input は既定 drop（必要最小限のみ許可）
# 4) forward はVLAN間/対WANをポリシーベースで制御

/ip firewall filter
# --- hygiene
add chain=input connection-state=invalid action=drop comment="DROP invalid"
add chain=forward connection-state=invalid action=drop comment="DROP invalid"

add chain=input connection-state=established,related action=accept
add chain=forward connection-state=established,related action=accept

# --- WAN側からの input は all drop（DHCPクライアントの更新等は別経路）
add chain=input in-interface=ether1 action=drop comment="DROP all from ISP(WAN)"

# --- ルータ管理：VLAN10 からのみ許可（Winbox/SSH/HTTPS 等）
add chain=input in-interface=vlan10-LAN src-address=10.10.10.0/24 action=accept comment="Mgmt from LAN"
# 必要なら VLAN20 からも限定許可
# add chain=input in-interface=vlan20-TRUST src-address=10.20.20.0/24 action=accept

# --- DNS サービス（全VLANからルータのDNSを使わせる）
add chain=input protocol=udp dst-port=53 in-interface-list=LAN action=accept comment="DNS UDP"
add chain=input protocol=tcp dst-port=53 in-interface-list=LAN action=accept comment="DNS TCP"

# インターフェイスリストでLAN系を包括
/interface list add name=LAN
/interface list member
add list=LAN interface=vlan10-LAN
add list=LAN interface=vlan20-TRUST
add list=LAN interface=vlan30-IOT

# --- VLAN間ポリシー ---
# 既定：相互隔離（必要な穴だけ下に書く）
# 1) IoT は他VLANへのアクセス禁止（DNSは input で受けるためOK）
add chain=forward in-interface=vlan30-IOT out-interface=!ether1 action=drop comment="Isolate IoT to others"

# 2) Trusted -> LAN を既定禁止（必要なら個別許可）
add chain=forward in-interface=vlan20-TRUST out-interface=vlan10-LAN action=drop comment="Block Trusted->LAN by default"

# 3) LAN(有線) 同士は許可（Mac/Linus/Console間のローカル通信）
add chain=forward in-interface=vlan10-LAN out-interface=vlan10-LAN action=accept comment="Allow LAN intra"

# --- WAN への出口ポリシー ---
# VLAN10(LAN) は WAN 禁止
add chain=forward src-address=10.10.10.0/24 out-interface=ether1 action=drop comment="Block LAN->WAN"

# VLAN20/30 は WAN 許可（上の established でOK。念のため明示）
add chain=forward src-address=10.20.20.0/24 out-interface=ether1 action=accept comment="Trusted->WAN"
add chain=forward src-address=10.30.30.0/24 out-interface=ether1 action=accept comment="IoT->WAN"

# --- ポート別要件（Port2/3） ---
# Port2=Mac（LAN内 NEW 制限なし）→ 既に VLAN10 intra を許可済み。WAN は上で禁止。
# Port3=Linux（NEW は allowlist のみ + ローカル）
#   1) Linux のIPまたはMACで識別（例はIP固定: 10.10.10.13）
/ip firewall address-list add list=linux-host address=10.10.10.13

#   2) Linux からの NEW を既定 drop（まずブロックしてから穴あけ）
add chain=forward src-address-list=linux-host connection-state=new action=drop comment="Linux NEW default drop"

#   3) 例外許可：LAN内（Mac/Console/ルータ）へは NEW 許可
add chain=forward src-address-list=linux-host dst-address=10.10.10.0/24 connection-state=new action=accept comment="Linux NEW to LAN allowed"

#   4) 例外許可：allowlist (FQDN/IP) 宛は NEW 許可
add chain=forward src-address-list=linux-host dst-address-list=allowlist-Linux connection-state=new action=accept comment="Linux NEW to allowlist allowed"

# --- 既定 DROP（最後尾） ---
add chain=input action=drop comment="Default drop input"
add chain=forward action=drop comment="Default drop forward"
  

Logical Design (Zone Separation)

An additional proposal divides Linux egress into two zones:

• VLAN10 (192.168.10.0/24) for updates
• VLAN15 (192.168.15.0/24) for long-running training or temporary internet-dependent work

Destination lists differ by purpose:

• dev-allow for apt, pip, npm, docker, github, and google
• temporary-allow for HuggingFace, Kaggle, and container registries

The design also considers physical topology, local switching, and routing limits.

Topology

The physical layout:

  ONU (VDSL)  →  CRS304 (Router)
                   |
                   |-- Port1 → WAN
                   |-- Port2 → Mac (1.12, primarily on Wi-Fi, wired for local-only use)
                   |-- Port3 → Linux server (1.13, wired for local-only use)
                   |-- Port4 → WiFi AP
                   |-- Port5 → Console
  

CRS304 has three roles:

1. the router directly attached to the ONU
2. the 10GbE switch for local Mac-to-Linux transfer
3. the aggregation point for household Wi-Fi and the local wired segment

Port2 and Port3 use local L2 switching without passing through WAN. RouterOS limits only the external path.

IP and Routing Layout

IP and routing roles:

Mac-to-Linux traffic stays local. Internet traffic follows the Wi-Fi AP, CRS304, and ONU path.

CRS304 Role

The proposal combines routing and local transfer in one device.

As a router

CRS304 connects to the ONU and handles NAT, DHCP, and firewalling. The expected performance is sufficient for roughly 100Mbps VDSL.

As a switch

Port2 and Port3 provide local 10GbE transfer without another switch.

As the integration point

Port4 connects the Wi-Fi AP, keeping household wireless clients on separate segments.

Operational Rules

Physical connections are also part of access control:

• leave Linux NIC3 unplugged by default
• connect it to ether2 only for the update zone
• connect it to ether3 only for the learning or temporary zone
• switch the matching IP and gateway on the Linux side

Wired links are for local work; egress uses Wi-Fi or an explicitly permitted path. Linux settings, cable placement, and RouterOS rules must all agree.

3) Wi-Fi AP Settings (Concept)

AP ether4 is a trunk for VLAN20 and VLAN30.

• one SSID maps to the trusted side
• one SSID maps to the IoT side

Routine Wi-Fi internet access remains separate from the restricted wired Linux path.

4) Additional Hardening Ideas

Possible additions:

• place AdGuard Home in front of upstream DNS to manage allowlists and denylists more comfortably
• add an mDNS relay only if cross-segment discovery is actually required
• keep log-prefixed drop rules so missing destinations can be identified from real traffic

FQDN policies also benefit from visibility into DNS behavior.

5) Validation Checklist

Baseline checks:

• Linux should not reach the WAN during normal operation
• dev-allow and temporary-allow should stay separate
• trusted Wi-Fi and IoT should remain segmented
• inter-VLAN traffic should stay closed unless explicitly allowed
• router management must not be exposed from the WAN side

Transfer and monitoring checks:

• Port2 and Port3 should provide local transfer without traversing the WAN path
• the Mac should remain usable without unnecessary friction
• Linux should stay local-first and only gain egress in narrow, intentional cases
• drop logs, login failures, and config changes should all be observable

Benefits of This Layout

VDSL and local 10GbE

The design assumes CRS304 can route 100Mbps-class VDSL while providing local 10GbE. Faster WAN routing needs reassessment.

An FTTH migration path

For 1G or 10G fiber, use CRS304 as a SwOS switch and add a router such as CCR, RB5009, or L009.

Power for continuous operation

The estimated power range is 15 to 21 watts, relevant to UPS-backed continuous use.

Switching Results

L2 switching figures:

• non-blocking Layer 2 throughput/capacity of roughly 39,480 Mbps to 40,000 Mbps
• even with 64-byte packets, about 30 to 40 Gbps

These figures guide local file and dataset transfer planning.

Ethernet Test Results

RouterOS paths involving the CPU:

Plain routing or bridging is around 2Gbps; filtering or queuing can reduce it to 0.5–1.0Gbps. This fits the VDSL assumption but needs reassessment for FTTH.

Physical layout and operating policy

  VDSL → CRS304 (RouterOS)
                   | (All RJ45)
                   |-- Port1 → WAN
                   |-- Port2 → Mac (1.12, primarily Wi-Fi, wired = local-only)
                   |-- Port3 → Linux server (1.13, wired = local-only)
                   |-- Port4 → Wi-Fi AP (1.11, IoT/Mobile segment)
                   |-- Port5 → Console
  

• CRS304 acts as both router and switch
• Mac and Linux use 10GbE for local transfer
• the Wi-Fi AP handles the internet-facing segment, separate from the local wired side

Firewall Policy

Core Policy

• drop all inbound traffic from the ISP side
• base outbound control on domain allowlists
• leave Mac unrestricted for new outbound sessions
• restrict Linux to approved authoritative domains
• allow established,related

Practical Enforcement

Linux on Port3 allows only approved new outbound sessions, such as apt, pypi, and ghcr.io; other destinations are dropped. Mac on Port2 has unrestricted new outbound sessions. Drop inbound traffic, restrict management to management addresses and SSH keys, and log drop rules for audits.

Metrics and Log Monitoring

Monitor device health separately from traffic anomalies.

SNMP exporter (Prometheus)

SNMP exporter collects CPU, memory, interface bandwidth, temperature, and uptime. Grafana shows sustained CPU load and bandwidth trends.

Syslog to Loki

Loki receives drops, SSH failures, configuration changes, and DNS anomalies. Example Grafana queries:

  count_over_time({job="routeros"} |= "DROP" [1m])
count_over_time({job="routeros"} |= "login failure" [5m])
  

Use these records to find missing allowlist destinations or unnecessary management access and raise alerts.

What the design establishes

The main points are:

• the CRS304 is currently sufficient as both router and switch in the VDSL environment
• local high-speed transfer between Mac and Linux can stay intact while outbound access remains tightly controlled
• Wi-Fi clients can be separated cleanly from the local wired segment
• the observability path is good enough to refine the policy later instead of guessing blindly

Operation and migration checks

When fiber or heavier filtering requires faster routing, reassess adding a dedicated router and moving CRS304 to SwOS switching.

First, monitor drops and bandwidth and add only necessary allowlist destinations.