cannot access shares over PPTP

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by cfinic, Apr 7, 2008.

  1. cfinic

    cfinic LI Guru Member

    Hi all.

    I have activated the PPTP server on my RV016 with a Static IP. I am able to connect to the VPN, but I am unable to access my file server (Running XP Home w/o firewall) when I try connecting to it by IP address. I've tried some network tools and the only thing I can see is myself and the router :confused::confused::confused:

  2. cfinic

    cfinic LI Guru Member

  3. cfinic

    cfinic LI Guru Member

  4. HennieM

    HennieM Network Guru Member

    Have not read the links you posted, but here some general info:

    Using some arbitrary IPs, so hopefully you'll get the idea. ("/24" means "netmask")
    base IPs:
         net1 --------------VPNdev1 ---------inet------ VPNdev2------------- net2
    ( - --inet-- a.b.c.d- - (
    VPN IPs:
         net1 --------------VPNdev1 ---------inet------ VPNdev2------------- net2
    ( - ---( - (
    In a single VPN connection, you are linking 2 different networks, net1 and net2 as shown under "base IPs". For starters, net1 and net2 cannot have the same IP range. [I suspect this is your problem.] I have used the 192.168.1 range for net1, and the 192.168.2 range for net2.

    When you link net1 and net2, you are bringing in a third network, net3, which cannot have the same IP range as either of the previous 2. I used the 192.168.3 range. This is the VPN network.

    So by the time your VPN is established
    VPN device 1 will have 3 IPs: on LAN side, z.y.x.w on WAN side, and VPN IP

    VPN device 2 will have 3 IPs: on LAN side, a.b.c.d on WAN side, and VPN IP

    Now, ALL devices on net1 must know 2 additional routes:
    1) To get to net3, it must send packets to VPNdev1, viz
    2) To get to net2, it must send packets to VPNdev1, viz
    This routing (1 and 2) is usually taken care of by the VPN software when setup. What is usually NOT taken care of, is that
    3) VPNdev1 must know that the route to net2 is over its VPN interface (, NOT over its WAN interface (z.y.x.w).

    Similarly (as routing is a 2-way street), ALL devices on net2 must know:
    1) To get to net3, it must send packets to VPNdev2, viz
    2) To get to net1, it must send packets to VPNdev2, viz
    3) VPNdev2 must know that the route to net1 is over its VPN interface (, NOT over its WAN interface (a.b.c.d).

    [I have no clue how RVxx routers work, so you'll have to work out how to correct the routing on your RVs if it's not right.]

    Now, say you have a PC5 on net1 with IP, and you have a PC6 on net2 with IP, and you are sitting at PC5, you will acees the shares on PC6 as:


    The name of PC6 might work, like \\PC6\ShareName, but that's usually a problem.

    Hope this helps.
  5. cfinic

    cfinic LI Guru Member

    Thank you for the input. It was very informative, I will most likely read over it again. The issue that I'm seeing is that (in teh example listed above) I am sitting at PC5 with the IP address of then I log-on to the network that PC6 is on, so it assigns PC5 the IP address of, then when I try going to PC6 (either by IP address or name) PC5 doesn't see it.

    Alternatively I have the same setup on another router at another location. If I sit at PC5 with the IP address of and log-on to the same network as PC7 it gives me an IP address of and I am able to access PC7.

    I cannot see the difference between these 2 networks, other than one is a 10.x.x.x and the other is a 192.x.x.x.
  6. HennieM

    HennieM Network Guru Member

    I have completely misunderstood your setup, so my blabbering above would not be quite applicable. However, your problem may still be related to routing. You may have a netmask of somewhere, so when you connect a PC with IP 192.168.1.x to a network with IPs in the range 192.168.2.x, these 2 networks are seen as being on the same subnet, and don't get routed, i.e.

    If you don't find a netmask or other fault, I suggest you perhaps change ONE of the networks to IPs in the range 172.16.1.x/24 (which is also private IPs). This would ensure that your 2 networks are on completely separate subnets, so even if you have a mask of /16 somewhere, it should not matter.
  7. cfinic

    cfinic LI Guru Member

    Well after switching the DSL connection to 172.16.1.x I will not connect to the 192.168.2.x network VPN :mad: but I can connect to the 10.50.1.x network without an issue. This thing is really starting to naw into the back of my brain. It just freezes on Verifying Username and password then errors out to 619... but I didn't do anything to that router... it just quit working.
  8. cfinic

    cfinic LI Guru Member

    Well I figured out that what I listed above is a separate issue and that it can be remedied by unplugging the DSL Modem then plug it back in again.

    On a note with the PPTP not connecting properly, when I changed the network here to a 172.16.x.x network and VPN'd in I was able to access the other systems no problem, but when I switched back to a 192.168.x.x network, no go. I will be switching this network to another IP set so if a user is on a 192.168.x.x connection they will still be able to access remotely. Thanks for all the help on this one.
  9. HennieM

    HennieM Network Guru Member

    Glad you got sorted. You can use any of the following ranges for a private net: - - -

    Be sure to use netmask all over, as it's unlikely that you would have or want more than 254 PCs/devices on one subnet. For the VPN connection, you could even use netmask if it's 1 VPN connection at a time.
  10. cfinic

    cfinic LI Guru Member

    Well I think after reading somewhere (I think I read a little too much the past couple days) that the built in Linksys PPTP VPN uses a, but somewhere there's a netmask of

    I think I'll just do all class A IP address on our network, or I may be tempted to do class B as I rarely see them and I think that would be the best way to avoid conflict in the future.
  11. cfinic

    cfinic LI Guru Member

    And I just want to confirm, I set up as the following:

    10.x.x.x For Chicago
    10.y.y.y For Colorado
    10.z.z.z For the user's network

    I am able to connect to either VPN using PPTP, now all I have to do is mess with that site to site, which I believe is caused by the router having a private IP for its WAN IP address.
  12. cfinic

    cfinic LI Guru Member

    Ok, so here's the current configuration:

    Co: 10.x.x.x
    Il: 10.y.y.y
    User: 192.168.x.x

    I am able to connect to the VPN, I can access the main \\10.x.x.4\ of the file server, but when I try to go to \\10.x.x.4\files it just errors out on me. When I try to ping the server 10.x.x.4 it drops all packets. I am confuzzled...

    Here is the error:
  13. cfinic

    cfinic LI Guru Member

    Can anyone take a look at the message?
  14. DocLarge

    DocLarge Super Moderator Staff Member Member

    Been busy for a while...

    Here's what I found:

    Finally got it to work by doing this: (Follow instructions exactly as the upper and lowercase letters in IrpStackSize DO matter)

    Start Regedit and go to...


    Check for the presence of a value named IrpStackSize. If it doesn't
    exist, create it as type DWORD. With base set to decimal, enter the
    value 20.

    Reboot the computer.

    Unplug your router and let sit for 30 seconds or so, then replug it in to reboot it so the network refreshes.

    Done. And I tried EVERYTHING before this. Hope it helps

    For a better understanding, read through this thread:
  15. cfinic

    cfinic LI Guru Member

    Thanks Doc,

    I tired the above mentioned method, I read through the thread and it seemed to be a different issue, but I figured I'd give it a shot.

    VPN seems to connect quicker now
    Still can't get to the server

    Hopefully this information will give it a little kick forward.

    When I connect to the VPN I have the IP Address of 10.x.x.195 and I know the computers on the remote LAN are 10.x.x.x I downloaded the solar-winds tool kit and used the DNS look up tool. I was able to locate all the computers, but could not ping any of them. I also tried connecting via the \\computername and it wouldn't connect.
  16. cfinic

    cfinic LI Guru Member

  17. cfinic

    cfinic LI Guru Member


    For grins and giggles I connected to our other VPN and ran a Ping Sweep, I was only able to ping/resolve for the systems that were in the port forwarding. So I compared and mimicked it on the router/network that I'm having issues with. Now instead of getting "Request timed out" I get "Network Unreachable"

    Not sure if that is a step forward or backward.

    just for an example:

    We run service A on a server in chicago using port 666. Even though we do not have that same service on port 666 here I forward it to the system I'm trying to access.
  18. cfinic

    cfinic LI Guru Member

    Update again:

    I found that if I connect both systems to the Il VPN connection I am able to connect to the server, so that tells me that it isn't the server/firewall issue. I will use this as a work around for the moment, but I really need something better.
  19. cfinic

    cfinic LI Guru Member

  20. cfinic

    cfinic LI Guru Member

    I've been talking with Linksys, we did a wireshark capture using a hub connected to the line going to the server. When I ping it from the VPN client it doesn't register the pings so that tells me that the built in VPN server is not allowing traffic to pass.
  21. cfinic

    cfinic LI Guru Member

    So they're finally replacing the router because they weren't able to recreate the issue in their lab.
  22. cfinic

    cfinic LI Guru Member

    So I got the replacement router, Plugged it in, set it up the exact same way as before and was still unable to connect to the server. I checked with my ISP and they assured me there was nothing on their end, so I got the case number and referred Linksys to them.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice