(SOLVED) Users can't access network over VPN but I can



  • I've tried looking for solutions for this problem, but I don't know what I should search. Let me describe my problem.

    I've recently setup OpenVPN for our users with authentication against AD. I tested the setup with my account and had no problems, so I went on to setup and check other users. At first, I thought it was going to work fine because other users could get connected, but I quickly found out that wasn't the case. While other users authenticated to the VPN, they can't actually do anything on the network like I can. To make it even weirder, if I am connected the VPN while they are, I can ping their computers just fine. I can also log in with my user account on their computers and have access just fine.

    What I've Ruled Out: I tried creating a test user account in the group domain admins like my account (the only different I can see between my account and other users), but that didn't fix the problem.

    Setup Info: I have setup our OpenVPN to require a certificate and user/pass authentication. To make things easier on me, I'm currently only using one certificate for everyone. Based on my research, this shouldn't make a difference in this specific problem, but maybe I'm wrong.

    Thanks in advance for any help!



  • Post your server1.conf and a network map, so we can visualize how things are laid out and connected.

    Also, what IP(s) are your clients trying to connect to?



  • Here is server1.conf for you. Working on getting the network map together.

    dev ovpns1
    verb 1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    auth SHA256
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local ***.***.***.***
    tls-server
    server 10.10.90.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    username-as-common-name
    auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'OBC AD VPN Users' false server1" via-env
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPNServer' 1"
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 10
    push "route 10.10.5.0 255.255.255.0"
    push "route 10.10.10.0 255.255.255.0"
    push "route 10.10.30.0 255.255.255.0"
    push "route 10.10.20.0 255.255.255.0"
    push "route 10.10.13.0 255.255.255.0"
    push "dhcp-option DOMAIN example.com"
    push "dhcp-option DNS 10.10.5.101"
    push "dhcp-option DNS 10.10.5.102"
    ca /var/etc/openvpn/server1.ca 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    persist-remote-ip
    float
    topology subnet
    


  • Here is a basic network map. Let me know if there is more necessary information needed. Thanks!




  • Any thoughts at all? To be sure, I tried creating a separate certificate for another user and tested that, but still no luck.


  • LAYER 8 Global Moderator

    So when you say they can not do anything on the network.. What exactly does that mean?

    Once they are connected to the the vpn.. Not being admin on the domain has zero to do with anything.  Now its possible their account on their machine if not admin can not create the routes in the client machine to go down the vpn to whatever networks are on that end..

    So your saying your clients connect to the vpn..  Then what can they not do - your saying you can ping IPs on your network, but then they vpn with their account they can not ping?  Post up the route table on the client machine when you connect and then when they connect.

    So for example I am connected to my vpn currently - my route table shows routes to the networks across the vpn.

    route print

    
    IPv4 Route Table                                                                    
    ===========================================================================         
    Active Routes:                                                                      
    Network Destination        Netmask          Gateway       Interface  Metric         
              0.0.0.0          0.0.0.0       10.56.41.1     10.56.41.100     10         
             10.0.8.0    255.255.255.0         On-link        10.0.8.100    276         
           10.0.8.100  255.255.255.255         On-link        10.0.8.100    276         
           10.0.8.255  255.255.255.255         On-link        10.0.8.100    276         
           10.56.41.0    255.255.255.0         On-link      10.56.41.100    266         
         10.56.41.100  255.255.255.255         On-link      10.56.41.100    266         
         10.56.41.255  255.255.255.255         On-link      10.56.41.100    266         
            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306         
            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306         
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306         
          192.168.2.0    255.255.255.0         10.0.8.1       10.0.8.100    276         
          192.168.3.0    255.255.255.0         10.0.8.1       10.0.8.100    276         
          192.168.9.0    255.255.255.0         10.0.8.1       10.0.8.100    276         
            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306         
            224.0.0.0        240.0.0.0         On-link      10.56.41.100    266         
            224.0.0.0        240.0.0.0         On-link        10.0.8.100    276         
      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306         
      255.255.255.255  255.255.255.255         On-link      10.56.41.100    266         
      255.255.255.255  255.255.255.255         On-link        10.0.8.100    276         
    ===========================================================================         
    Persistent Routes:                                                                  
      None                                                                              
    
    

    See the routes to 192.168.2, .3, .9 using 10.0.8.100



  • @johnpoz:

    So when you say they can not do anything on the network.. What exactly does that mean?

    Once they are connected to the the vpn.. Not being admin on the domain has zero to do with anything.  Now its possible their account on their machine if not admin can not create the routes in the client machine to go down the vpn to whatever networks are on that end..

    So your saying your clients connect to the vpn..  Then what can they not do - your saying you can ping IPs on your network, but then they vpn with their account they can not ping?  Post up the route table on the client machine when you connect and then when they connect.

    So for example I am connected to my vpn currently - my route table shows routes to the networks across the vpn.

    Okay I'll answer your questions in order:

    They can not do anything through the VPN. We are using Viscosity for Mac, so I install the inline config from the Client Exporter Utility on pfSense, then they connect and put in their credentials. After a few seconds, Viscosity says connection established and shows what IP they were assigned. This works the same for me and all other clients. The problem comes after that—trying to do anything on the remote network like smb to a server, pull up an internal website, or ping any other machines (including the gateway). It's as if they aren't even connected to the network. However, if I use my credentials (on the same machine), it let's me through fine. The only variable that has changed is my credentials instead of another users'.

    I really didn't ever think this had anything to do with me being a domain admin verses others not being one. It was just the only difference I could think of. All of the other users are administrators on their respective machines, so that shouldn't be a bottleneck. And besides, it works if I log in to the VPN with my credentials.

    As I stated in the first paragraph, they cannot do anything. What made it weird is when I first started troubleshooting, a user called me saying they were connected to the VPN but couldn't connect to our file server. I was at home so I jumped on the VPN myself, and was immediately able to connect to the fileserver. I thought maybe they thought they were connected but actually weren't, so I checked OpenVPN status in pfSense and I could see them as connected. I then tried pinging their machine, and I could, but they couldn't ping me. I'll post the route table below. For comparison, I'll put one from when I'm connected and one from when it's a different user.

    My Table:

    Routing tables
    
    Internet:
    Destination        Gateway            Flags        Refs      Use   Netif Expire
    default            172.20.10.1        UGSc           30        0     en0
    default            link#16            UCSI            1        0   utun4
    10.10.5/24         10.10.90.1         UGSc            4        0   utun4
    10.10.10/24        10.10.90.1         UGSc            5        0   utun4
    10.10.13/24        10.10.90.1         UGSc            2        0   utun4
    10.10.20/24        10.10.90.1         UGSc            2        0   utun4
    10.10.30/24        10.10.90.1         UGSc            1        0   utun4
    10.10.90/24        10.10.90.2         UGSc           16        0   utun4
    10.10.90.2         10.10.90.2         UH              5       26   utun4
    127                127.0.0.1          UCS             1        0     lo0
    127.0.0.1          127.0.0.1          UH             14   380853     lo0
    172.20.10/28       link#4             UCS             2        0     en0
    172.20.10.1/32     link#4             UCS             2        0     en0
    172.20.10.1        7a:40:4e:d3:15:64  UHLWIir        34      108     en0   1151
    172.20.10.2/32     link#4             UCS             2        0     en0
    172.20.10.2        3c:15:c2:e5:13:50  UHLWIi          1        1     lo0
    172.20.10.15       ff:ff:ff:ff:ff:ff  UHLWbI          1        3     en0
    224.0.0/4          link#4             UmCS            4        0     en0
    224.0.0/4          link#16            UmCSI           2        0   utun4
    224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en0
    239.192.0.0        1:0:5e:40:0:0      UHmLWI          1        0     en0
    239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          1       48     en0
    239.255.255.250    link#16            UHmWI           1       11   utun4
    255.255.255.255/32 link#4             UCS             2        0     en0
    255.255.255.255    ff:ff:ff:ff:ff:ff  UHLWbI          1        1     en0
    255.255.255.255/32 link#16            UCSI            1        0   utun4
    

    Different User (same computer)

    Routing tables
    
    Internet:
    Destination        Gateway            Flags        Refs      Use   Netif Expire
    default            172.20.10.1        UGSc           36        0     en0
    default            link#16            UCSI            1        0   utun4
    10.10.5/24         10.10.90.1         UGSc            3        0   utun4
    10.10.10/24        10.10.90.1         UGSc            3        0   utun4
    10.10.13/24        10.10.90.1         UGSc            1        0   utun4
    10.10.20/24        10.10.90.1         UGSc            1        0   utun4
    10.10.30/24        10.10.90.1         UGSc            1        0   utun4
    10.10.90/24        10.10.90.3         UGSc           11        0   utun4
    10.10.90.3         10.10.90.3         UH              4        0   utun4
    127                127.0.0.1          UCS             1        0     lo0
    127.0.0.1          127.0.0.1          UH             14   381200     lo0
    172.20.10/28       link#4             UCS             2        0     en0
    172.20.10.1/32     link#4             UCS             2        0     en0
    172.20.10.1        7a:40:4e:d3:15:64  UHLWIir        42      201     en0    340
    172.20.10.2/32     link#4             UCS             2        0     en0
    172.20.10.2        3c:15:c2:e5:13:50  UHLWIi          2        3     lo0
    172.20.10.15       link#4             UHLWbI          1       58     en0
    224.0.0/4          link#4             UmCS            4        0     en0
    224.0.0/4          link#16            UmCSI           2        0   utun4
    224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en0
    239.192.0.0        1:0:5e:40:0:0      UHmLWI          1        0     en0
    239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          1      102     en0
    239.255.255.250    link#16            UHmWI           1        4   utun4
    255.255.255.255/32 link#4             UCS             2        0     en0
    255.255.255.255    link#4             UHLWbI          1       29     en0
    255.255.255.255/32 link#16            UCSI            1        0   utun4
    


  • have you tried using a different account that was a domain admin?



  • Yes, that's what the second table above is from. No love with that one. :/



  • Some of the obvious things:

    • Verify All LAN devices are using PFsense as the default gateway

    • Verify windows clients are running the OpenVPN client as admin

    • Verify client's LAN doesn't overlap with the tunnel network or any of your VLANs

    • Verify Firewall rules on the OpenVPN tab are not blocking traffic destined to any of your VLANS

    • Verify Firewall rules on your LAN tab are not blocking traffic from your tunnel network

    • If you're pinging Windows servers, verify ICMP echo reply is enabled on the server for all subnets (default behavior is to only reply to traffic sourced from its own subnet)

    Other possibilities:

    • Your server1.conf suggests you're pushing a DNS suffix of "example.com", I'm assuming that was manually edited to hide your domain?  If not, that would be contributing to your issue.

    • Your network map info can be interpreted in different ways, so I'll just ask instead of assuming… are your VLANs terminated on PFsense or your switch?  i.e. is your switch trunked to the LAN interface on PFsense or is there a transit network between PFsense and your switch?  I ask because the wording suggests one thing, but your diagram suggests something else.  Either way, "VLAN 90 (VPN)" should not exist.

    • I have a working setup that is similar to yours with differences being the encryption and auth digest algorithms.  All windows clients work fine, but I have a MAC user that could not get Viscosity working, so he switched to TunnelBrick and everything worked fine and dandy.  Might be worth a shot.

    • Another difference in our setups is I create a separate client cert for each user.  I don't know if your way (using the same cert for all users) is supposed to work, but if you ever find yourself in a situation where you want/need to revoke a cert, you can't… because you're using the same cert for everyone.  That being said, have you created a "Peer Certificate Revocation list"?  I've had situations where things were acting weird until I created that list.

    • How are your clients connecting to their resources?  IP, hostname or FQDN?  In a routed solution, broadcasts (NETBIOS) will not traverse the tunnel, so they should be using IP or FQDN.

    • I doubt this is it, but have you implemented ACL's on your switch?  If so, that'd be another thing to look into

    • Have you checked your system logs?  Are there any notable firewall blocks or OpenVPN error messages upon client connection?

    • Another weird issue I had with the same MAC client from earlier, is he lives in Canada and he wanted to be routed thru me (US), so he could watch Netflix, etc… well... for some reason the routing wasn't working properly while the tunnel was on Topology Subnet... he  would connect, but the routing wasn't doing what we wanted, so I had to switch the tunnel over to Topology NET30 to get him working.  It may or may not help your particular issue, but just thought I would throw it out there.



  • Okay, so I removed and setup OpenVPN again, but did it slightly different this time in a few ways—now it works!. I'm unsure of which item fixed it, but it is working now. Thanks everyone for your help!

    Here are the changes I made (I think these are the only ones):

    • Setup a peer revocation list

    • Used individual certificates and exports instead of one for everyone

    • Removed VLAN90 (a VLAN I had setup for VPN)


  • LAYER 8 Global Moderator

    "Removed VLAN90 (a VLAN I had setup for VPN)"

    That would be my guess to your problem…  Revo list and or what certs is being used as long as they auth have nothing to do with it..



  • @johnpoz:

    "Removed VLAN90 (a VLAN I had setup for VPN)"

    That would be my guess to your problem…  Revo list and or what certs is being used as long as they auth have nothing to do with it..

    Possibly, but the weird thing is one user DID have access through the VPN. I can't reconcile how any of these changes suddenly let all users through instead of just the one. I'm glad I have it working, but I still can't figure out why haha.


Log in to reply