Cisco VPN / Firewall configuration

[G-Love]

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

[Scot L. Harris]

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.

-- 
Scot L. Harris
webid(a)cfl.rr.com

In vino veritas.
	[In wine there is truth.]
		-- Pliny

[G-Love]

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

[Scot L. Harris]

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

>   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 
Ah!  Now that sounds better.  From the other discussion I was beginning
to think that Cisco had a big hole in their VPN software.  This sounds
like they use a similar scheme, the policy is set on the concentrator
and apparently transfered to the client.  This would also apply to
configuration of the split tunnel setup. 

-- 
Scot L. Harris
webid(a)cfl.rr.com

I used to be an agnostic, but now I'm not so sure.

[Kaj J.Niemi]

>  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

[Kenneth Porter]

--On Saturday, July 24, 2004 3:56 PM -0700 G-Love <greg(a)20percent.org&gt; 
wrote:

>  So all of the DNS information in configured on the concentrator side
> - no
>  client side configuration necessary. 
The VPN server pushes a set of DNS servers and your /etc/resolv.conf gets 
replaced with one pointing at those servers. When the connection shuts 
down, your saved file gets restored.

There's some additional interception going on though, as I find even if I 
block the overwriting of resolv.conf that some packets targeted to the 
Internet still get lost.