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
23 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
the_rock
Legend
Legend

Hey guys,

Sorry to update this threat few months later, but in case anyone else has this problem, we had a case with TAC escalations team and once they discussed the issue with R&D, this was their response (customer removed 8.8.8.8 dns server from the list (this is under gateway object in dashboard -> vpn clients -> office mode -> optional parameters). Customer had 3 servers there, 2 internal and then secondary backup as 8.8.8.8

R&D statement (which makes total sense). Also, just as a side note, you can leave google dns in web UI in dns list (hosts and dns)

**************************************

Here is RnD's statement:

You shouldn't mix internal and external DNS servers, it's not a backup\fallback server, the OS (any OS) treats them as equal and you can't rely on your internal domains resolved through the 'right' server.You also don't have this server in the encryption domain so no reason for you to see these 8.8.8.8 DNS requests on your gateway. For another external fallback option the OS already has the DNS server configured on the physical interface so again, no point in having this one configured on the tunnel.In iOS 16 Apple made some changes to prefer encrypted DNS when available and as 8.8.8.8 supports DoH/DoT it prefers to resolve addresses using this server.In addition, in what clearly seems like an iOS bug, even if you have this server in the encryption domain they contact this DoH-supporting DNS server outside the VPN tunnel (it is encrypted DNS but still, it means internal resources will fail to resolve).TL:DR

Adding 8.8.8.8 never actually did anything for you and in iOS 16 this just breaks things so it is simply recommended to remove it.

*******************************************************

 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events