Intego NetBarrier: Fix a Blocked App or No Internet

First route the symptom: one app, every app, one network or one service

“NetBarrier blocked my Internet” describes several incidents with different fixes. Open two unrelated websites in a normal browser, repeat the failed action in the problem app, test a local device if that's the complaint, and note whether a VPN is connected. Do this before editing a rule. A reproducible one-app failure points toward an application decision; a whole-Mac failure points toward an all-traffic control, extension or system network setting.

A single website is a separate clue. The browser may be online while ContentBarrier, DNS, a proxy, the site itself or a VPN exit is responsible. Don't turn a site-only problem into an application-wide firewall exception. The scope test is short, but it prevents most overbroad “fixes” that later become security debt.

Intego ONE and NetBarrier X9 expose the same idea through different controls

ONE’s current firewall is integrated into the ONE app. Its rules can target an app or Any app, choose Allow, Ask or Deny, choose incoming/outgoing/both and optionally narrow a hostname, IPv4/IPv6 address or TCP/UDP port. Its Security Switch is an emergency containment control that blocks all network traffic. The current ONE Firewall guide is the authority for those controls.

X9 is a separate NetBarrier application. It divides controls between Firewall channels and Applications, remembers network profiles, and allows application or channel exceptions. Its current X9 manual documents Home, Work, Public Hotspot and VPN profiles. Don't hunt for those X9 labels inside ONE or assume a ONE rule changed an X9 profile.

If you're unsure which generation is installed, check the application name and About screen before following screenshots. Our ONE versus X9 bundles guide explains the product split; this page stays focused on live connection decisions.

Capture a connection receipt before you change the firewall

Write down the time, failed action, application version, ONE or X9 version, macOS version, network name/type and VPN state. Capture the process name shown by ONE Network Monitoring/Rules or X9 Applications/logs; a visible app can rely on a separate updater, sync agent, login helper or browser service. The firewall makes a decision about the executable it sees, not the marketing name you recognize.

Record the current action, direction, profile, remote host/address, protocol and port when exposed. Take screenshots of relevant rules and exceptions. If the failure began after an app update, preserve both the old rule and new process identity until you understand the change. This receipt lets you reverse a bad edit and gives Intego support something more useful than “Internet stopped.”

Keep the test itself constant: same account, same app action, same network and same destination. Switching Wi-Fi, VPN server and firewall rule together may make the symptom disappear but can't tell you which change mattered. One variable at a time is slower for five minutes and much faster over an hour.

When one app is blocked, find the helper that actually made the request

Start the failing operation, then inspect recent traffic or application entries. A browser may work while a video client, backup tool or game fails because its own executable has a Deny rule. An app may load its shell but fail to sign in because an authentication helper or updater is the blocked process. Reveal the process in Finder where ONE offers that command; verify that its location and publisher fit the installed application before allowing it.

If the prompt is still visible, read the direction and destination before clicking. Allow Only Once in ONE is useful as a reversible proof: if the operation succeeds once and fails next time, the matching connection is identified. Ask can serve the same diagnostic purpose, but only when someone is present to answer; on unattended startup it can make a legitimate background service look dead.

Don't solve one failure by authorizing Any app, every direction and every destination. That removes the evidence boundary and gives unrelated software the same route. Exact application first; direction second; profile, host, protocol and port only when the application’s documentation or observed connection makes those constraints reliable.

Fix an Intego ONE rule from Network Rules or Monitoring

In ONE Firewall, open Network Rules and locate the executable tied to the failed action. Change a matching Deny to Allow or Ask, edit its scope, or remove a stale conflicting rule and let ONE prompt again. The current guide says a rule can be changed, edited or removed and the process can be revealed in Finder. Retest the exact action after saving; ordinary browsing isn't proof that the app’s helper now works.

Network Monitoring can provide the application and domain that were active at the failure time, then create a rule from that evidence. Be careful with the word Reset here: the ONE traffic-statistics guide uses Reset for application/domain data. That clears statistics, not firewall rules, and therefore doesn't repair a Deny policy.

ONE also offers broad settings for Apple-published, Intego-published, Mac App Store and other signed apps. The current interface guide strongly recommends Apple-published access and recommends Intego-published access because blocking those processes can affect macOS behavior or definition updates. Keep those expected defaults unless you have a documented reason, but don't enable every signed-app class merely to fix one third-party app.

Fix a blocked application in NetBarrier X9 without touching every channel

Open NetBarrier from the menu-bar castle icon or Applications → Intego, choose Applications, select the app, click Edit and change Block Connections to Allow Connections or Ask. Click Done, quit/reopen the app if necessary and repeat the failed action. These are the current steps in Intego’s February 2026 blocked-connection article.

If the visible app is already allowed, look for a helper with a related path or timestamp instead of changing the main rule repeatedly. Check the current profile too. X9 remembers the profile selected for a network, and a rule or local exception that worked at Home may not explain behavior at a coffee shop or office.

Use Firewall channel exceptions only when the failure genuinely belongs to Incoming Internet, Outgoing Internet, Incoming Local or Outgoing Local. The default profile is sufficient for most client use; editing a whole channel to rescue one application is a large blast radius. Application protection is the safer starting point.

Allow, Ask and Deny are policy choices—not “working,” “maybe” and “broken”

Allow permits traffic that matches every part of the rule. Deny blocks matching traffic. Ask pauses for a decision and can establish the policy from that response. X9 documents that an Ask application prompts on its first network attempt after login; ONE prompts can offer Allow, Deny or Allow Only Once. If the prompt is behind another window or no user is present, the application may time out while the firewall is waiting.

Use Allow when the exact process and required connection are expected. Use Ask while learning an unfamiliar but legitimate app’s pattern or where each new destination deserves review. Use Deny for traffic the app doesn't need, an unexpected helper, or a containment decision. An allow rule isn't a malware verdict; confirm the executable’s path and publisher before granting it.

Conflicting rules require context. A narrow Deny for one host can coexist with a broader Allow, and the product’s matching behavior may make the specific rule decisive. Remove obsolete duplicates and retest rather than piling a new broad Allow on top. Preserve a screenshot so a successful result can be tied to the actual edit.

Incoming and outgoing traffic solve different jobs; narrow the rule deliberately

Most ordinary browsing, sign-in, update and cloud-sync failures begin with an outbound client connection. Incoming rules matter when another device or Internet host initiates a connection to a service on the Mac—file sharing, remote control, a local development server or another listener. Opening incoming Internet access can't repair a blocked outbound updater and may expose a service unnecessarily.

Apple’s current macOS Firewall guide describes its controls in terms of unwanted incoming connections and receiving access for apps/services. NetBarrier/ONE also expose outbound and destination dimensions, so the two firewalls shouldn't be treated as identical switches. Check which layer produced the alert.

A well-scoped rule answers six questions: which app, which direction, which X9 profile/network, which host/address, which TCP or UDP protocol and which port. You don't need all six for every app. Add specificity only when the value is stable and authoritative; hard-coding a rotating cloud IP can break the app again tomorrow.

X9 Home, Work and Public Hotspot profiles explain “works here, fails there”

Home blocks new incoming Internet connections but lets the Mac act as a client and local-network server. Work also blocks new incoming Internet connections, while local server/file-sharing behavior requires approval. Public Hotspot blocks new incoming Internet and incoming local connections, leaving the Mac as a client. X9 also documents a VPN profile for compatible network behavior.

When X9 first sees a network, it asks for a type and remembers that choice. Verify Current Profile after moving between home, office, hotel and hotspot. A printer disappearing on Public Hotspot may be expected protection, not a corrupt rule. Don't label a hotel or shared office network Home merely to regain discovery; create a narrow local-device allowance only when you trust the network and need it.

If the wrong profile was saved, select the correct one and retest before modifying exceptions. Document the network name and selection. The profile is part of the connection receipt, and a support case without it can make two contradictory results look random.

