Scot L. Harris wrote:

On Sat, 2004-07-24 at 18:09, G-Love wrote:

...

All -

After much consternation, I was successfully able to install the Cisco 3000 series VPN client on my FC2 box, with kernel 2.6.7 I had some problems connecting at first, but that was fixed with a simple addition to my iptables config file. Here's my current problem (and seemingly my last hurdle to getting this to work as I need):

I'm connecting to the VPN server using NAT, as I have a firewall running on my machine. I can get to all the internal websites with no problem; however, when I try to ssh to a machine on the internal network, it simply hangs. When I try to ping the same machine, it times out with the following message:

PING: unknown host <hostname.myco.com>

Then I did a little experiement. I got the IP address of the machine that I was attempting to connect to, re-established my VPN connection, then attempted to ssh to the machine using the IP address. Lo and behold, it worked, and I was able to verify that I was, in fact, connected to the machine thru my VPN connection (the 3000 series VPN clients/concentrators allow for split tunnelling).

SO...it seems as thought name resolution does not work with the VPN connection enabled. In fact, I can't see (ssh, ping,...) ANY machines while the VPN connection is active. I tried pinging cnn.com, and that resulted in the same "unknown host..." message. I'm a bit of a newbie to firewall configurations, etc, so any help on getting this to work would be appreciated. I guess using the IP address is an OK workaround for now, but I'd rather not rely on this method.

Thanks.

       -greg

This is related to another thread here in the last day. I suspect that the VPN client you are using does not have a DNS sever configured or does not have the correct DNS server configured.

You validated that you do have network connectivity using the IP addresses. When you establish the VPN connection using the Cisco client software you should end up with some kind of security policy. (I am assuming this software is similar to Checkpoints Secure Remote). As part of that policy is DNS information. The DNS server it points to will resolve all your DNS queries.

If for the DNS server is incorrect or unreachable then the query will fail.

Are you able to identify a file on your system that contains the policy? I don't remember if Secure Remote encrypted the policy file or not. (I always looked at the file on the firewall side)

Even in split tunnel mode with the Checkpoint software all DNS queries went to the one defined in the security policy. It did this since there was no way to differentiate if the request was for a name on the other end of the VPN or not.

From the Cisco 2000 VPN Concentrator Configuration page:

"In this section, you are presented with the information to configure the features described in this document. Split DNS parameters are configured under the group parameters on the Cisco VPN 3000 Concentrator. Therefore, no configuration on the client is necessary."

So all of the DNS information in configured on the concentrator side - no client side configuration necessary. I never had this problem when we used the older, 5000 series concentrators. Thinking about it, I believe that there was some DNS configuration necessary on the client side when first installing the client SW. Maybe I'll ask around if anyone else has seen this behavior, since an improper configuration on the concentrator side means others would see this behavior as well.

-greg

his would also apply to configuration of the split tunnel setup.

There's a few bugs related to split tunneling, split dns and generic tunneling.. They seem related to the kernel version, glibc version and vpn client version in use but have started rather recently (say within the last 6 months or so). My hunch is that the interceptor does something weird. Anyway, with _linux_ clients I got the best result using split tunneling and pushing dns servers that are routed outside the vpn tunnel to the clients. It's mentioned off hand in the release notes under the section "DNS Server on Private Network with Split DNS Causes Problems" (CSCee66180).

Another is CSCea75956 which occurs with non-Win32 vpn clients only. I first thought that was what I was experiencing but further investigation and packet dumping at all ends proved me wrong :)

The vpn client works great under win xp in vmware (as expected) and without any problems with iptables, too. One needs to permit 500/udp and 4500/udp (nat/pat passthrough) or 10000/tcp (or whatever other tcp port you or your administrator might have configured in the concentrator). Good ports to use are 25, 143, 80, 443, 3128, 8080 .. there's almost always one or two of those open at various locations. O:-)

// kaj