Separate device discovery, local connectivity and login failures when a printer or NAS stops working with Falemon connected. Use controlled comparisons, targeted permissions and a redacted support record instead of disabling the firewall.
Internet access and local access are different tests
Use this guide when ordinary websites work but a home network printer, NAS or shared folder becomes inaccessible after you connect Falemon. It does not assume that your client version offers LAN access, split routing or a kill switch. Check the actual application and its documentation rather than borrowing another product’s settings.
A directly attached USB printer is a different case: start with the cable and driver if that is what fails. On a company device, guest network or hotel Wi-Fi, do not enable sharing to work around intentional isolation. Organizational restrictions need an administrator, not a workaround.
Create a reproducible before-and-after comparison
- On a trusted home network, pause uploads, synchronization and sensitive activity. Record the Wi-Fi name and the local addresses of your computer and target device, using the device display or an authorized router interface.
- While disconnected from the client, access that same device or print a nonsensitive test page. If it already fails, investigate device availability or the home network first.
- Connect the client without changing Wi-Fi, device address or test method. Repeat the same action so that only one condition changes.
- Where safe and permitted, restore the original state and repeat once more. If failure is specific to the connected state, record the time and exact behavior before considering a reset.
An illustrative computer address of 192.168.50.20 and printer address of 192.168.50.40, both with mask 255.255.255.0, are on the same IP subnet. These are not your actual addresses, and they do not guarantee communication: wireless isolation, guest networks, VLANs or firewall rules can still interfere.
Distinguish discovery, connectivity and authentication
A missing device in an automatic list is not the same as an unreachable device. For a NAS you are authorized to use, compare its usual hostname with a vendor-supported IP-based method. For printers, use a supported system or vendor setup method rather than guessing protocols, ports or share names.
- Name fails but a verified IP-based method works: investigate name resolution or discovery first. Repeated node switching is unlikely to isolate that difference.
- Both fail only while connected: record permissions, client policy and routing differences for support.
- The login screen opens but rejects credentials: check the NAS account or share permissions separately.
- A print job is accepted but no page appears: inspect the queue, device condition and driver rather than assuming routing is at fault.
A failed ping alone does not prove a device is offline. Likewise, opening an HTTPS management page by IP can produce a certificate-name mismatch. Do not bypass that warning and submit a password to finish the test; record it and use an approved device entry point.
Check only the relevant system permissions
Windows public and private network profiles affect discovery and sharing. Review the profile only on a home network you trust and control; do not classify a hotel or café network as private. A printer shared through another PC also depends on that host being awake and on the correct share name and credentials.
Microsoft: Essential network settings
Microsoft: Shared printer connection problems
On macOS versions that provide the Local Network permission control, inspect the relevant trusted application under Privacy & Security. Do not grant access to every application or delete the permission database because an app is missing. Settings names can differ by release.
Apple: Control local network access
Record the original setting and change one item at a time. Keep the firewall enabled. If a rule is genuinely necessary, ask an administrator to scope it to the trusted network, application and minimum service. Enabling obsolete protocols or exposing file-sharing ports to the public internet is not a home-printing fix.
Treat routes and client options as evidence, not assumptions
A VPN can change the path to an address, and overlapping home and remote subnets can create ambiguity. These are possibilities to investigate, not a diagnosis from one failed page. Windows route print and Mac netstat -rn are read-only ways to inspect routes. If you cannot interpret the output, share only the relevant redacted entries with support; do not copy route-deletion commands from an unrelated guide.
If the installed client has a documented LAN-access option, understand which local traffic it permits before testing it on a trusted network. Local access does not establish how every application’s internet traffic is routed. If the feature is absent, do not install an unknown patch or modify application files to manufacture it.
Avoid changing DNS, disabling protection, switching nodes and reinstalling adapters in one attempt. Even a successful result would not identify the cause. If temporary disconnection is permitted for printing, pause sensitive internet work first, then reconnect and verify the protection state you require. It should not become an unexamined permanent workaround.
Send a concise, redacted support record
OS and client version:
Target: printer / NAS / shared folder
Trusted home network or managed/guest network:
Before connection: name__ IP__
After connection: name__ IP__
After restoring original state:__
Exact error and time:
Local permissions and one setting tested:Remove public addresses, complete internal topology, account names, private filenames and device serial numbers before sharing. Private IP addresses are not passwords, but a full network map should not be posted publicly. Remove unnecessary temporary queues and revert changes that did not help.
- Stop if the next step requires bypassing organizational policy, removing protection or exposing a local service publicly.
- If every state fails, return to device and LAN checks. If only one state fails, preserve the comparison and contact support.
- After recovery, check normal browsing, the local device and the original workflow. A printer appearing in a list does not prove every path is safe.
The aim is a repeatable difference that someone can diagnose, not a promise that one checkbox will fix every client. Keep local access, internet connectivity and security requirements as separate acceptance checks.
Related guides
View the complete troubleshooting library, or organize the information to contact the support team