Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
the_rock
Legend
Legend
Jump to solution

VPN / Mac Monterey OS access by fqdn

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!

0 Kudos
1 Solution

Accepted Solutions
the_rock
Legend
Legend

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.

View solution in original post

0 Kudos
32 Replies
PhoneBoy
Admin
Admin

Pretty sure that isn’t a universal problem since I am on Monterey now and not having this issue.

0 Kudos
the_rock
Legend
Legend

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?

0 Kudos
RuiRibeiro
Contributor

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.

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
PhoneBoy
Admin
Admin

I'm accessing internal resources via FQDN.
I assume the issue is a configuration issue somewhere (not able to reach the configured DNS server). 

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
RuiRibeiro
Contributor

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)

0 Kudos
(1)
the_rock
Legend
Legend

Im sure if routing was the issue, then this would never work on windows machines either, agree?

0 Kudos
PhoneBoy
Admin
Admin

Split tunnel in use here, so doubt that.

RuiRibeiro
Contributor

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.

 

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
(1)
the_rock
Legend
Legend

I read online about it, let me test myself from personal macbook and will update! tx @Bob_Zimmerman 

0 Kudos
the_rock
Legend
Legend

I dont think that is it sadly...I dont even have that on and its same issue.

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
the_rock
Legend
Legend

Its not...internal dns server is not accessible only via vpn. I will take it further with TAC. Thanks guys for all your inputs.

0 Kudos
the_rock
Legend
Legend

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...

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
RuiRibeiro
Contributor

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
RuiRibeiro
Contributor

@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.

0 Kudos
the_rock
Legend
Legend

Might be worth TAC case then.

0 Kudos
PhoneBoy
Admin
Admin
0 Kudos
RuiRibeiro
Contributor

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 


 

0 Kudos
the_rock
Legend
Legend

Same behavior on E88.30?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events