Forum Discussion

antec42's avatar
antec42
Icon for Altostratus rankAltostratus
May 19, 2015

DNS issue with VPN connection from OSX

Hi all,

 

I have an issue with the DNS resolvers when I'm connecting with a Mac computer. Problem is the local DNS server already configured on the computer still remains as the "resolver 1", i.e. first resolver to query, even though it should be overwritten with the new resolvers provided from the big-ip. At the very least the "local DNS" should be placed after the new ones. The problem with the current situation is that sometimes the local DNS server will respond with a "REFUSED" message after the client is connected to the VPN, the reason for this I'm not sure but is something out of our hands because the DNS server might be random X wifi somewhere...

 

Is there any way I can alter how the DNS servers will be handled? I have tried to play around with the options "Enforce DNS search order" and "Allow local DNS" but both these settings doesn't change how the DNS config on the client look like (at least not on the Mac computer). Also there's no difference between portal access (web based) or Network access (from the Edge client).

 

Best Regards, Marcus

 

4 Replies

  • Hi Marcus,

    Can you show the output of the following commands?

    $ scutil --dns
    
    $ scutil -r google.com
    

    Also is there anything that stands out in the svpn.log or edge.log in the ~/Library/Logs/F5Networks/ directory?

    Seth

  • Hi MaxQ, it sure looks similar to this problem. I will try to re-order the different interfaces in OSX to make the VPN adapter be the top one in the list, this might influence this?

     

    Seth, I will have the customer get the output from those commands. I will also have a look in the files you specified.

     

    Thanks, Marcus

     

  • Hi everyone,

     

    For your info, the solution to these problems were to avoid split tunneling completely. And to avoid connectivity problems with VS'es through the VPN tunnel we had to seperate the VPN Connections to another route domain.

     

    Just wanted to give an update to what we did to solve this. But this really feels like a work around...

     

    Regards, Marcus