I recently posted a question about OpenVPN Requirements and have ongoing items to address there related to a recent RRAS crash. But as I search the Peplink Community site more broadly, I don’t see a long list of recent OpenVPN conversations.
Things I Would Like Know
- Does this forum community like the built-in OpenVPN for Remote User Access?
- I have only one Balance 305, not using SpeedFusion or OpenVPN WAN - just your basic Remote User Access with Full Tunnel for a small business
- Do people generally use VPN anymore for file sharing or on-prem access, or is this passé?
- What gotchas did you encounter when first setting up OpenVPN?
- Did any of you start with MS RRAS, then switch to OpenVPN?
- Did your end users have problems mapping drives, accessing on-prem applications, databases?
- Did random end users have ISPs that blocked VPN services or other ports (SMB, RDP, etc.)
- How did you overcome the barriers that you experienced?
- Did you work with Peplink Support? I did and shout out to Brian - they’ve been very helpful.
- Are your end user/client devices AD-joined?
- Are your end user/client devices EntraID-joined?
- Are your end user/client devices Out-of-the Box/not joined or bound to any auth provider or domain?
- Are your end user/client devices Windows/MACs?
Like most of us, I suspect Peplink customers/users don’t spend their days browsing and posting [on] the forum unless something is broken OR we’re researching something we’d like to implement in our network. I am hoping to hear from you if you are visiting the forum today and see this post and welcome any insight or experiences you’ve had with OpenVPN Remote User Access. OpenVPN is new to me and I am responsible for ensuring all of my users have reliable access to our on-prem network resources. I feel like I am missing some obvious or obscure pieces.
Thank you in advance - you don’t have to write a novel or comment on all of my questions but your single bit of help might be what I am looking for - you never know!
I will start by offering what I have learned in the process of preparing our network and end users for OpenVPN connections.
What I Have Learned Thus Far
-
No additional license or add-on required to use OpenVPN on the Peplink if only using Remote User Access. Documentation on that was vague and not immediately obvious.
-
We use Entra Connect Sync (not cloud version yet) for user authentication to push/pull user passwords - we do not sync devices, nor are we using an AD/EntraID Hybrid model. This is not something I “learned” in this process but might be helpful to know if you’re domain has a similar implementation.
-
EntraID-Joined devices that have been deployed via Intune have problems gaining access to on-prem SQL databases when users sign in using their Windows Hello PIN. For the best results they must sign in to their devices using their password. This is related to the Kerberos ticketing system and in theory should work for the SQL database access but certain end users still struggle to gain and maintain this granted access.
-
AD-Joined devices have the most ease at accessing their on-prem resources by virtue of their trusted device status in the domain.
-
OpenVPN speeds are erratic, with some end users experiencing severe degradation of internet speeds once OpenVPN connected, while others see no appreciable reduction in speed. We have ~30 users connecting from across the US; our fiber service is 200M U/D, and the CPU of the Peplink Balance 305 router is not showing signs of not handling requests or being overloaded. Those in closest proximity to our physical building don’t always have better experiences as might be expected.
-
Split tunnel doesn’t work for us as users report drive mapping failure, even intermittent drive mount/unmount events. In a nutshell, if the end user’s device IPv4 does not broadcast as (must equal) our Public WAN IP when querying What Is My IP Address, the internal apps and drives fail.
-
Having a current support warranty with InControl access is massively helpful, providing a better GUI to see clients, logs, etc. Worth ~$1K for a two-year term.
-
On-prem DHCP for OpenVPN is not currently supported, which has causes a lot of authentication and access problems, in my opinion as the LAN I created for OpenVPN has to be untagged and can’t relay DHCP to another LAN.
-
Since the OpenVPN LAN is sort of its own island, the internal domain doesn’t “know” as much about this traffic as I would like. I do not have a DHCP Scope on the internal DHCP server or any Forward/Reverse Lookup Zones on the internal DNS servers that reference the OpenVPN LAN subnet.
-
I have added the OpenVPN VLAN on all internal switches, to what end I see no real value, but I tried.
-
The Auto-reset OpenVPN doesn’t work like I expected. I want all client connections to be dropped each midnight, forcing users/clients to reconnect each day. Connection Security Refresh each X minute(s) seems to be the. “keepalive” element. The Authentication Token Lifetime is also confusing to me and I am not sure what it might solve in terms of my goal to essentially bump out users each night at midnight.
-
Also part of our configuration is that we have for WAN 1 a block of 5 public static IP addresses and 9 LANs, 8 of which have a VLAN designation. Most of the LANS are DHCP Relay enabled, but for the OpenVPN LAN. No Static Routes, no One/Many-to NAT mappings, no DNS proxy, 2 local DNS servers, 1 domain lookup. Pretty basic. And WAN2 is a slow DSL backup for disaster recovery purposes and not used for production or remote access purposes.
-
On the client.ovpn side, I manually added the two primary domain controllers to the full tunnel config to “help/force” the drive mapping success - nothing has worked on that front. The OpenVPN connection is lightning fast, it’s all about the routing and DNS/DHCP as this point - whether it is on our end or the end users’ ISPs is hit and miss.
client
dev tun
proto udp
remote <PUBLIC WAN IP ADDRESS> 1194
remote-random
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
auth-nocache
verb 3
setenv CLIENT_CERT 0
remote-cert-tls server
tls-client
reneg-sec 3600
cipher AES-256-GCM
redirect-gateway def1
dhcp-option DNS <IP ADDRESS OF PRIMARY DC>
dhcp-option DNS <IP ADDRESS OF SECONDARY DC>
<ca>
-----BEGIN CERTIFICATE-----
REMOVED FOR SECURITY PURPOSES
-----END CERTIFICATE-----
</ca>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
REMOVED FOR SECURITY PURPOSES
-----END OpenVPN Static key V1-----
</tls-crypt>
