Previous 1 2 3 4 5 Next 66 Replies Latest reply: Jan 19, 2015 2:44 PM by avafromzagreb Go to original post
  • pietia336 Level 1 Level 1

    Hi,

    In my case the 6.0.1 update resolved the issue initially described in the original post:

    pietia336 wrote:

     

    Hi!

    I have a PPTP VPN configured on SBS 2003 which is built-in by default in the OS.

    iPhone 4 (iOS 5.1.1), iPhone 4S and iPad 2 connected fine to this VPN. Also the URLs which where poinintg to addresses in local domain (e.g. service.contooso.local) were resolved properly.

    After updating to iOS 6 connection to VPN still establishes properly. Unfortunately all these devices cannot connect through Safari to local websites anymore when a URL in .local domain is specified (e.g. http://service.contooso.local) and that was working fine before the udpate. Safari returns the following message: "Safari cannot open this website. Server cannot be found." - this is a translation to English, so original message may slightly differ.

    When IP address is entered in Safari the connection is succesfuly established to the default website on SBS.

    It seems like after connecting to the VPN the DNS address used for resolving the names is not poining to the local DNS server (which is the same as webserver, VPN server, etc. as all the services are on SBS), but still to the ISP's DNS.

    Is that behavior normal in iOS 6 or is it a bug? As I have written before in iOS 5.1.1 this kind of behavior did not occur, and after connecting to VPN I could use http://service.contooso.local URL which was resolved properly to correct website in the intranet.

    I am looking forward for any hints.

    Best regards,

    Piotr

  • kmaybe Level 1 Level 1

    It looks like Apple posted an official response to this issue with KB Article http://support.apple.com/kb/TS3389.

     

    The above KB article indicates that the issue only occurs with sites that have .local as the DNS suffix which means it's not an issue with the VPN's DNS servers not getting applied to the connection and that any other internal hosts will resolve over the VPN tunnel as long as they have a DNS suffix other than .local.

     

    It seems rather odd that this behavior was not present in iOS 5 as many users on this thread have pointed out and Apple does not specifically indicate that there is anything different in iOS 5 and iOS 6 as far as this behavior is concerned--but they don't explicitly say it's been this way all along either.

  • CodePro Level 1 Level 1

    Nice job Apple.  After months of no help from "geniuses" ("I know the only change made to your network was updating to iOS6, but your VPN is mis-configured"), you post a KB article stating what everyone having the issue already knows as well as setting the expectation it won't be fixed because it will conflict with another Apple product.

     

    http://en.wikipedia.org/wiki/.local

     

    Seriously, the only thing that over-shadows Apple's ability to make fantastic hardware is their total incompetince at making software.

     

    I guess I am just a little peeved, thanks for letting me vent!

  • MDS78 Level 1 Level 1

    No solution ??? ....... Please help me

  • iam2012 Level 1 Level 1

    As far as I read somewhere here that it seems like it's not going to be fixed as somehow it interferes with other apple devises.

  • GunnerTAC Level 1 Level 1

    This is crazy. I have the same basic problem. I can't resolve my View Connection Server's FQDN when using VPN to connect to my network only when connecting via cellular connection. If I shut that off and turn on Wi-Fi the connection works perfectly. Why in the world would that make any difference? I don't buy the explanation that using .local conflicts with their Bonjour service because if that was a deliberate coding on their part the problem would exist whether using LTE or Wi-Fi to connect to the resource.

     

    Apple...FIX THIS!

     

    fwiw...I can change the View client to connect via IP address but that won't work at this point because View needs a trusted SSL connection. My connection won't be trusted since I'm not connecting via FQDN. I'm going to try and add the IP address as a second name to the certificate and see if that fixes things.

  • afsmoosavi Level 1 Level 1

    please fix this, are u there?

    I missed Steve Jobs so much!

  • lip1978 Level 1 Level 1

    It looks like it might have been fixed in 6.1

  • rmaudsley Level 1 Level 1

    Initial testing shows positive results here as well, using Juniper Pulse app / Verizon service

  • Tweekme Level 2 Level 2

    Fully tested here on an iPad 4th gen., and an iPhone 5. .local now resolves on AT&T LTE here in Atlanta and Florida.

     

    Nice!!

  • CodePro Level 1 Level 1

    No dice, I have a iPhone 4S running iOS 6.1 on Verizon.  Same as before, works when wifi connected, fails when 3G connected.  If you are testing this, make sure you disable wifi.

     

    Regardless, Apple has already posted a KB article indicating they will not fix this issue because it could potentially break their Bonjour service - which is a bogus statement as it works when wifi connected (unless they plan on breaking that with the next iOS release also?).

     

    If it works for you without wifi, congratulations, your IT team is part of the 1% that use Bonjour, or all of your servers have bad their DEFAULT name extensions switched out from .local - something that is barely reasonable for even small IT shops.

  • prochejr Level 1 Level 1

    Works for me, 6.1 fixed for me also.  Verizon iPhone 4S running iOS6.1 connecting with Palo Alto VPN.  Works on 3G only whcih is the fix, and still works on Wifi also.  Using the FQDN it can now resolve my internal serve rnames.

  • MakMak1980 Level 1 Level 1

    Hi there,

     

    for me it worked only when i used the actuall IP instead of the domain in order to get the emails and go to the company local site under VPN.

     

    so for example if your email setup is mail.yourcompany.local replace it with the actual IP e.g. 192.168...etc.

     

    if you dont know the IP you can ping under wifi with mobile or pc to the smtp.yourcompany.com (when you are under VPN) and then you will see the IP in terminal or CMD

     

    works for me after months of fraustration and temp solutions (using the free ping app)!

  • GunnerTAC2 Level 1 Level 1

    It fixed the issue for me too. Both Wi-Fi and 3G work with the other being off. Using IP for resolution is not an option when using SSL certs that use FQDN for certification.

  • CodePro Level 1 Level 1

    My mistake!  I had given up on this ever working based on the Apple KB article.   From all the recent posts claiming success, I re-checked my phone and saw I was actually running 6.0.1 - after a few scary moments of updating to 6.1 (a user NEVER wants to see ' Swipe to setup your phone' after updating their OS!), I shut off wifi and powered on the VPN.  Bingo it works!

     

    Ohh happy days!  Looks like we need to cancel our Android order!