Mac OS clients can connect, but no LAN access
-
I posted this on OpenVPN's forums but have yet to get a response. Was wondering if anyone here has ran into this…
I'm running into a brick wall trying to get any Mac computer to fully connect to our VPN. It connects without issue, but then I cannot ping any host except other remote VPN clients.
Our Setup:
Server: OpenVPN 2.3.11 server (on pfSense 2.3.2-RELEASE-p1)
Example Remote Client: Mac OS Sierra (10.12.2) running Tunnelblick 3.7.1beta01 (build 4800)VPN IP Range for remote clients: 10.8.15.0/24
Local IP ranges for the main office they are connecting to:
10.8.10.0/24
10.8.11.0/24
10.8.12.0/24External IP used (changed for security, example only):
1.1.1.130OpenVPN server config:
[2.3.2-RELEASE][root@fw]/var/etc/openvpn: cat server1.conf dev ovpns1 verb 1 dev-type tun 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 local 1.1.1.130 tls-server server 10.8.15.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server1 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'vpn.mydomain.org' 1" lport 1194 management /var/etc/openvpn/server1.sock unix push "route 10.8.10.0 255.255.255.0" push "route 10.8.11.0 255.255.255.0" push "route 10.8.12.0 255.255.255.0" push "dhcp-option DNS 10.8.12.4" client-to-client 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
An example client config:
dev tun persist-tun persist-key cipher AES-256-CBC auth SHA256 tls-client client resolv-retry infinite remote 1.1.1.130 1194 udp verify-x509-name "vpn.mydomain.org" name ns-cert-type server comp-lzo adaptive
Now here's the interesting part….Windows clients work just fine! They can ping any host in the subnets being pushed to them. I've attached a route list for a Windows client below:
The client's VPN IP is 10.8.15.2For comparison, here is the routing table on a Mac:
The client's VPN IP is 10.8.15.3What strikes me as weird here are the routes to itself…(10.8.15/24 and 10.8.15.3 both having a gateway of 10.8.15.3). Is this just an odd way of saying "on-link" like Windows does?
The only part of the client log that jumps out at me on a Mac is this:
Right before the highlighted bit that says it can't assign requested address.No errors in the OpenVPN server log on pfSense.
To wrap things up….Windows remote clients who are using the VPN have no issues pinging any local IP in the main office. Mac clients cannot ping any local IPs in the main office, but they can ping other remote VPN clients.
Ideas? I'm fresh out. This is also affecting Linux clients as I just found out.
-
We've further narrowed down the problem…
This affects Windows as well. We found the issue to be that the first client who connects to the VPN will work fine, but all subsequent clients have the issue I described above.
Ideas?
-
Bump.
Any ideas on this? This is severely hampering our remote workers…since only 1 client can connect. Please help
-
How are your users authenticating? Looks like certificates with no username/password (Remote Access (SSL/TLS)).
Sounds like they are all authenticating as the same user. Though that usually appears as subsequent connections "kicking off" the prior connection.
Try enabling Duplicate connections on the server.
-
How are your users authenticating? Looks like certificates with no username/password (Remote Access (SSL/TLS)).
Sounds like they are all authenticating as the same user. Though that usually appears as subsequent connections "kicking off" the prior connection.
Try enabling Duplicate connections on the server.
Each client has their own unique user account and associated certificate in pfSense. I'm using the openvpn-client-export package to give a config file to each user.
They aren't sharing anything.
-
Do you have something silly in your OpenVPN firewall rules, like only allowing connections from the first tunnel address?
This pretty much "just works."
-
Do you have something silly in your OpenVPN firewall rules, like only allowing connections from the first tunnel address?
This pretty much "just works."
Right, this has always "just worked" in the past for me. Why it's allowing only 1 connection is beyond me…
This is the only OpenVPN rule:
The only error showing up in the server OpenVPN logs is:
ERROR: FreeBSD route add command failed: external program exited with error status: 1
-
I found the issue….
There was a test VLAN added with the same IP as the OpenVPN server. Disabling that fixed everything.
Wow. >:(
-
That'll do it.
-
That'll do it.
Indeed.
For my own understanding, why would OpenVPN allow one connection though? I get that 10.8.15.0/24 couldn't get outside of VLAN 15 because there were no routes outside of it, but why would the first connection be able to get to all other VLANS? Is OpenVPN somehow above the law so to speak in the network stack?