In this article
Use this article to enable and configure Travel Wi-Fi mode for macOS Roaming Clients, a feature introduced in version 2.3.8 of the macOS agent that helps macOS devices load captive portals on networks such as airplanes, hotels, and airports while maintaining DNS protection.
What Travel Wi-Fi mode does
Travel Wi-Fi mode temporarily allows the device to use the Wi-Fi network’s DNS so captive portals can load correctly. During this short window (default 60 seconds), the macOS agent sends each DNS request to two places:
- The network’s DHCP DNS server (used by captive portals)
- The DNSFilter resolvers
The agent applies the following decision logic:
- If DNSFilter resolvers return a block, the request remains blocked
- If DNSFilter resolvers return an allow, the DHCP DNS answer is used so the captive portal can load
- If the DNSFilter resolvers are unreachable, DHCP DNS is used automatically, matching real captive portal behavior
When the countdown expires, full DNS protection resumes without additional action.
Prerequisites
- Running macOS Roaming Client v2.3.8 or higher
- Permissions to edit Application Support device settings
- Access to a text editor app such as TextEdit or Sublime Text
Enable Travel Wi-Fi mode
Travel Wi-Fi mode is controlled through the agent's daemon.config file. Follow these steps to edit the file to use Travel Wi-Fi mode.
Step one: Update file permissions
The daemon.config file permissions need set to Read & Write to update the file. Follow these steps from the end-user device after deploying the v2.3.8 agent.
- From the mac home screen, open Finder
- From the Finder menu bar, select Go
- Select Go to Folder and enter:
/Library/Application Support - Navigate to the DNSFilter folder (DNS Agent for whitelabeled agents) and right-click to Get Info
- Under Sharing & Permissions, select the Lock icon and enter the local user authentication
- Set Admin (or Everyone) to Read & Write
- Select the Lock icon again to save the settings and close the agent info window
- Open the DNSFilter/DNS Agent folder
- Navigate to the daemon.conf file and right-click to Get Info
- Under Sharing & Permissions, select the Lock icon and enter the local user authentication
- Set Admin (or Everyone) to Read & Write just like the folder in step 6 above
- Select the Lock icon again to save the settings and close the agent info window
The daemon.config file can now be edited to set Travel Wi-Fi mode.
Step two: Edit daemon.config
- Open the daemon.conf file in a text editor (TextEdit; Sublime Text)
- At the very top of the file, insert this configuration line:
allowExtensionBypass=true
🚨 Important: Place this line above[log]section of the daemon.config file, as shown in the image above. - Save the updated file and close the text editor
Example (default timeout)
allowExtensionBypass=true [log] level = "debug" [client] secret_key = "<your site key>" [misc] local_dns_and_domains = ""
Optional: change the timeout
The default timeout is 60 seconds. To use a different value, add captive_portal_delay=<seconds> below allowExtensionBypass=true
Example (45-second timeout)
allowExtensionBypass=true captive_portal_delay=45 [log] level = "debug" [client] secret_key = "<your site key>" [misc] local_dns_and_domains = ""
Step three: Restart the macOS agent
After saving daemon.config file, restart the agent:
- From the mac home screen, navigate to Terminal and unload the helper
- Copy this command into Terminal and hit Return to run the command
sudo launchctl unload /Library/LaunchDaemons/com.dnsfilter.agent.macos.helper.plistsudo launchctl unload /Library/LaunchDaemons/io.netalerts.agent.macos.helper.plist
- Enter the local device password if prompted
- Wait until the tray icon shows the agent is disconnected
- Copy this command into Terminal and hit Return to run the command
- After the agent shows disconnected, reload the helper following the same steps with this command:
sudo launchctl load -w /Library/LaunchDaemons/com.dnsfilter.agent.macos.helper.plistsudo launchctl load -w /Library/LaunchDaemons/io.netalerts.agent.macos.helper.plist
✍️ The agent should reconnect within seconds. If it does not, click the tray icon and follow the Fix Installation Issues prompt to restart the agent.
After restart, the macOS tray menu displays a Travel Wi-Fi option.
Activate Travel Wi-Fi mode
Click Travel Wi-Fi to initiate a captive portal session to complete the Wi-Fi login process.
When activated:
- The tray displays Travel Wi-Fi Active (XXs)
- A countdown shows how long the temporary captive portal mode will remain active
Travel Wi-Fi mode automatically ends when the timer expires, restoring full filtering.
Comments
23 comments
Is there a way to prevent a user from taking advantage of the Travel Wi-Fi mode?
Is there a way to create a cooldown for this feature?
Is there an admin guide on how to manage this new Travel Mode from an MDM such as Jamf Pro? We cant expect our end users to make all of these manual changes without IT support. We never want to tell users to make POSIX permission changes, nor do we allow local admin access from user accounts. Expecting customers to make this change is unacceptable. This is a poor implementation of a ‘solution’. It's a non-starter.
If I have no choice, I'd prefer to just curate my own configuration file (/Library/Application Support/DNSFilter Agent/daemon.conf), and deploy with via a script or a pkg, this way I can retain the root:admin POSIX permissions, and simply prepend the new required ‘allowExtensionBypass=true’ key myself across my entire Mac laptop fleet. I would deploy our customized config file at deployment time on new Macs, and as a 1-time remediation policy in Jamf Pro MDM for existing Macs (making sure to restart the DNSFilter daemon at the end of the policy, and also making sure our org-specific license code "secret_key" is in place).
Is my proposed deployment method supported? Can you provide a doc from enterprise customers please?
Notes:
1 Why can't the new "allowExtensionBypass" key be managed from the DNSFilter admin console from a single point, rather than manually editing a flat file on every single endpoint? Or how about providing a GUI button inside the DNSFilter client “Enable Travel Wi-Fi Mode”?
2 Can the key ‘captive_portal_delay’ be sent to a longer time than 60, say, 120 seconds?
3 Can the new config be deployed to Macs running versions older than 2.3.8? Example: Will it cause issues if we deploy it to DNSFilter 2.2.0 proactively before they get auto-updated to 2.3.8?
4 Apple advises against using deprecated load and unload verbs in launchctl: Try running `launchctl bootout` as root for richer errors. Load failed: 5: Input/output error Try running `launchctl bootstrap` as root for richer errors. Your manual instructions should be updated.
5 MacOS has never had a “System Tray” like Windows. It's referred to as simply the macOS menu bar. Just an FYI about Apple's parlance.
6 Why's is this ‘feature’ named “Travel Wi-Fi Mode”? I go to my local cafes all the time that require captive portals, and I'm not “traveling” at all - Im just working. Shouldn't it be named “Captive Portal Mode”?
Alex Hovsepian and Daniel Stranathan Thanks for reaching out, and happy to address your questions.
Alex: Even in Travel Wi-Fi mode filtering policies still apply—an attempt to a domain blocked by the device's policy will still be blocked—so curious what sort of advantages you're concerned about. Also, unclear what you mean by “cooldown,” so if you'd like to add more detail I'm happy to submit a feature request on your behalf if it's something that's feasible!
Daniel: The short answer for you is MDM support is in our next release (v2.3.9), which is in testing as of late last week. We opted to release this feature as a manual configuration adjustment first because we didn't want to delay for environments that allow end-user's admin rights that experience Captive Portal issues. We know this isn't the situation for all our customers, so are continuing to iterate, including plans down the road to make this a dashboard-optional configuration.
We do not recommend creating custom config files. Our recommendation is waiting for the MDM solution to release with agent version 2.3.9.
Follow the instructions under Optional: change the timeout to change the time to whatever value you see fit.
As for why this feature is named Travel Wi-Fi mode: Most Captive Portals work without this extra step, including at cafes. Our research shows the conflict that prevents a Captive Portal from appearing is primarily contained to Airports and Airlines—hence the name.
And thanks for all the copy edits—always appreciate customer's help with making our content better! Our engineers checked the commands, and though they are legacy, do still work, so we'll work on getting them up to date across our documentation in the new year.
I needed to manually make a config because I have executives traveling for the holidays who have been complaining that their wi-fi is ‘breaking’ (mostly on planes as you stated). So I had no choice but let them at least try these new settings now (with my caveats). I won't roll this new setting out any wider to production, I'll wait for 2.3.9 per your suggestion. Thanks.
How would I have known that this feature will be baked-into version 2.3.9? I didn't see it mentioned anywhere. Did I miss something?
Minetta Gould, I'm also testing the “Travel Wi-Fi Mode” and I have a few questions. I guess the major question here is, “What exactly does this feature fix/address?" and “How can I test this functionality for my users?”. Is this for connections made through viasat?
In my testing I've tried to replicate the user's experience by forgetting my known networks and then activating “Travel Wi-Fi Mode” (TWM), before connecting. It appears as though a network connection has to be present before the DNSFilter client will activate the TWM. So, are user's supposed to attempt the connection to the network before activating the TWM? It doesn't seem to make sense that they'd be connected to a network before activating it, if they are at an airport or traveling.
Thanks so much to both of you for the thoughtful questions and for sharing how you’re testing this feature!
Ward: Travel Wi-Fi Mode is designed to help macOS devices successfully load Captive Portals on networks like airplanes, hotels, and airports, while still keeping DNS protection in place. A network connection does need to exist first so the portal can intercept traffic and present the login screen. If that doesn’t happen automatically, enabling Travel Wi-Fi Mode helps prompt it. This was tested with providers like Viasat. You’ll know it’s active when Travel Wi-Fi Mode appears in the agent details, like in the screenshots above.
Daniel: Really glad the manual config helped your traveling execs! And totally fair question on visibility. We wouldn’t expect you to know which version a feature will land in; mentioning 2.3.9 was just meant to share where things are headed, not an assumption you already had that context—simply letting you know great minds think alike, and we're already working on the ideas you suggested.
Appreciate both of you taking the time to test and share feedback—let us know if anything else comes up!
Minetta Gould When Wi-Fi Travel Mode is enabled (i.e.; actively counting down…), should I see the DNSFilter DNS Proxy system extension ("Transparent Proxy" AKA com.dnsfilter.agent.macos.DNSProxy) turn red in the System Settings > Network > Filters UI to reflect that it is temporarily disabled? Asking because I dont see it change to a disabled or inactive state on my test Macs (Sequoia and Tahoe).
Any reason why the countdown timer doesn't appear on the menu bar itself rather than requiring users to click it to see the time remaining?
Can you articulate the differences between an airline captive portal like Viasat and a “regular” captive portal from, say, Cisco, Fortinet, Meraki etc? Im trying to understand why airlines and planes should be treated different than any other captive portal (sorry - I dont fly too often, but I asked my CIO to put me on a plane to Hawaii for ‘testing’ ASAP)
Can you confirm this is the best practice for using the new Travel Wi-Fi Mode:
-Turn off Wi-fi.
-Activate Travel Wi-fi Mode from the DNSFilter menu. Timer begins with 60 seconds. (DNSFilter security filter is deactivated in the background presumably…?)
-Turn on Wi-fi, and select the target SSID.
-The Travel Wi-fi Mode ends after 60 secs (which should be enough time to connect). DNSFilter security filter activates.
Im at a cafe near my office with Ubiquity Captive Portal. Not an airline but this is as best as I can do for base level testing I have 2 Macs.
Mac #1 Tahoe 26.2 Apple M3
I forgot to enable WTM before authenticating to the captive portal, but when I opened the menu bar app, it was already in WTM automatically. Is that expected behavior? I didn't need to manually activate it. From there I was able to route to the internet make a VPN tunnel to my office, get a Kerberos TGT ticket from my domain/realm, etc.
Mac #2 Sequoia 15.7.2 Apple M3
I was able to connect to the captive portal, but DNSFilter got stuck with the X (disabled symbol) and there was no WTM timer. It's stuck and I couldn't start a VPN tunnel or route to the public internet. After 10 minutes of fighting it, I gave up. I tried to kill every process 1 by 1. DNSFilter 2.3.8 is in bad shape I had to reboot to fix it. Overall this was a weird experience but Im on the WLAN.
If an IT admin of 20+ years cant figure out how this works, there's no way my users (and executives) will be able to understand the nuances and “magic” of DNSFilter.
Whats the ETA on 2.3.9?
Daniel Stranathan Happy to share a bit more detail! We totally get the Hawaii flight testing requests—our engineers wish you luck where their similar requests were denied 🌴 😅 🌴
When Travel Wi-Fi Mode is active, the agent is not disabled, so you shouldn’t expect the DNSFilter DNS Proxy to turn red or appear inactive in network settings. That’s expected behavior. Instead, allowed traffic is sent to both the network’s DHCP DNS server and DNSFilter so captive portals can load while policies continue to apply. Blocked domains stay blocked, even during Travel Wi-Fi Mode.
Airline networks like Viasat behave differently from most hotel or coffee shop portals. They use a tightly controlled, walled-garden DNS model that blocks all external DNS until authentication, which is why conflicts show up there more often than on platforms like Cisco, Meraki, or Fortinet.
Our primary focus is expanding native captive portal handling—including for highly restrictive airline networks—so the agent “just works” without extra steps. Where native handling isn’t possible, Travel Wi-Fi Mode will continue to evolve to make protection easier to enable and manage, so if you have ideas feel free to submit a feature request!
As for best practice: users generally shouldn’t need to toggle Wi-Fi off/on. Enabling Travel Wi-Fi Mode and attempting to browse to any site should prompt the captive portal. Every network is a little different, though, so toggling Wi-Fi can still be a safe troubleshooting step if needed.
Thanks for the info. This convo is helpful. To make sure we are on the same page, can you give me an outline on exactly what a non-technical user should do once they sit down on an airplane and attempt to connect to a network? I want to have a how-to doc ready for executives for 2.3.8 (at least as a temp procedure until DNSFilter matures). Id really appreciate having an official process “from the horse's mouth”.
Do you have an approximate ETA on Mac version 2.3.9? Jan 2026? later in Q1 2026?
What is the expected cadence for auto-updates from the DNSFilter admin console? We have ~400+ Macs on version 2.2.0 and only ~40 have 2.3.8 thus far from auto-update. Looking back over the last year, we never saw any other updates get applied (like 2.3.3 from October 2025 for example). What logic/criteria do you use when deploying auto-updates?
While we are on the topic of DNSFilter menu bar, is there a way to optionally hide the menu bar icon via our admin console? When we evaluated the product in 2024 (1.8.6) our rep mentioned that we can hide the System Tray icon on Windows, and the ability to do this on macOS was “coming in 2025”. Any info on this? We aren't sure we would actually want to do this (especially with the new Wi-Fi Travel Mode), but it's nice to have options.
Daniel Stranathan The test experience you described is not as expected in either scenario, so I started a Support Ticket for the team to take a look at the issue. They'll need diagnostic logs from both agents if you can provide them, and the daemon files would also be helpful.
For the end user to use Travel Wi-Fi mode (after the function is enabled following the instructions in this article):
If the captive portal does not propagate, toggle off and back on Wi-Fi to retry the connection.
Our regular auto-update release cadence completes in 4 weeks, but over 2025 we slowed or paused this process due to the new System Extension agent, and sometimes we have a new feature or bug fix that prevents a version from reaching 100%. v2.3.8 is on a short pause just because most our company is on a holiday break until the new year, but will resume once we're back in office. Likewise, 2.3.9 is in QE testing, and thus far we feel good that it will release in January!
As for hiding the menu icon, there's an open feature request you can vote for, which will then notify you of any updates on its status. We don't have it prioritized at this time—our focus is on stability—but the request is on our radar!
Minetta Gould Happy new year! Hope you are doing well. I'm off holiday break and back at it!
I haven't heard back from my executives regarding their experience with DNSFilter 2.3.8 and Travel Wi-Fi Mode yet.
Question: It appears that 2.3.8 was released December 10 2025 (nearly 1 month ago). But only ~70 of my 400+ Macs have version 2.3.8 - the rest are still on 2.2.0. We are using DNSFilter's best practices by using our cloud admin console perform the auto-updating. But that number seems low. What are your thoughts on auto-updates? Shouldn't more of our Macs have 2.3.8 by now?
Daniel Stranathan Happy new year to you as well!
We paused the auto-update release for our company-wide holiday break, so you should see it resume over the next few days—likely reaching 100% of devices with auto-updates enabled in a few weeks. The auto-updates apply at random, so it's normal for a single Organization to see some, but not all, updates at once.
Not hearing anything is often a good sign, so hope everything is working well for your exec!
The feedback was not great. I think they were able to connect to their flight's Viasat which is good (no reported issues…yet) But the obvious downside is that nobody wants to invoke TWM manually. Users were confused at what I was asking them to do when I created a brief instruction doc.
Glad to see auto-updates are active again post-holidays
Daniel Stranathan Totally understand the feedback—and thanks for sharing it. Our primary focus is expanding native captive portal handling so the agent works without extra manual steps. Travel Wi-Fi Mode exists to bridge the gap for networks that don’t trigger captive portals naturally today, and we’ll continue iterating on it as needed.
We really appreciate the feedback, ideas, and testing from you and others—it helps us prioritize the work that delivers the most value.
Is there a way to opt-in to your Mac agent beta releases? Anyway to see 2.3.9 early? Sorry to keep bugging you. Im enjoying this convo about your product and Id like to dive into it more as it matures.
Sure thing, Daniel Stranathan ! If you’d like early access to 2.3.9, just reply to your open ticket and let Tate know—he can share the file with you. Please note this is an alpha build while our Quality team finishes testing. Nothing major has been flagged so far, but it isn’t fully finalized yet.
The build isn’t hosted publicly yet either, so as long as you’re able to host the file in your MDM, you should be able to test deployment. Tate can help with any setup questions along the way.
If you’re interested, we can also add you to our pilot program list. We reach out to that group when we’re looking for customer feedback on larger releases—we could add you for the macOS agent, or other areas like reporting and integrations as well!
Great info thanks! I'll likely wait to reach a beta stage (not alpha). But yes we certainly want to be able to work closer with you - especially on macOS.
Great, Daniel Stranathan—added you to the contact list for the macOS agent for any upcoming pilots!
Tate sent me the alpha pkg. I may toss it on a test box for “fun”…
Much appreciate being added to the pilot program.
I found some colleagues on the MacAdmins Slack that may participate in this discussion. If you aren't a member I highly suggest it. There are lots of orgs that have community representation here like SentinalOne, Apple, Cisco, Microsoft, Jamf, Rapid7 etc. Its a thriving source for news, updates, integration, support etc.
https://www.macadmins.org
Have fun with the Alpha, and thanks for the community suggestion! Passed along to the Support Team and our Engineers—awesome resource!
I have been watching my Mac fleet's DNSFilter version history. We still only have ~70 Macs out of 400+ running DNSFilter 2.3.8 (released December 10 2025). The rest are on 2.2.0 still. Is there a way for a customer to get better insight into the inner workings of how your auto-update logic works? I dont see any controls at all other than a global off/off toggle.
Hey Daniel! The easiest thing to check is the Released Version KB article. If a release isn’t set to 100% auto-update, it’s normal to see parts of your fleet still running an older agent. If the release date is more than a week old, that usually means the rollout is currently on hold.
You can also take full control of the timing by pushing the updated agent via your MDM. That way, you decide exactly when the update happens and don’t have to rely on auto-update cadences.
Hope that helps!
Please sign in to leave a comment.