(SOLVED) Users can't access network over VPN but I can
-
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.
-
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: NoneSee the routes to 192.168.2, .3, .9 using 10.0.8.100
-
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 utun4Different 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)
-
-
"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..
-
"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.