On Fri, 2012-06-29 at 09:33 -0400, Darryl L. Pierce wrote: > On Wed, Jun 27, 2012 at 02:45:15PM -0700, Joe Zeff wrote: > > On 06/27/2012 02:34 PM, Lawrence Graves wrote: > > >192.168.1.84 israel.risingstar.local > > > > That's on a non-routable subnet. Considering that nslookup is a > > program to query Internet domain name servers, there's no way in the > > world that they'd know its address. > > Not necessarily. If you have a _local_ DNS server then it can resolve a > hostname on a non-routable IP block. (Realized I had inadvertently top-posted this reply - sorry! Need more coffee...) That's correct. Sorry for jumping in on this thread late. I not only know Lawrence personally, I also set up the network he is trying to access. I've just been out of town... The actual domain name of the internal network in this case is risingstar.local. He is trying to connect remotely first using the NetworkManager vpnc client to a VPN gateway (a Cisco ASA5505) that is configured to provide/refer DNS name resolution services for the internal domain as a part of the VPN configuration setup. The risingstar.local domain is added to the domain search list as a part of connecting to the VPN. What we are having trouble with is that gnome-rdp simply dies when trying to connect. Even when successful, the VPN connection appears to just hang after a few seconds. Conversely, I can run a Windows 7 virtual machine on the same physical computer that's having trouble with vpnc/gnome-rdp using VMware Workstation, with the virtual networking set to NAT mode, and connect to the VPN from that Windows VM via the Cisco VPN Client for Windows with no issues at all. Further, Windows Remote Desktop rdp client works without a hitch. Again, we can resolve host names both via the local host name (because risingstar.local is one of the VPN provided domain search names) and the FQDN. The issue is that the combination of using the vpnc client and gnome-rdp (or for that matter, any of the available rdp clients on F16/F17) either do not properly resolve the host name, or they connect briefly and then hang or crash outright. This *used* to *not* happen on our Fedora based systems. It *used* to work perfectly using the exact same vpnc VPN configuration profiles. I suspect that something got broken when a few vpnc and Gnome-rdp updates came along, and I also I suspect vpnc is the root cause here. So, I hope that helps a little more with the situation. We could use a hand on this from the vpnc and rdp folks on the list... Cheers, Chris -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
