WinXP OpenVPN client connects but is unable to access share



  • Hi all. I've been banging away at this for a while, trying to get a simple road warrior setup going between a WinXP machine and a pfSense 1.2.3 install on a dedicated desktop system.  I did do a bunch of searching on here to find a solution, but I'm stuck.

    I can connect reliably to the OpenVPN server on pfSense 1.2.3 using OpenVPN client 2.1.4 (there's a bug, #125, in OpenVPN 2.2.1, apparently). However, once I'm connected, I can't browse the shares at \192.168.1.10.

    I wish there was one definitive wiki article how-to somewhere that everyone edited and kept updated. Seems like there is not one fully complete how-to anywhere.

    I have a simple road warrior OpenVPN setup, following these how-to's:

    pfSense OpenVPN server config:

     <installedpackages><openvpnserver><config><disable><protocol>UDP</protocol>
    				 <dynamic_ip><local_port>1194</local_port>
    				<addresspool>192.168.2.0/24</addresspool>
    				 <nopool><local_network>192.168.1.0/24</local_network>
    				 <remote_network><client2client><crypto>BF-CBC</crypto>
    				<auth_method>pki</auth_method>
    				 <shared_key><ca_cert>[i]private[/i]</ca_cert>
    				<server_cert>[i]private[/i]</server_cert>
    				<server_key>[i]private[/i]
    				 <crl><dhcp_domainname><dhcp_dns><dhcp_wins><dhcp_nbdd><dhcp_ntp><dhcp_nbttype>0</dhcp_nbttype>
    				 <dhcp_nbtscope><dhcp_nbtdisable>on</dhcp_nbtdisable>
    				<use_lzo>on</use_lzo></dhcp_nbtscope></dhcp_ntp></dhcp_nbdd></dhcp_wins></dhcp_dns></dhcp_domainname></crl></server_key></shared_key></client2client></remote_network></nopool></dynamic_ip></disable></config></openvpnserver></installedpackages> 
    

    There is no interface assignment for the server TUN adapter. I created one and configured a firewall rule for it, but I deleted it when it didn't help.

    Do I need to have one? The forum how-to mentions it in an off-hand way at the end like it should be created automatically, but the book doesn't mention it at all, so I suspect it's not really necessary.

    pfSense firewall rules:

     <filter><rule><type>pass</type>
    			<interface>wan</interface>
    			 <max-src-nodes><max-src-states><statetimeout><statetype>keep state</statetype>
    			 <os><protocol>udp</protocol>
    			<source>
    				 <any><destination><network>wanip</network>
    				<port>1194</port></destination> 
    			<descr>Allow traffic to OpenVPN server</descr></any></os></statetimeout></max-src-states></max-src-nodes></rule> 
    		 <rule><type>pass</type>
    			<interface>lan</interface>
    			 <max-src-nodes><max-src-states><statetimeout><statetype>keep state</statetype>
    			 <os><source>
    
    <address>192.168.1.0/24</address>
    
    			 <destination><any></any></destination> 
    			<descr>Default LAN -> any</descr></os></statetimeout></max-src-states></max-src-nodes></rule></filter> 
    

    My client config file is exactly as it is in the book, except for putting the entire path for the certificates and client key:

    client
    dev tun
    proto udp
    remote IP_addy_of_WAN_interface 1194
    ping 10
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
    cert "C:\\Program Files\\OpenVPN\\config\[i]hostname[/i].crt"
    key "C:\\Program Files\\OpenVPN\\config\[i]hostname[/i].key"
    pull
    verb 3
    comp-lzo
    

    route print on the client:

    ===========================================================================
    Interface List
    0x1 ........................... MS TCP Loopback interface
    0x2 ...00 1e 65 c6 08 22 ...... Intel(R) WiFi Link 5100 AGN - Packet Scheduler Miniport
    0x3 ...00 22 68 15 9e 28 ...... Intel(R) 82567LF Gigabit Network Connection - Packet Scheduler Miniport
    0x20004 ...00 ff b4 82 be 71 ...... TAP-Win32 Adapter V9 - Packet Scheduler Miniport
    ===========================================================================
    ===========================================================================
    Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
              0.0.0.0          0.0.0.0     192.168.43.1   192.168.43.18	  25
            127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
          169.254.0.0      255.255.0.0    192.168.43.18   192.168.43.18	  20
          192.168.1.0    255.255.255.0      192.168.2.5     192.168.2.6	  1
          192.168.2.1  255.255.255.255      192.168.2.5     192.168.2.6	  1
          192.168.2.4  255.255.255.252      192.168.2.6     192.168.2.6	  30
          192.168.2.6  255.255.255.255        127.0.0.1       127.0.0.1	  30
        192.168.2.255  255.255.255.255      192.168.2.6     192.168.2.6	  30
         192.168.43.0    255.255.255.0    192.168.43.18   192.168.43.18	  25
        192.168.43.18  255.255.255.255        127.0.0.1       127.0.0.1	  25
       192.168.43.255  255.255.255.255    192.168.43.18   192.168.43.18	  25
            224.0.0.0        240.0.0.0      192.168.2.6     192.168.2.6	  30
            224.0.0.0        240.0.0.0    192.168.43.18   192.168.43.18	  25
      255.255.255.255  255.255.255.255      192.168.2.6               3	  1
      255.255.255.255  255.255.255.255      192.168.2.6     192.168.2.6	  1
      255.255.255.255  255.255.255.255    192.168.43.18   192.168.43.18	  1
    Default Gateway:      192.168.43.1
    ===========================================================================
    Persistent Routes:
      None
    

    ipconfig /all on the client, edited to only include the OpenVPN TUN interface:

    
            Connection-specific DNS Suffix  . : 
            Description . . . . . . . . . . . : TAP-Win32 Adapter V9
            Physical Address. . . . . . . . . : 00-FF-B4-82-BE-71
            Dhcp Enabled. . . . . . . . . . . : Yes
            Autoconfiguration Enabled . . . . : Yes
            IP Address. . . . . . . . . . . . : 192.168.2.6
            Subnet Mask . . . . . . . . . . . : 255.255.255.252
            Default Gateway . . . . . . . . . : 
            DHCP Server . . . . . . . . . . . : 192.168.2.5
            NetBIOS over Tcpip. . . . . . . . : Disabled
            Lease Obtained. . . . . . . . . . : Sunday, July 17, 2011 5:55:18 PM
            Lease Expires . . . . . . . . . . : Monday, July 16, 2012 5:55:18 PM
    

    I have no idea why no Default Gateway shows up here. My research has pulled up no cause and other posts I've found in this forum where people have posted their ipconfig with the same blank gateway say their setup works.

    Thanks in advance for any help anyone can offer.



  • Default gateway won't ever show up there, you don't have a default on a VPN (or the VPN itself would become unreachable). Assuming you don't have auto-added VPN rules disabled, you don't need to assign the tun interface. Routes look ok, you're getting a route for 192.168.1.0/24 via the VPN. First try to ping the LAN IP, I presume 192.168.1.1. If that works, your VPN is set, then try to hit various things on the LAN. Usually if you can't get to a Windows share off-subnet but the VPN is working as it appears to be, it's a local firewall on that host. The Windows firewall commonly allows only the local subnet to file sharing, etc.



  • Disabling the ESET Smart Security firewall didn't seem to make a difference. I'll check out its entire configuration to see if I'm missing something there.

    I'm planning on testing connection from an Ubuntu client today.

    Oddly, the XP client from my first post has been able to occasionally ping systems on the office LAN and was able to view the pfSense Web GUI a couple times but not several other times. Also, an HP MFP Web GUI has come up reliably.



  • I double-checked my client's firewall settings and they were correct. I confirmed that disabling the firewall made no change in whether the client was able to view network resources in Windows Explorer after connecting over OpenVPN. The OpenVPN connection goes smoothly.

    I tested connecting with an Ubuntu client. The results were exactly the same. It connected up just fine, can ping hosts on the LAN, but can't view SMB shares. It can, however, view the pfSense Web GUI and Web GUI's for MFP's on the LAN.

    I can SSH to a Samba server on the network whose shares I can't view in Windows Explorer or Nautilus.

    Once I'm connected to the VPN I can no longer access the Internet on the client.

    I must have something wrong in my networking config…



  • By "can't view SMB shares", you mean browse the network? That's common with cross-subnet attempts at network browsing, it's a Windows/general protocol issue, if you Google on cross-subnet network browsing you'll find info on that in general. If you go direct to the machine and that works, then that's your issue.



  • No, sir. I mean if I type the UNC path with IP addy ("\192.168.1.50") in the Windows Explorer address bar or the SMB path in the Nautilus Location bar ("smb://username@192.168.1.50/"), it times out.

    I do suspect it's a protocol issue or routing issue.



  • Should I move this to a different subforum?



  • Actually, I think that's probably as far as I can get in a forum setting. There's just on-site troubleshooting to be done now.

    CMB, thanks much for your time and for confirming my OpenVPN config.


  • LAYER 8 Global Moderator

    Ok going to have to look up this bug #125 in 2.2.1 because I am using it just fine.

    So here at work, on XP box - and connected via openvpn road warrior into my pfsense box (2.1-DEVELOPMENT (i386))

    I don't have any issues accessing the pfsense webui through the vpn, nor do I have any access with shares on boxes on the other side of my vpn.  Now you will have to auth to them, which you might have an issue if you say just run \ipaddress

    So you can see in attached, pinging - then net view says access denied, so I auth and then good can view and access the share just fine via unc, or can map a drive letter, etc. etc.

    Now I have not used 1.2.3 in quite some time, is there some reason you don't/cant run the 2.0?  But as I recall I never had a problem with doing this on 1.2.3 either.

    Can you post what happens via doing the same sort of thing I did in the attached image?

    For completeness I just checked the version of openvpn on my pfsense box
    [2.1-DEVELOPMENT][admin@pfsense.local.lan]/root(10): openvpn –version
    OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jul  6 2011
    Originally developed by James Yonan
    Copyright (C) 2002-2010 OpenVPN Technologies, Inc. sales@openvpn.netBTW how would that bug come into play??  Is the 125 your talking about? https://community.openvpn.net/openvpn/ticket/125
    Build CA is broken in Windows on version 2.2 release


    /sales@openvpn.net



  • Thanks, John. I'll try those things and reply.

    No, there's no reason I'm using 1.2.3 over 2.0, except that I'm a newbie and the book covers 1.2.3. I'm comfortable enough now that I could upgrade it.

    That's right about bug 125 stopping me because I ran easy-rsa on the client and couldn't run "build-ca.bat". Now, though, I would run it on the pfSense box. So I could upgrade that, too.


  • LAYER 8 Global Moderator

    I would just move to the 2.0 line, I think its not far from being released.  As you can see I moved to the 2.1 development they moved the IPv6 stuff there.  I would highly recommend that if you want to play with ipv6.

    Man its been awhile since I was on 1.2.3, I think I moved over to 2 on one of the early betas, I know it was well before the RCs – to be honest is been pretty freaking solid, couple of hickups with commits that caused some issues now and then -- but overall I have been very very pleased with it!!

    If you move over to the 2.0 stuff I can be of more help in getting your openvpn working, I use it daily from work to my home network - solid as a rock..  Even using it over a http proxy currently and still rock solid performance.



  • Hi!
    Apparently I have much of the same problem…
    My goal is to have my Road Warriors getting the same experience as if they were inside the firewall.

    System: pfsense 2.0 RC3
    Client config:

    dev tun
    persist-tun
    persist-key
    proto tcp
    cipher BF-CBC
    tls-client
    client
    resolv-retry infinite
    remote xx.xxx.xx.xxx 1194
    tls-remote yyyyyyyyyy
    auth-user-pass
    ca pfSense-tcp-1194-ca.crt
    tls-auth pfSense-tcp-1194-tls.key 1
    

    OpenVPN connects fine both from windows (with OpenVPN client) and osx (tunnelblick client)
    I am able to ping servers (with IP-address) on my LAN from Road Warrior
    I am able to open web-addresses on my LAN from Road Warrior (e.g. the pfsense configurator)
    I'm however not able to map a network drive from windows, nor from osx with smb
    Ping on hostname does not work (UPDATE: solved with DNS-settings)
    mstsc to LAN with IP works (UPDATE: also works after editing DNS-settings)

    Example:
    I have a XP-computer with some shares on my lan, 192.168.8.100:

    C:\Users\Roald>net view \\192.168.8.100
    Systemfeil 53 har oppstått. (System error 53)
    
    Nettverksbanen ble ikke funnet. (Path not found)
    
    C:\Users\Roald>ping 192.168.8.100
    
    Pinger 192.168.8.100 med 32 byte data:
    Svar fra 192.168.8.100: byte=32 tid=142ms TTL=127
    Svar fra 192.168.8.100: byte=32 tid=160ms TTL=127
    Svar fra 192.168.8.100: byte=32 tid=148ms TTL=127
    Svar fra 192.168.8.100: byte=32 tid=87ms TTL=127
    

    Until recently I used the Endian Community firewall, and there this worked fine. I abandoned Endian for other reasons though.

    Thankful for any hint :)



  • No idea? Anybody?



  • Try using tap (bridge) instead of tun (routing).



  • Hi,

    I get a similar problem but only related to the name resolution.

    @rkleivel : what did you set on the DNS settings to make the name resolution to work ?

    @Cry Havok : I tried to set "tap" instead of "tun" but I'm NOT able to connect at all !

    Thanks



  • Do you get an IP address from the LAN DHCP server?

    Are you in the same IP range? Can you connect from another computer on the LAN?



  • @Cry : Not sure these questions are for me but…

    1. Using "tun" I'm able to connect without problem
    2. Once "in"...
    2.1 I'm able to ping everything on every LAN
    2.2 I.m able to access resources from the file manager with \ipadress_share_

    Actually, what I'm NOT able to do and cause me trouble is accessing resource with the "netbios" name.
    Let's imagine I do have the following machine ;

    • Name : server

    • IP : 192.168.1.100

    • Share : datas

    Using : \192.168.1.100\datas -> Works !
    Using : \server\datas -> Don't Work !

    Looks like a simple issue but give me a lot of problems.
    According rkleivel  it can be solved with the DNS !

    Actually, my networks are setup like this ;

    • Local LAN : 192.168.1.0/24

    • Remote VPN : 10.0.8.0/24

    • Remote LAN : 192.168.0.0/24

    I added a picture of the remote VPN configuration of the network.
    As you will see, I added both DNS server (VPN & RemoteLAN) but still not working.



  • LAYER 8 Global Moderator

    well it would make sense that you would not resolve netbios via broadcast methods over a vpn.  Your traffic is routed, not bridged so broadcast traffic would never get from your remote network to your segment on the other side of the vpn.

    Yes dns would be a way of resolving name, or a wins server or host/lmhost file on your clients, etc.

    so example, connected currently to my home network via openvpn from work.  my popcorn box, I can not view it by netbios name pch.  53 = can not find.

    If I use dns, then it works pch.local.lan and I get error 5 access denied.  So I auth and then I can view, etc..

    
    D:\>net view \\pch
    System error 53 has occurred.
    
    The network path was not found.
    
    D:\>net view \\pch.local.lan
    System error 5 has occurred.
    
    Access is denied.
    
    D:\>net view \\192.168.1.99
    System error 5 has occurred.
    
    Access is denied.
    
    D:\>net use \\pch.local.lan\ipc$ /u:pch\nmt 1234
    The command completed successfully.
    
    D:\>net view \\pch.local.lan
    Shared resources at \\pch.local.lan
    
    SMP8634 Share
    
    Share name  Type  Used as  Comment
    
    ------------------------------------------------------
    share       Disk
    The command completed successfully.
    
    

Log in to reply