UniFi Route Troubleshooting: Routing Tables, Forwarding State, and Packet Paths
Tech GuruQuick Answer
Compare the intended route with installed forwarding state and a real client flow. Record the source, destination, policy, next hop, health state, and observed egress before breaking a test next hop. Repeat the flow during failure and after recovery, including replies and existing sessions. A table entry alone does not prove where a packet went. The specific Network 10.4 FIB-view claim still needs device-and-version evidence.
Evidence status: The cited 10.4 announcement confirms routing-table enhancements but does not establish the exact FIB view or its device coverage. No UI capture, forwarding dump, traceroute, or packet capture is supplied. The checks below are a planned path investigation, not a verified UI walkthrough.
What To Check
Ubiquiti's 10.4 announcement discusses routing-table integration for eBGP and OSPF. It does not, on its own, support calling a particular screen a FIB view. Confirm the exact screen and gateway firmware before relying on that view.
UniFi policy-based routing can select an interface or tunnel according to traffic conditions. For that reason, the planned investigation must include the matching policy as well as a destination route. Distinguish an eligible forwarding entry from packet evidence showing the selected flow actually leaving an interface.
Key Concepts In Plain Language
- FIB: Forwarding Information Base, the installed forwarding information. It is a state record, not a packet history.
- Policy-based routing: A route choice based on matching traffic conditions, to inspect alongside destination routes.
- Flow evidence: Correlated source/destination, protocol, timestamps, egress and reply observations; these tie a routing explanation to actual traffic.
Technical Checklist
- Create competing static, policy, VPN, and default routes whose expected preference and health behavior are documented in advance.
- Break one next hop safely and compare the saved route, FIB installation, SLA or health state, traceroute, and packet capture.
- Test return-path symmetry and session behavior because the outbound FIB alone does not prove replies follow a compatible path.
- Restore the next hop and observe failback timing, route reinstallation, and whether long-lived sessions remain pinned or reset.
Interactive Operating Model
Use the detailed runbook and acceptance checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Use one client and a noncritical destination in a controlled topology. Save gateway and policy configuration, record an independent management path, and define the expected normal/failure/recovery routes. Do not break a next hop that is also the only way to administer the gateway.
- Export the current router, firewall, resolver, wireless, and switching configuration before changing policy.
- Keep direct management access that does not depend on the service or route being tested.
- Use one canary client or site and record the expected path before applying a fleet-wide setting.
- Test a negative case as well as a successful case; a green dashboard alone is not path evidence.
Go, Hold, Recover, Or Escalate
Hold the fault test if you cannot identify the policy/table being inspected or keep management access independent of it. Do not broaden a routing exception when only one client's result has been explained.
Planned Checks And Recovery
Step 1: Identify one flow and its expected route
Record the source client, destination, protocol, applicable static/default/VPN routes, matching policy, and health checks. Note application and gateway versions. Write down which path should be used normally and what should happen when the chosen next hop fails.
Step 2: Capture state and observed traffic
Use supported inspection facilities for the gateway to capture installed forwarding state and policy. Pair that with a client traceroute and a narrowly filtered packet capture at the relevant boundary. Keep timestamps aligned. Do not call the route entry proof of egress or omit the return path.
Step 3: Fail only the test next hop
Introduce the preplanned fault in the isolated or bounded test. Repeat the same client transaction and capture health-state changes, table changes, and observed traffic. Compare existing sessions with new connections instead of assuming they behave identically.
Step 4: Restore and observe failback
Restore the next hop and observe route reinstallation, health state, and traffic again. Record failback timing without inventing a target value. Check whether long-lived sessions continue, remain on another path, or reset, and verify replies still reach the client.
Step 5: Close the investigation
Return configuration to the recorded state, confirm management access and policy-denied traffic, and verify the alert reached an independent channel. Keep unresolved differences between the table and capture open; do not mark the route proven on the strength of a screenshot alone.
Validation Checklist
- The tested flow has a recorded source, destination, protocol, applicable policy, and expected path.
- Installed state and actual egress/reply observations are correlated by time rather than conflated.
- Failure and failback include health state, new connections, long-lived sessions, and return-path checks.
- Configuration recovery, denied-access policy, management reachability, and independent alerts pass before expanding the change.
Troubleshooting
- The configured route is not used: Compare installed state, matching policy, and next-hop health with the specific flow.
- Outbound traffic is visible but replies fail: Investigate the return path and session behavior instead of treating outbound forwarding as end-to-end success.
- Old and new sessions differ after failback: Record both cases and compare their observed paths before resetting state or changing policy.
Security, Privacy, Legal, And Recovery Boundaries
Security
Keep management interfaces off untrusted networks, sanitize captures before sharing, and avoid weakening authentication merely to make a test pass.
Privacy
DNS logs, packet captures, client addresses, and wireless telemetry can reveal people, sites, and browsing patterns; collect the smallest useful sample and control retention.
Legal
Only impair or capture traffic on systems you own or are authorized to administer, and follow local communications and privacy requirements.
Recovery
Preserve a direct management path, a configuration export, and the exact commands or UI changes required to restore the last known working route or policy.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No packet path, failover interval, or FIB-screen availability has been verified on a UniFi gateway. The specific UI and device coverage still require verification. The test plan does not guarantee route preference or session continuity for untested firmware, policy combinations, VPNs, or sites.
Related TechGeeks Resources
- Networking Field Notes: Start Here
- 15 Router Security Settings to Audit Before Something Breaks
- What Should You Monitor in a Homelab?
References
Next Action
Keep a correlated route/policy/capture record for the failing flow. Resolve the exact FIB-screen and firmware scope before presenting this as a Network 10.4 UI guide.
