I flushed the dns cache, I verified the /etc/nf file had the two DNS servers that the NetExtender had placed in there when I connected, and I verified with telnet that a firewall was not blocking DNS to the DNS servers. I verified that I could telnet to port 53 across the tunnel, a NSlookup test proved that I the records I was looking for did exist. I could resolve DNS on my local subnet, and on the internet, but I was unable to resolve anything on the internal DNS servers at the main office that I was connecting to. Now on version 5.0.680 I was unable to resolve DNS on the other end of the VPN tunnel when connected. I thought my problems were over until I re-connected to test that the VPN was still working. I updated the first client and Success! I was able to connect, disconnect, and then continue to resolve DNS. I updated one of the client Macs to 10.6.5, but still no luck.Ī call to SonicWall ended up with them giving me a new version of the NetExtender software for the Mac, version 5.0.680. I started with a review of the release notes of the SonicWall firmware, which mention a problem with Mac OS prior to version 10.6.5 and NetExtender. I had already updated the endpoint device, a SRA 1200, and the NetExtender was whatever version came with SRA 1200 firmware SonicOS SSL-VPN 4.0.0.3-20sv, which was the most recent firmware available at the time of writing. Once the connection was ended, boom, no DNS resolution.
The problem didn’t appear until after the software was connected to a endpoint, and then disconnected. The client computers were able to resolve DNS properly prior to installation. This is a standard trick VPN software uses to prioritise its routes over default: it adds two routes which together cover all IP addresses, but each of them is more specific than default, so they win.Over the last few days I’ve been running into a problem with Mac OS 10.6 clients and the SonicWall SSL VPN client, NetExtender. This route covers the bottom half of the address space and therefore I would expect to also find: 128.0/1 10.10.99.100 UGSc 0 0 ppp0 Now, this route from your output makes me think that in your case specificity also plays its role: Destination Gateway Flags Refs Use Netif Expire You can use networksetup -listnetworkserviceorder to view this order and networksetup -ordernetworkservices to change it. Instead of assigning metrics to individual routes, macOS assigns priorities to interfaces. On Linux (and, I think, on Windows) priority is determined by metric, but it is not the case on macOS as you correctly pointed out. Choose the one with the highest priority.the ones with the longest matching prefix).
Most systems follows these rules when choosing which route to use:
0 kommentar(er)
