OPNsense / Troubleshooting
OPNsense VLAN Client Gets an IP Address but Has No Internet
Use the expected DHCP lease only as a scope gate, then separate gateway reachability, DNS-only failure, firewall blocking, Source NAT coverage, and WAN routing on OPNsense 26.7.3.
OPNsense filters traffic on the interface where it enters the firewall, and the default inbound policy blocks traffic when no pass rule matches. For a VLAN client going outward, the relevant policy is therefore on the client’s receiving VLAN interface or an applicable interface group, not a blanket WAN allow rule.[2]
OPNsense 26.7 uses Source NAT (Outbound). Automatic is the default and generates rules; Hybrid adds manual rules alongside automatic ones; Manual generates no automatic rules; Disable turns Source NAT off. The absence of a visible manual rule is therefore not evidence that NAT is missing.[3][1]
Applicability
- Products
- OPNsense
- Scope
- For OPNsense Community Edition 26.7.3 in the 26.7 Xenial Xenops series when a VLAN client receives the expected DHCP address, prefix, and default gateway from that VLAN but cannot reach the Internet. DHCP success proves the DHCP exchange completed on the expected logical segment; it does not prove gateway unicast reachability, firewall pass, routing, Source NAT, DNS, or Internet reachability. DNS-only failures exit this page.[1][4][5]
- Last verified
Symptoms
Quick diagnosis
Treat DHCP success only as a scope gate, then prove gateway, DNS, firewall, Source NAT, and WAN boundaries in order.
Confirm the lease really belongs to the intended VLAN
Record the client IPv4 address, prefix, default gateway, and DHCP scope. Treat the successful lease only as proof of DHCP exchange; do not infer complete VLAN tagging or gateway reachability from it.[4][5]
Test the VLAN gateway separately
Check whether the client can reach the OPNsense address configured as its VLAN default gateway. Failure here keeps the problem inside the local VLAN/gateway path and makes Internet firewall/NAT reasoning premature.[5][6]
Separate DNS-only failure from routing failure
Test a known external numeric IP independently from a hostname. If numeric connectivity works while names fail, exit to a DNS diagnosis; do not change firewall or Source NAT to solve a DNS-only symptom.[6][2]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceDoes the client have the expected VLAN lease and gateway?
The expected DHCP lease is the scope gate, not proof of later connectivity.[4][5]
Read the complete diagnostic tree without using the controls
- Does the client have the expected VLAN lease and gateway?
The expected DHCP lease is the scope gate, not proof of later connectivity.[4][5]
- Yes — expected lease and gateway → Can the client reach the OPNsense VLAN gateway?
- No — lease/gateway is wrong → Different diagnosis: DHCP/VLAN addressing problem
- Can the client reach the OPNsense VLAN gateway?
Test unicast gateway reachability separately from DHCP success.[5][6]
- Yes — gateway responds → Can the client reach an external numeric IPv4 address?
- No — gateway unreachable → Local VLAN-to-gateway path is broken
- Can the client reach an external numeric IPv4 address?
Numeric success separates DNS-only failure from the routing/NAT path.[6]
- Yes — numeric Internet works → DNS-only failure
- No — numeric Internet also fails → What do the firewall logs and rule counters show?
- What do the firewall logs and rule counters show?
Correlate the flow on the receiving VLAN interface or group and identify whether it is blocked or passed.[2]
- Blocked/default deny → Firewall policy blocks the VLAN flow
- Intended pass rule matches → Does effective Source NAT cover the VLAN source network?
- Unsure → Collect firewall, NAT, and route evidence
- Does effective Source NAT cover the VLAN source network?
Interpret coverage in the context of Automatic, Hybrid, Manual, or Disabled mode.[3]
- No — effective coverage is missing → Source NAT coverage is missing
- Yes — effective coverage is present → Is the selected WAN gateway/route healthy and intended?
- Unsure → Collect firewall, NAT, and route evidence
- Is the selected WAN gateway/route healthy and intended?
Record normal or policy-routed gateway selection before changing anything.[6][2]
- Yes — gateway and route look correct → Collect firewall, NAT, and route evidence
- No — gateway or route is wrong → WAN gateway or policy route is wrong
- Different diagnosis: DHCP/VLAN addressing problem
Correct the lease or VLAN assignment before reasoning about Internet policy.[4][5]
- Local VLAN-to-gateway path is broken
Keep firewall/NAT Internet changes out of this branch and repair the local VLAN path first.[5]
- DNS-only failure
Preserve routing and Source NAT and move to DNS troubleshooting.[2]
- Firewall policy blocks the VLAN flow
Correct only the proven receiving-interface policy under a backup and rollback boundary.[2]
- Source NAT coverage is missing
Correct the specific source-network coverage according to the active NAT mode; do not add duplicate rules blindly.[3]
- WAN gateway or policy route is wrong
Hand the gateway and route evidence to the operator before changing routing policy.[6][2]
- Collect firewall, NAT, and route evidence
Preserve the rules, logs, Source NAT mode, gateway selection, and timestamps rather than changing multiple network layers at once.[2][3][6]
Detailed diagnosis
1. Validate the expected DHCP evidence
Confirm the lease, subnet, and gateway belong to the VLAN under diagnosis. A wrong lease or wrong gateway is a DHCP/VLAN configuration problem and exits this page before firewall or NAT work.[4][5]
2. Test unicast reachability to the VLAN gateway
Verify the client can reach the OPNsense VLAN gateway address. If it cannot, inspect the local access/trunk/interface path under a separate VLAN procedure rather than adding Internet rules.[5][6]
3. Test an external numeric IP before a hostname
If the gateway responds, test an external numeric IPv4 address. Numeric success with hostname failure is a DNS-only exit. Numeric failure continues to firewall, routing, and Source NAT evidence.[6][2]
4. Inspect the rule and live-log evidence on the receiving VLAN
Use the rules view, Inspect counters, and Live View to determine whether the client flow is hitting a block/default-deny path or an intended pass rule. OPNsense documents that rules are evaluated on the interface receiving the traffic and that unmatched inbound traffic is blocked.[2]
5. Inspect the effective Source NAT mode and source-network coverage
Check whether Source NAT is Automatic, Hybrid, Manual, or Disabled and whether the effective rules cover the VLAN source network on the intended outbound path. Do not infer a missing NAT rule merely because no manual entry is visible in Automatic or Hybrid mode.[3][1]
6. Confirm the WAN gateway and route before changing the VLAN
If firewall and Source NAT evidence look correct, verify the WAN interface and gateway status and the route used for the flow. Policy-routing choices on a VLAN rule can override the normal default route, so record any selected gateway or group.[6][2]
Supported scenarios
These observations narrow the next investigation; they do not establish a unique cause.
The client cannot reach the VLAN gateway
The lease succeeded, but unicast traffic from the client to the configured VLAN gateway does not. DHCP success alone cannot prove the complete Layer-2 path or later unicast reachability.[4][5]
How to check: Confirm the expected lease, then test the VLAN gateway directly before any Internet rule or NAT change.[4][5]
The VLAN flow is blocked by policy or rule ordering
OPNsense applies inbound filtering on the receiving interface and uses a default block when no pass rule matches. A blocked log or rule counter therefore identifies the policy boundary.[2]
How to check: Correlate the client source, destination, and timestamp with Live View and the applicable VLAN/group rules.[2]
The effective Source NAT configuration does not cover the VLAN source network
Outbound IPv4 traffic normally needs Source NAT when private clients share the external address. In Manual mode no automatic rules are generated; in Automatic and Hybrid modes they are. The relevant evidence is the effective mode and source-network coverage.[3]
How to check: Inspect the active Source NAT mode and the rule coverage for the VLAN source network and intended outbound interface.[3]
The WAN or selected gateway path is unavailable or wrong
A pass rule can select a gateway for policy routing, and gateway state affects the outbound path. If filtering and NAT are correct but the chosen gateway or route is wrong, the VLAN still has no external connectivity.[6][2]
How to check: Record the rule’s gateway selection, gateway status, and effective route before altering the VLAN.[6][2]
Next actions and procedure boundaries
Gateway unreachable: keep Internet policy unchanged and repair the local VLAN path
When the client cannot reach the VLAN gateway, stop this Internet diagnosis. Hand off the lease, client port/SSID, VLAN ID, OPNsense parent/assignment, and gateway evidence to the local VLAN procedure. Do not add allow-any rules or Source NAT to compensate for a broken local path.[5][4]
Correct only the proven VLAN firewall policy
If Live View or rule counters prove the intended outbound flow is blocked, add or correct the least-privilege pass policy on the receiving VLAN/interface group according to the intended network policy. Do not use an unrestricted allow-any-any rule as the default remedy, and do not disable the firewall.[2]
Before changing anything
- Risk
- Firewall rule changes can expose services or alter traffic for the entire VLAN, not only the test client.[2]
- Safer check
- Record the current rule order, interface/group, source network, destination scope, gateway selection, and the exact blocked log entry before editing.[2]
- Expected result
- The intended outbound flow matches the new or corrected rule, unrelated blocked traffic remains blocked, and the rule counters/logs confirm the expected policy.[2]
- Backup / recovery access
- Export or otherwise preserve the current OPNsense configuration and record the exact pre-change ruleset details.[2]
- Rollback
- Disable or restore the changed rule to the recorded state if the intended flow still fails or unintended traffic becomes allowed.[2]
Correct Source NAT only when effective coverage is proven missing
If the effective Source NAT mode and rules prove the VLAN source network is not translated, correct that specific coverage. In Automatic mode, investigate why the expected generated rule is absent rather than blindly adding duplicates; in Hybrid or Manual mode, add only the necessary explicit rule for the intended source and outbound path.[3][1]
Before changing anything
- Risk
- Source NAT changes alter return-path behavior for the whole matched source network and can break existing sessions or policy routing.[3]
- Safer check
- Record the current Source NAT mode, generated/manual rules, VLAN source network, translation target, and outbound interface before editing.[3]
- Expected result
- The VLAN’s external flow is translated on the intended outbound path while existing internal networks continue to use their previous translations.[3]
- Backup / recovery access
- Export or preserve the current OPNsense configuration and record the old Source NAT mode and rules.[3]
- Rollback
- Restore the previous Source NAT mode/rules if connectivity does not recover or another network’s outbound path changes.[3]
Correct a proven gateway or policy-routing boundary
If the flow is allowed and translated but the selected WAN gateway or route is unavailable or incorrect, hand the gateway status, rule gateway selection, and route evidence to the operator. Gateway-group and policy-routing changes are outside this narrow page unless the exact desired path and recovery plan are known.[6][2]
Numeric connectivity works: exit to DNS troubleshooting
If an external numeric IP works, preserve firewall, routing, and Source NAT. Continue with a DNS-specific diagnosis instead of changing the Internet path.[2]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-08. Reachability and automated validation do not replace editorial verification of each claim.
- OPNsense 26.7 Xenial Xenops series release notes
Deciso B.V. · Tier A · accessed 2026-09-08 - OPNsense firewall rules manual
Deciso B.V. · Tier A · accessed 2026-09-08 - OPNsense Network Address Translation manual
Deciso B.V. · Tier A · accessed 2026-09-08 - OPNsense DHCP manual
Deciso B.V. · Tier A · accessed 2026-09-08 - OPNsense VLAN and LAGG setup
Deciso B.V. · Tier A · accessed 2026-09-08 - OPNsense gateways manual
Deciso B.V. · Tier A · accessed 2026-09-08