- Organized 252 files across project - Root directory: 187 → 2 files (98.9% reduction) - Moved configuration guides to docs/04-configuration/ - Moved troubleshooting guides to docs/09-troubleshooting/ - Moved quick start guides to docs/01-getting-started/ - Moved reports to reports/ directory - Archived temporary files - Generated comprehensive reports and documentation - Created maintenance scripts and guides All files organized according to established standards.
4.3 KiB
Omada Cloud Controller - Firewall Rules for Blockscout
Date: $(date)
Issue: HTTP 502 from Blockscout via Cloudflare Tunnel
Solution: Check and configure firewall rules via Omada Cloud Controller
🌐 Accessing Omada Cloud Controller
Option 1: Web Interface (Recommended)
-
Navigate to Omada Cloud Controller:
https://omada.tplinkcloud.com -
Login with TP-Link ID:
- Use your TP-Link account credentials
- Your Omada Controller should appear in the list
- Click Launch to access your controller
-
Navigate to Firewall Rules:
- Click Settings (gear icon)
- Click Firewall in left sidebar
- Click Firewall Rules tab
Option 2: Direct Controller Access (If Cloud Access is Enabled)
If your controller has cloud access enabled, you can also access it directly at:
https://192.168.11.8:8043
Use your Omada Controller admin credentials (not TP-Link ID).
🔍 Checking Firewall Rules for Blockscout
Blockscout Network Details
| Component | IP Address | Port |
|---|---|---|
| Blockscout Container | 192.168.11.140 | 80 |
| cloudflared Container | 192.168.11.7 | - |
| Network Subnet | 192.168.11.0/24 | - |
What to Look For
-
Blocking Rules:
- Any rule with Destination IP =
192.168.11.140and Action = Deny - Any rule with Destination Port =
80and Action = Deny - Default deny policies
- Any rule with Destination IP =
-
Allow Rules:
- Rules allowing traffic from
192.168.11.0/24to192.168.11.140:80 - Rules with Action = Allow and Protocol = TCP
- Rules allowing traffic from
-
Rule Priority:
- ✅ Allow rules must be ABOVE deny rules in priority
- ⚠️ Rules are processed top to bottom (high priority → low priority)
✅ Creating Firewall Allow Rule
If no allow rule exists, create one:
Rule Configuration
Name: Allow Internal to Blockscout HTTP
Enable: ✓ Yes
Action: Allow
Direction: Forward
Protocol: TCP
Source IP: 192.168.11.0/24 (or leave blank for "Any")
Source Port: (leave blank for "Any")
Destination IP: 192.168.11.140
Destination Port: 80
Priority: High (must be above any deny rules)
Steps
-
In Omada Controller (via cloud or local):
- Navigate to Settings → Firewall → Firewall Rules
-
Click Add or Create Rule button
-
Configure the rule as shown above
-
IMPORTANT: Set priority HIGH (drag rule to top of list, or set priority value higher than deny rules)
-
Click Save or Apply
-
Wait for configuration to apply to router (may take a few seconds)
📋 Verification Steps
After creating the firewall rule:
-
Test connectivity from cloudflared container:
# SSH to Proxmox host ssh root@<proxmox-host> # Test from cloudflared container (VMID 102) pct exec 102 -- curl -v http://192.168.11.140:80/health -
Expected result:
- Should return HTTP 200 with JSON response
- Should NOT return "No route to host" error
-
Test Blockscout via Cloudflare Tunnel:
curl https://explorer.d-bis.org/health- Should return HTTP 200 (not 502 Bad Gateway)
🔧 Troubleshooting
If "No route to host" persists:
-
Check rule priority:
- Ensure allow rule is above deny rules
- Rules at the top have higher priority
-
Check rule is enabled:
- Verify the rule has "Enable" checkbox checked
-
Check for overlapping deny rules:
- Look for deny rules with broader matching (e.g., destination
192.168.11.0/24) - Ensure allow rule has higher priority
- Look for deny rules with broader matching (e.g., destination
-
Check router configuration:
- Verify firewall is enabled on the router
- Check if there are router-level firewall settings
-
Test from different source:
- Try testing from another host on the same subnet
- This helps isolate if the issue is specific to cloudflared container
📝 Notes
- Both cloudflared (VMID 102) and Blockscout (VMID 5000) are on the same subnet
- Traffic on the same subnet should typically be allowed by default
- If blocked, there's likely an explicit deny rule or restrictive default policy
- The "No route to host" error indicates a firewall/routing issue (not DNS)
Last Updated: $(date)
Status: Manual configuration required via Omada Controller web interface