- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hey guys,
I know the percentage of people using Mac machines in their corporate environment is not that large, but hope to confirm if someone may had encountered the same issue. We had a case with TAC on this and it appears that for users who have monterey OS, when they connect with VPN client, either regular or harmony endpoint, they can access anything by IP address, but not fqdn (so say server resolved to abcd and IP is 10.11.12.13, they can access it by IP, but NOT fqdn).
If they do this on Catalina OS, then works fine. To me, that clearly indicates OS problem, but could not find an official statement on CP website about this. If anyone had similar issue, can you please let me know.
Thanks as always!
Just to update, we found a solution...appears it was, as we thought, version of VPN client that was causing the issue...so once customer used E86.30.1214, all worked fine. This is of course with Identity agent connected, since we had to use that for mac machines.
Pretty sure that isn’t a universal problem since I am on Monterey now and not having this issue.
Hey @PhoneBoy ...thanks for feedback. So do you think this could be some fw setting issue or something missing on mac itself? WE added dns suffix on gateway vpn optional parameters as CPiOSDefaultDNS besides actual dns suffix, but that did not change the behavior.
Any idea? Are you able to access internal resources when connected via vpn by fqdn?
Same, been using EndPoint Security in Monterey for 7+ Months and not having big issues. Seems far more stable than in Windows. The only issue is sometimes after sleeping with the VPN open, upon opening the lid, I have the local DNSes and not the VPN provided DNSes.
If i had to guess, seems more a case of DNS setup/lack of routing, or issues between full and split VPN.
what dns servers/dns suffixes are you using in dashboard/web ui/mac settings? We tried so many options and no luck. Its a split vpn by the way. Funny thing is say if I try from my home macbook air to access AD servers by name, it fails, but works for another server. I believe customer has users that have random issues like that too. I dont know if its related to IA agent, but seems even when iA agent is connected, its not any better.
I'm accessing internal resources via FQDN.
I assume the issue is a configuration issue somewhere (not able to reach the configured DNS server).
I dont get it...when Im vpn-ed in, I can ping both dns servers fine, no issues. So, not sure if its gateway related or something else.
Have you done a tcpdump from the gateway when the Mac is trying to do a DNS lookup?
Possible the packets are getting dropped somewhere, but that seems a logical place to start looking.
will do...one question though. Do you think that the fact customer used split tunnel could be an issue? I dont see how, since all this works fine on windows, just NOT mac
If the customer is subverting/deleting the default VPN gateway to have a split tunnel, specific routes for the DNS servers networks might have to be created (and who knows what else more)
Im sure if routing was the issue, then this would never work on windows machines either, agree?
Split tunnel in use here, so doubt that.
Full and split here. The point if not being or not possible, is people creating the needed routes/knowing what they are doing.
But it seems odd Windows doing it and Mac not indeed if both are doing split routing.
Beware DoH in Windows 10/11/2022.
Does the client have Private Relay enabled? That sends all DNS traffic via Apple's relay system to public DNS servers. I could definitely see it causing weird behavior like this for names which can only be resolved inside a company's network.
I read online about it, let me test myself from personal macbook and will update! tx @Bob_Zimmerman
I dont think that is it sadly...I dont even have that on and its same issue.
Did tcpdump and fw monitor, exact SAME output when I test windows or mac. I really dont understand this...makes no logical sense to me.
What do you get if you dig a fully-qualified internal name without specifying a DNS server? That is, 'dig myCoolHost.internalDomain.local'?
What about if you manually specify the internal DNS server in the dig? That is, 'dig @10.20.30.40 myCoolHost.internalDomain.local'?
If you can, please try on both macOS 12 and an earlier version where access by name works.
If I do nslookup on macbook, comes back fine, resolves to right IP/name, so thats not the problem. I asked engineer in TAC I was working with to consult with endpoint team about this, since its 100% clear now it could be version of the client used, as customer told me that some older versions work, but not newer ones. Apple senior adviser is also absolutely right,if access by fqdn works when off VPN (which it does), then its not Monterey OS issue and I agree with him.
When you use nslookup, does it show it's asking the internal DNS server which is only accessible over the VPN?
If that works without specifying a server manually, that means the VPN client is properly telling the system about the new DNS server. That in turn suggests it may be an issue with the client application. Some client software (in particular, Chrome) does its own DNS lookups without involving the system's resolver.
Its not...internal dns server is not accessible only via vpn. I will take it further with TAC. Thanks guys for all your inputs.
Just to update quickly on this...guy in TAC I spoke to yesterday said that supposedly R&D has some sort of custom vpn client for mac that would solve this issue. I asked them to send it, but nothing as of yet...
Just to update, we found a solution...appears it was, as we thought, version of VPN client that was causing the issue...so once customer used E86.30.1214, all worked fine. This is of course with Identity agent connected, since we had to use that for mac machines.
I am using E88 and still losing VPN DNS servers after the machine going to screen saver while connected to VPN.
I am using now a workaround where I define private DNS servers for our internal domains at /etc/resolver and it works like a charm.
ruiribeiro@Ruis-MBP-2 resolver % cat xx.pxlocal
domain xx.pxlocal
nameserver 10.1.1.1
nameserver 10.1.1.2
search_order 1
timeout 10
Hey,
I see this post was from while back, apologies, did not deal with this in some time. You are saying even with newest EPS client you have the issue? Is it standalone VPN client or EDR?
Andy
@the_rock wrote:Hey,
You are saying even with newest EPS client you have the issue? Is it standalone VPN client or EDR?
Andy
It is a standalone VPN client.
Might be worth TAC case then.
Did you try E88.30? https://support.checkpoint.com/results/sk/sk182110
E88.30 seems to not work for me for now, had to go back to E88.00.
@PhoneBoy wrote:Did you try E88.30? https://support.checkpoint.com/results/sk/sk182110
Same behavior on E88.30?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |
Tue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY