Mapping Network Drives over vpn

Discussion in 'Tomato Firmware' started by sites, Jan 28, 2014.

  1. sites

    sites Networkin' Nut Member

    I admit that I'm not at all familiar with much of what I am trying to do, but I've come this far already using this guide. I've successfully connected a client to my toastman flashed WRT54GL router. Now I'm trying to connect to a shared folder on the server side. I can log into the router serving the vpn from the client & I can ping the address of the PC which is sharing the folder on the server side, but have failed to get into the desired folder. I've tried following all the tips I've been able to find, but now my head is spinning. If there is a better way to do this, I'm open for the suggestion. I have another WRT54GL router on the client side that can be flashed with the same toastman firmware if necessary. I had the notion that using a "road warrior" type of setup would allow the users on the client side to use their own network most of the time, while only connecting to the vpn when necessary. I assume this would be better than having them start/stop the service from the tomato administration. As of now connecting/disconnecting with the OpenVPN client software is simple enough, so all I need at them moment is to be able to map a folder so they can access it once connected. Am I in the right ballpark with this assumption? I would also like to have this setup with the best possible speed & performance in mind. Any help I can bribe from you guys will be met with my complete & unwavering appreciation and awe, not to mention some donations when I'm blessed with adequate coin as a result of my efforts. Cheers.
  2. quihong

    quihong Networkin' Nut Member

    Have you tried mapping a drive via IP Address?

  3. sites

    sites Networkin' Nut Member

    Yes, using IP as well as hostname.
  4. quihong

    quihong Networkin' Nut Member

    Last edited: Jan 29, 2014
  5. sites

    sites Networkin' Nut Member

    Thank you, quihong. I will give that a look.

    Edit: Yes, I remember viewing your walk-through before now. The 2x54GL's, upon which I've installed 1.28.7635 Toastman-IPT-ND ND VPN, being used here don't have USB. I have an RT-N16 & plan on following your instructions with it at a later date, but this doesn't affect the setup I'm facing in this case. I'll look into the Shibby ware.
    Last edited: Jan 30, 2014
  6. koitsu

    koitsu Network Guru Member

  7. sites

    sites Networkin' Nut Member

    I could switch to tap instead. When I've tried it using the current configuration the client fails to connect, with an error about ifconfig. Let's say I changed the server to tap & udp, which I've read is the way to go, then what about the client & server config files? I have yet to get them right in this type of setup. I'm also unsure about some things on the server side. Does openvpn need to be running on the computer with the shared folder I'm trying to map, or is everything pretty much taken care of by the tomato router? Would this whole thing be easier with a CLIENT-ROUTER --> SERVER-ROUTER vpn instead of the roadwarrior type CLIENT-PC --> SERVER-ROUTER??
    Last edited: Feb 2, 2014
  8. koitsu

    koitsu Network Guru Member

    tap vs. tun has no real bearing on this situation as I understand it.

    Your initial description is missing a lot of necessary technical details. I'm sorry but you really need to provide all the IP addresses involved in this mess of a setup, as well as a topology diagram (with proper indicators of what device has what IP per interface, etc.). VPNs are not "simple networking". You also don't disclose if the CIFS server is the router itself or a machine on your LAN (yes it matters! Greatly!).

    Based on the very last screenshot in that link you provided, the IP address range being used for VPN clients is part of, which is perfectly fine except for the fact that it's IANA reserved space on top of IANA reserved space (i.e. the router ends up having to live on two networks, and, but your machines on the server's LAN probably do not live on

    I'm familiar with VPN setups unrelated to Tomato, either client-to-server (i.e. "I have a workstation that needs to be on the corporate network (LAN) when VPN'd into it, and be able to talk to all the systems on the corporate network (LAN)"), or network-to-network (i.e. using a VPN as a way to bridge a single network together but in two separate geographic locations).

    The complexity of the client-to-server method is when the "corporate network (LAN)" happens to have the same addressing topology as the client's own local LAN. Ex. client1 is on a LAN (behind NAT/router) using, then VPNs into a server (, and that server has access to the corporate network (LAN) where they also use This won't work because the VPN client ends up getting an IP address within the network, and the client OS ends up being unable to determine if packets for should go to the client's own local LAN or the corporate network (LAN).

    Sadly the only solution for this is to renumber one of the two LAN networks (either client1's LAN or the corporate LAN) to not conflict. This is often why on corporate networks folks use (or some part of it), because so many consumer routers use (or sometimes

    Sorry if I have made your issue more complex, but as I said, VPNs are not "simple". They require a lot of familiarity with netblocks, interfaces, and routing. The situation becomes even worse if, say, a VPN server sits behind a firewall, or a VPN server sits behind NAT (OpenVPN can work with this, but oh god does it become a complete nightmare; real IPsec cannot deal with this). It's a lot easier to troubleshoot VPN stuff like this if a person familiar with networking (and packet capturing) can physically be present.

    Otherwise if the sole and only goal is "I want clients to be able to VPN into my server (Tomato router) and be able to access a directory that has files in it", then that can be solved without use of VPNs and instead simply using SSH with a port forward/tunnel (on the client side) and a FTP server running on the actual router itself (I think only FTP active mode would work in this model). That may require some very specific firewall rules to pass proper traffic (FTP is a kind of annoying protocol, active vs. passive mode making things difficult), but it'd work.
    Last edited: Feb 2, 2014
  9. sites

    sites Networkin' Nut Member

    What's needed here is a VPN. That is the only option.

    I've figured it out, across tap. Just needed to fidgit with the client config a bit more. Drives are mapped & work as needed. Interesting to note that I'm networked via a wifi connection being shared over the LAN to another router. The only router configured for vpn in the following chain is the server, & the only static IP is the computer with the shared folder.

    PC#1 (client) IP 10.xx.xx.xx @ router#1 ->
    PC#2 LAN shared from wifi w/IP 192.168.254.xx @ router#2 ->
    internet -> router#3 WRT54GL vpn+ddns & connects w/IP 192.168.0.xx ->
    PC#3 shared folder

    Now I'll work on security options.

    Thank you, quihong & koitsu, for all your help! I'm sure that I'll return for more assistance in the future :D
    Last edited: Feb 2, 2014
  10. koitsu

    koitsu Network Guru Member

    That configuration (network/IP-wise) definitely looks like it should work, so I'm glad to hear using tap rectified the issues you ran into with tun. It makes sense, too, actually -- tun is for tunnelling, tap is for bridging: When I used OpenVPN to bridge two co-located datacenters together (a month or so project when migrating from one to the other), and this was on FreeBSD, I definitely used tun -- because I literally wanted to bridge two networks, securely, over the Internet.

    Stackoverflow came in handy for a "simple" answer regarding the behavioural difference as well:

    The problem with CIFS/SMB is that there's a lot more than goes on "surrounding" the overall protocol than meets the eye. Supposedly recent implementations are all just supposed to work using TCP port 445, but even at my day job (including last week!) we've run into problems where firewall-wise passing TCP 445 works but the underlying OS/applications still insist there is a problem (meaning there is other crap going on under the hood / in the OS that really isn't being discussed. My gut feeling is that NetBIOS is trying to get its grubby hands in first).

    And SMB itself -- at least the versions (1.0) used prior to Windows Vista -- was never designed to be used across WAN links (think "high latency" as in "larger than a few milliseconds"):

    P.S. -- Your profile picture/avatar made me LOL.
  11. sites

    sites Networkin' Nut Member

    Hi ya! Back for more. :D Now my second client (client2) isn't connecting. In the log the last lines are about not finding the certificate & key for the first client (client1). I know, my naming habits are brilliant, but try not to get lost in the disco lights. On client1 I only put the certificate and key made for client1 in the /config folder. I thought the procedure would be similar for client2, but I'm wrong, apparently. Why is client1 certificate and key being called for when trying to connect from client2? Why doesn't client2 certificate and key get called for when connecting client1?

    EDIT: I fixed it by uncommenting the other client(s) in the config files.
    Last edited: Feb 5, 2014
  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