RouterOS Firewall Visualizer

🌐 Website

A single-file HTML tool that turns your Mikrotik RouterOS firewall rules into an interactive network topology diagram.

Features

• 🎨 Visual Network Topology - See your IP addresses, networks, interfaces, and connections at a glance
• 🖱️ Interactive Drag & Drop - Rearrange nodes and connection labels freely
• ⚙️ Customizable Layout - Adjust circle radii, connection curves, and node sizes
• 💾 Export to PNG - Save your diagram as an image
• 📄 Export to SVG - Save your diagram as a scalable vector graphic
• 🚀 Zero Dependencies - Just HTML, CSS, and vanilla JavaScript

Usage

1. Download index.html
2. Open it in your browser
3. Paste your RouterOS firewall rules (from /ip firewall filter print)
4. Click "Generate Diagram"
5. Drag nodes and labels to customize the layout
6. Export your diagram as PNG or SVG using the download buttons

What It Shows

• IP addresses and networks as nodes
• Interfaces (ether2, wg1, etc.) as nodes
• Interface lists (WAN, LAN, etc.) as nodes
• External IP addresses and connections
• Port mappings and protocols
• Connection types (Internal, External)
• Public access warnings for nodes with open ports

How It Works

The visualizer processes ACCEPT rules from your RouterOS firewall configuration:

• Rules with explicit src-address and dst-address create connections between IP addresses/networks
• Rules with in-interface or out-interface create connections from/to interfaces
• Rules with in-interface-list or out-interface-list create connections from/to interface lists
• Disabled rules (marked with X flag) are automatically ignored
• Connection-state rules (established, related, untracked) are skipped as they handle return traffic

Limitations

Drop Rule Deduction: The visualizer does not attempt to deduce connections from DROP rules (e.g., drop in-interface=!ether2). While it might seem logical that such a rule implies ether2 can connect, this deduction would be incomplete and potentially misleading because:

1. Missing Context: A drop rule only tells us what is blocked, not what is actually allowed. The actual allowed connections depend on ACCEPT rules that appear earlier in the rule chain.

2. Complex Logic: RouterOS firewall rules are processed in order, and a connection is allowed if it matches an ACCEPT rule before hitting a DROP rule. Simply inverting a DROP rule doesn't give us the full picture of what's allowed.

3. Multiple Conditions: Drop rules often have multiple conditions (interface + address + port + protocol), and inverting all of them correctly would require understanding the complete rule chain logic.

Interface-Based Connections: Connections from interfaces (like in-interface=wg1) work great when they appear in ACCEPT rules with explicit destinations. The visualizer shows these connections clearly.

Example

Try pasting this sample RouterOS firewall configuration to see the visualizer in action:

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 4    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

 5    chain=input action=accept protocol=udp dst-port=49536 log=yes log-prefix="wireguard" 

 6    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN log=no log-prefix="drop not from lan" 

 7    ;;; drop all not coming from ether2
      chain=input action=drop in-interface=!ether2 log=no log-prefix="drop not coming from ether2" 

13    chain=forward action=accept src-address=10.0.1.100 dst-address=10.0.0.0/24 in-interface=ether3 out-interface-list=WAN 

14    ;;; WG: Allow DNS UDP
      chain=forward action=accept protocol=udp dst-address=10.0.1.50 in-interface=wg1 dst-port=53 

15    ;;; WG: Allow DNS TCP
      chain=forward action=accept protocol=tcp dst-address=10.0.1.50 in-interface=wg1 dst-port=53 

16 X  ;;; WG: Allow HTTP
      chain=forward action=accept protocol=tcp dst-address=10.0.1.10 in-interface=wg1 dst-port=80 

17    ;;; WG: Allow HTTPS
      chain=forward action=accept protocol=tcp dst-address=10.0.1.10 in-interface=wg1 dst-port=443 

18    ;;; WG: Allow SSH
      chain=forward action=accept protocol=tcp dst-address=10.0.1.0/24 in-interface=wg1 dst-port=22 

19    ;;; WG: Allow return traffic
      chain=forward action=accept connection-state=established,related out-interface=wg1 

20    ;;; WG: Drop all other traffic
      chain=forward action=drop in-interface=wg1 log=no log-prefix="wg1 drop" 

24    chain=forward action=accept protocol=tcp src-address=10.0.2.11 dst-address=10.0.1.200 in-interface=ether2 out-interface=ether3 dst-port=8006 log=no log-prefix="" 

25    chain=forward action=accept protocol=udp dst-address=10.0.1.50 dst-port=53 log=no log-prefix="dns" 

26    chain=forward action=accept protocol=tcp dst-address=10.0.1.50 dst-port=53 log=no log-prefix="" 

48    chain=forward action=accept dst-address=10.0.1.10 log=no log-prefix="" 

49    chain=forward action=accept src-address=10.0.2.14 dst-address=10.0.1.100 in-interface=ether2 out-interface=ether3 log=no log-prefix="" 

50    chain=forward action=accept src-address=10.0.2.11 dst-address=10.0.1.100 in-interface=ether2 out-interface=ether3 log=no log-prefix="" 

64    chain=forward action=drop dst-address=10.0.1.0/24 

67    chain=forward action=accept dst-address=!10.0.0.0/24 out-interface-list=WAN log=no log-prefix="" 

68    chain=forward action=drop log=no log-prefix="drop forward" 

Notes

• Rules marked with X (disabled) are automatically ignored
• Rules marked with I (invalid) are automatically ignored
• Rules marked with D (dynamic) are processed normally