Currently Being ModeratedNov 6, 2012 4:10 AM (in response to pietia336)
In my case the 6.0.1 update resolved the issue initially described in the original post:
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.
Currently Being ModeratedNov 12, 2012 5:37 PM (in response to pietia336)
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.
Currently Being ModeratedNov 13, 2012 5:22 AM (in response to kmaybe)
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.
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!
Currently Being ModeratedDec 18, 2012 1:29 AM (in response to pietia336)
No solution ??? ....... Please help me
Currently Being ModeratedDec 18, 2012 4:50 AM (in response to MDS78)
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.
Currently Being ModeratedJan 4, 2013 9:56 AM (in response to iam2012)
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.
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.
Currently Being ModeratedJan 27, 2013 10:21 AM (in response to pietia336)
please fix this, are u there?
I missed Steve Jobs so much!
Currently Being ModeratedJan 28, 2013 11:53 AM (in response to pietia336)
It looks like it might have been fixed in 6.1
Currently Being ModeratedJan 28, 2013 2:03 PM (in response to pietia336)
Initial testing shows positive results here as well, using Juniper Pulse app / Verizon service
Currently Being ModeratedJan 28, 2013 4:13 PM (in response to rmaudsley)
Fully tested here on an iPad 4th gen., and an iPhone 5. .local now resolves on AT&T LTE here in Atlanta and Florida.
Currently Being ModeratedJan 29, 2013 5:34 AM (in response to pietia336)
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.
Currently Being ModeratedJan 29, 2013 5:46 AM (in response to CodePro)
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.
Currently Being ModeratedJan 29, 2013 5:53 AM (in response to CodePro)
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)!
Currently Being ModeratedJan 29, 2013 6:14 AM (in response to MakMak1980)
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.
Currently Being ModeratedJan 29, 2013 6:27 AM (in response to pietia336)
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!