Printers, NAS boxes and file sharing need local rules—not an open Internet door

Confirm that the Mac and device are on the same trusted local network, then test the device’s local address and the required service. X9 can add a local-device exception for a printer, Apple TV, server or other known endpoint. Prefer that device/address and the required local direction over allowing an entire incoming Internet channel.

Public Hotspot intentionally blocks incoming local connections. That protects the Mac from unknown neighbors but also suppresses discovery and sharing. If you own both devices, use a trusted private network or a scoped rule; don't weaken every public network profile for AirPlay or a printer that you use once.

macOS Sharing settings can also open or close services, and Apple notes that enabled sharing services may receive firewall access. If the service itself is off, NetBarrier can't make it exist. Verify the service, then the Apple incoming rule, then the Intego local channel—one layer at a time.

Port exceptions are for documented services, not the first unblock button

Use an application rule for an ordinary outbound app failure. A port exception becomes appropriate when a service listens on a known port, an official vendor requires a stable connection, or a local device can't reach a specific service. NetBarrier’s port-exception instructions can select incoming/outgoing channels and a process or explicit TCP/UDP port.

The process list doesn't automatically follow future ports. That limitation is protective: it prevents a rule created for one listener from silently opening every port that process might use later. Record the business reason and remove the exception when the service is retired.

Intego’s current NetUpdate error guide says ports 80 and 8079 are needed for downloads and authentication. Treat that as outbound client access. Verify the NetUpdate executable and existing Deny rule first; opening inbound ports or resetting all policy is the wrong direction and much broader than the stated need.

If the whole Mac is offline, check the all-traffic controls before app rules

In ONE, inspect Security Switch first. Intego describes it as a suspected-compromise containment control that blocks all network traffic and makes network/device communication unavailable. If it's on intentionally, the outage is expected; if it was enabled accidentally, turn it off only after confirming there's no active containment incident.

Next check whether Apple- and Intego-published application access remains at the recommended defaults, whether the network extension is enabled, and whether the failure affects Ethernet and Wi-Fi or only one service. In X9, verify protection state and Current Profile. A global Deny/channel exception or damaged filter state matters more than the main browser’s Allow rule.

Don't create Any app + Allow All to recover connectivity. It may mask the symptom while discarding application control. If you need causal proof, use the timed isolation test below and restore the layer immediately; then repair the exact rule, extension or profile.

Separate NetBarrier from ContentBarrier, VPN, proxy, DNS and Apple’s firewall

If ordinary browsing works after disconnecting Intego VPN, the base firewall isn't the only suspect. Record that result and move to the VPN-specific workflow; changing every NetBarrier rule won't fix a congested server or protocol negotiation. The next Intego cluster article owns that deeper job, while this page establishes the boundary.

If only selected sites fail, inspect ContentBarrier and the browser before firewall reset. If every app uses a broken proxy, compare System Settings → Network → active service → Details → Proxies with the approved configuration. Apple’s proxy guide shows where those values live. A work or school network may require them, so use a controlled test or administrator baseline rather than deleting managed settings permanently.

DNS trouble can also mimic a firewall failure: numeric connectivity may work while hostnames don't. A captive portal may block normal traffic until login. Test a second network only as evidence, not as a simultaneous permanent change. If the problem stays with one Mac across networks, the local filter stack becomes more likely; if it stays with one network across devices, look beyond Intego.

A disabled ONE network extension can create a permission loop or partial filtering

ONE’s current permission-loop article directs users to System Settings → General → Login Items & Extensions → Network Extensions, then to enable the Intego ONE extension and authorize the change with an administrator password. The exact grouping can vary by macOS release; use the current Apple settings search if the label moves.

A separate ONE firewall prompt may still ask about an application or system process after the extension is enabled. That's a traffic decision, not proof that the extension failed again. Record the process and choose the narrow policy that matches its role.

