XPost: comp.dcom.sys.cisco, comp.security.firewalls   
   From: SoddOff@Baldric.co.uk   
      
   please verify our route-statements/protocols, and if there is any VACLs in   
   place, ACL on routers etc.   
   The IP pool used for VPN must be routed and allowed.   
      
   GL   
      
   HTH   
      
   MArtin   
      
   "Jon Doe"  skrev i en meddelelse   
   news:ZPOdnS48bMf5fYHeRVn-tg@comcast.com...   
   >   
   > "Martin Bilgrav"  wrote in message   
   > news:Xb4Te.66830$Fe7.224543@news000.worldonline.dk...   
   > > Are you absolutly certain, that this is not a simple route issue ?   
   > >   
   > > meaning that the 10nw knows the route back to the Cisco VPN Clients ...   
   > > (try from a server to ping the clients)   
   > > and that you do not have any personal firewall services installed on   
   > > servers/clients   
   >   
   > That's really what I'm trying to figure out. Also, as I mentioned before,   
   > this is not a case in which the VPN clients can't get *anywhere* on the   
   > network. For instance, when I connect from home to VPN, I'm able to get to   
   > most (I'll give a rough estimate of 85%) of whatever I need to get access   
   > to. By the way, we're very heavy into VLANs here... in case that might   
   have   
   > anything to do with it.   
   >   
   > So, it's only a few VLANs here and there that I cannot get access to. The   
   > main reason I got word of this problem was that while connected to this   
   new   
   > VPN, we can no longer get access to a few of our routers or switches... so   
   > we can't administer them while at home (which we really need to be able to   
   > do).   
   >   
   > I should also mention here that the whole reason for the cisco vpn is that   
   > we're trying to get rid of the microsoft pptp vpn currently in place. When   
   > connected to the microsoft vpn, I have access to *everything*.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)