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/24

    External IP used (changed for security, example only):
    1.1.1.130

    OpenVPN 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.2

    For comparison, here is the routing table on a Mac:

    The client's VPN IP is 10.8.15.3

    What 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


  • Netgate

    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.



  • @Derelict:

    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.


  • Netgate

    Do you have something silly in your OpenVPN firewall rules, like only allowing connections from the first tunnel address?

    This pretty much "just works."



  • @Derelict:

    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.  >:(


  • Netgate

    That'll do it.



  • @Derelict:

    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?