If toggling the extension is the only thing that restores connectivity, don't leave it disabled. Re-enable, reproduce once, capture ONE/macOS versions and filter state, then use Intego support or the clean-install procedure from our Intego macOS compatibility and permissions guide. Avoid stacking multiple third-party network filters during diagnosis.

App updates can leave a good-looking rule attached to the wrong executable

An updated application may install a new bundle, helper path, signing identity or updater process. The old Allow entry remains visible, but the new executable triggers Ask or Deny. Reproduce the failure, sort recent events by time, reveal the actual process and compare its path/publisher with the installed app. Then remove the stale duplicate and create a rule for the current component.

This pattern isn't unique to Intego. CrashPlan’s support documentation notes that firewall/security software may see an updated application as new. We use that as a practical signal, not as authority for Intego’s matching engine. The observed process and current Intego rule remain the evidence.

For NetUpdate itself, verify outbound access before broader edits. If antivirus definitions also fail, confirm your subscription and update plumbing through the Intego account and device guide; firewall policy and entitlement are separate causes that can produce a similar update button error.

Safe fix workflow: narrow the rule, retest, isolate once, reset last

1. Classify the outage. Test whether one application, every application, one website, one local device, one network or only the VPN is failing; don't change rules until the failure is repeatable.
2. Record the working context. Capture ONE or X9 version, macOS version, current network/profile, app and helper-process names, direction, destination, time and the last relevant prompt or update.
3. Check containment controls. For a whole-Mac outage, verify that ONE Security Switch isn't intentionally blocking all traffic and that the current X9 profile matches the network.
4. Find the exact process and rule. Use ONE Network Rules or Monitoring, or X9 Applications and logs, to connect the failed action to the executable and its Allow, Ask or Deny decision.
5. Fix the narrowest rule. Prefer the exact application and required direction; narrow further by profile, host, protocol and port only when official service documentation and observed traffic support it.
6. Retest the original action. Quit and reopen the application when needed, repeat the same operation on the same network, and confirm both the feature and ordinary browsing or local-device access.
7. Run a timed isolation test. If causality remains unclear, disable only the suspected Intego layer briefly, retest once, restore protection immediately and record whether the result changed.
8. Separate adjacent network layers. Test base Internet without VPN, compare proxy settings with the approved network configuration, check ContentBarrier for site-only failures and verify the ONE network extension.
9. Preserve policy before reset. Screenshot or inventory application rules, exceptions, profiles and local-device allowances; distinguish resetting traffic statistics from deleting firewall policy.
10. Reset last and rebuild narrowly. Only after NetBarrier is shown to be causal, use X9 Reset NetBarrier, select the correct default profile, recreate necessary rules one at a time and keep the evidence for support if the fault returns.

The ladder deliberately begins with evidence and an exact executable. Host, protocol and port constraints can improve safety when they're stable, but guessing them can create fragile rules. Reset isn't “deeper troubleshooting”; it's deletion of policy. Use it only when the layer has been proven causal and the existing state has been preserved.

Reset NetBarrier X9 only after preserving rules—and know how to recover

Intego’s current no-Internet troubleshooting article says to open NetBarrier, choose NetBarrier in the macOS menu bar next to the Apple menu, select Reset NetBarrier, confirm Reset, choose the default profile and click Continue. It explicitly says the process resets all previous settings.

Before doing that, capture application rules, four-channel exceptions, local-device allowances and the profile used by each relevant network. After reset, choose the correct profile—don't default an untrusted network to Home merely for convenience—and retest before recreating anything. Add back only required rules one at a time; if the fault returns after a specific exception, you have found the policy that needs correction.

If a short disabled-state test doesn't restore connectivity, reset is unlikely to be the best next move. Preserve the evidence and inspect proxy, VPN, ContentBarrier, extension and macOS network state instead. For support, include ONE/X9 and macOS versions, network/profile, exact process/path, rule action/direction, destination/protocol/port, timestamps, screenshots, whether another network works, and the result of the timed isolation test. Never send passwords, license keys or private traffic contents.