Hi there,

major problem and it is getting frustrating. I have the cisco vpn
client version 3.6.3.A and can connect to the VPN server, but cannot
access the network. The problem is that when I open stats I see :

0 encrypted 0 decrypted
0 bytes in 0 bytes out
200 pack discarded 222 packets bypassed

I have one secured connection (to a subnet), but normally, on another
network I get three subnets that are secured. Then it works

All my packets are beeing discarde of bypassed. I am on a B class
network, e.g. 10.190.x.x and am trying to connect to a single IP
address using UDP/NAT/Firewall. I altered the local firewall as below:

Source         Destination    Prot.   Port
10.190.0.0     10.10.10.1     UDP     62515
10.190.0.0     10.10.10.1     UDP     4500
10.190.0.0     10.10.10.1     TCP     10000

Does anyone know how to help? Am I missing port numbers or a protocol
I have to use instead?

In article <929ebdf1.0412030917.27cd1db@posting.google.com>,
seansan <sean108@reeve.nl> wrote:
:major problem and it is getting frustrating. I have the cisco vpn
:client version 3.6.3.A and can connect to the VPN server, but cannot
:access the network.

:I am on a B class network, e.g. 10.190.x.x

IPs starting with 10 are never class B networks: they are either
class A networks, or they are using CIDR in which the concept of class
does not exist.

You may be configuring a netmask of 255.255.0.0 on a 10 series address,
but that doesn't make it a class B network: if you are going to
talk about class at all, it makes it a subnetted class A network.

It may look like I'm being pedantic here, but when you are talking
about Cisco VPN equipment, it can be important to know the difference between
a Class B and a subnetted class A. The reason it can make a difference
is that when you are using EzVPN (which would usually be the case for
the Cisco VPN client), the EzVPN server might not send the client a
netmask, unless the server is configured to do so and the client is a
new enough version to receive the netmask. For example, the Cisco PIX
version of the EzVPN server code only gained the ability to send masks
along as of the latest software release, PIX 6.3(4), and for backwards
compatability the PIX will not send the mask unless you have specifically
configured a netmask as part of the vpdngroup configuration.

If your client system is expecting a netmask that is really a subnet
of a Class, and the client needs that netmask to be in force in order
to reach other IPs that are outside the range of the desired netmask
but inside the range of the overall Class, then you can run into problems,
especially problems reaching local networks [if split tunnelling has
been enabled at the VPN server.]
-- 
   Warhol's Law: every Usenet user is entitled to his or her very own
   fifteen minutes of flame                  -- The Squoire