MacOS 14 beta: DNS issue when enable VPN

Question

lesterhan OP

Created Jul ’23

Replies 6

Boosts 0

Views 1.1k

Participants 2

Our application (VPN solution) works well on macOS 13 and this issue only occurred on macOS 14 beta. This issue is:

If we connect the cable to a Mac mini’s ethernet port, and enable the VPN in our application, then the Tunnel is enabled under System Settings->Network->VPN & Filter, after that, the DNS stops resolving.
If we use a “USB-C LAN” adapter to connect the cable to Mac mini’s USB-C port, this issue disappears. Only enable Wi-Fi can also avoid this issue.

The confusion is what’s the difference between connect to Ethernet directly and use an adapter?

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’23

Is your app configuring the built-in VPN transports, that is, using Personal VPN? Or do you have a custom VPN transport, that is, a Network Extension packet tunnel provider?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

lesterhan OP

Aug ’23

Hi eskimo, we use packet tunnel provider.

0

Answer 3

DTS Engineer OP

Apple

Aug ’23

Does the DNS fail because it’s misconfigured? Or because it’s unable to send exchange packets with the DNS server?

On macOS you can get the DNS configuration using:

% scutil --dns

The idea would be to compare the configuration in your working and non-working cases.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

lesterhan OP

Aug ’23

I think DNS is well configured.

On worked macOS 13.2.1, the interface details and DNS settings like below: ifconfig en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
	ether 14:9d:99:7a:63:8a 
	inet6 fe80::f9:3d3a:cf03:a052%en0 prefixlen 64 secured scopeid 0x8 
	inet 10.12.25.199 netmask 0xfffffe00 broadcast 10.12.25.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex>)
	status: active

scutil --dns

resolver #1
  search domain[0] : dhcp.xxxx.net
  nameserver[0] : 192.19.189.30
  if_index : 8 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

On macOS 14.0 beta 5, the interface and DNS have same settings as 13.2.1, but after tunnel provider connected, nslookup command always timeout. ifconfig en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
	ether 14:98:77:2e:c8:89
	inet6 fe80::1485:6060:796d:4828%en0 prefixlen 64 secured scopeid 0x9 
	inet 10.12.25.44 netmask 0xfffffe00 broadcast 10.12.25.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex>)
	status: active

scutil --dns. (same output before and after enable the tunnel provider)

resolver #1
  search domain[0] : dhcp.xxxx.net
  nameserver[0] : 192.19.189.30
  if_index : 9 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

Also on same machine(macOS 14.0 beta 5), if use a USB adapter, then DNS works well. The adapter interface details:

en7: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=6464<VLAN_MTU,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
	ether c4:41:1e:75:91:16
	inet6 fe80::406:dbc8:b9d0:3bd%en7 prefixlen 64 secured scopeid 0xe 
	inet 10.12.25.68 netmask 0xfffffe00 broadcast 10.12.25.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex>)
	status: active

resolver #1
  search domain[0] : dhcp.xxxx.net
  nameserver[0] : 192.19.189.30
  if_index : 14 (en7)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

0

Answer 5

DTS Engineer OP

Apple

Aug ’23

Thanks for all that info.

So your tunnel provider claims a route that captures the DNS traffic to 192.19.189.30?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 6

lesterhan OP

Aug ’23

DNS requests will not go though the tunnel provider. We have a proxy provider to check the domain name to determine whether the corresponding traffic goes through the tunnel.

0