Remote user network configuration - best practices

Our remote users have been using a VPN to connect to an on-prem server(10.2.400). We are in the process of switching from OpenVPN to Wireguard(IT expects better performance, less vulnerabilities, and easier management), but we have some users reporting issues(haven’t validated they are legit yet), but this got me thinking we’ve never researched best practices for remote users connecting via VPN…

What recommendations do others/Epicor have in regards to what works well and what to avoid for this scenario?

Do you know if your IT department is rolling their own Wireguard service?

1 Like

Yes, it’s our own Linux based Wireguard server. We’ve been using it for about 6 months and has been faster and more reliable than OpenVPN in my experience. I work in Epicor very little recently so don’t have much experience with it and Epicor…

Gotcha Gotcha…
Well a few things I CAN say is that from the research I did before switching our VPN off of our Fortigate Firewall is that Wireguard is a solid choice. However it can have some weird connectivity issues from my understandings.

From a ‘Best Practices’ perspective I dont know that when it comes to actual connectivity of the VPN that there’s really much to deal with. Split-DNS and Split-Tunneling are a must. You probably do not want ALL of your end users traffic funneling back to the main office just to then go out to the internet. (In otherwords… YouTube should just go straight out. Not over VPN.) Really a VPN is a VPN and as long as you keep both the SERVER and the CLIENTS updated I cannot think of anything much beyond this to worry about. [EDIT:] I am going to add that I think that MFA for the VPN connection should be 1000% included as a Best Practice. I mention it below but wanted to clarify that that should be a BIGGIE

We use a commercial VPN product that implements Wireguard with some of its own special sauce to make things a little more magical. It gives us Login via M365 and MFA so that our Insurance Provider is happy. It works amazingly well. In fact except for one person who had a corrupted installation we have had exactly 0 problems since switching.

1 Like

Interested in what commercial product you are using with Wireguard? We went down the path of a on prem Wireguard server to also try and get away from OpenVPN (~400% price hike during a global pandemic didn’t sit right with me). At the time we couldn’t find a reliable commercial solution and the self built one our MSP deployed during testing had enough bugginess and missing features that we abandoned it and stuck with OpenVPN.

Some people use Tailscale, which is a WireGuard "host"ing service.

WireGuard vs. Tailscale · Tailscale

In addition to Mr. Curtis’s excellent advice on MFA, the better practice for VPNs is to restrict the connections to individual resources and not give access to the entire network. Yes, it’s more work, but you limit the blast area if someone coughs up their credentials and falls prey to MFA attacks like push fatigue.

Are there any Epicor specific configuration we should be aware of for remote users? I ask as in E9 if I’m not mistaken there was a compression checkbox on a user that was recommended for users connected via a WAN I believe but can’t find anything similar in E10. I ask as I wonder if I’m missing something obvious/easy…

Others will correct me if I’m wrong, but net.tcp is much more sensitive to network disruptions. If you can use https, no extra settings are necessary.

1 Like

@Mark_Wonsil I’m really fuzzy as I believe I only looked at our web.config once at go live when we were lucky to have Jose Gomez help us to tweak it to get REST API calls working…

Do you have any recommendations given the following configuration we currently are using(I believe this is the section that specifies if we are using https, but not positive)?

      <remove scheme="net.tcp" />
      <!--<add scheme="net.tcp" binding="customBinding" bindingConfiguration="TcpCompressedWindows" />-->
      <!--<add scheme="net.tcp" binding="customBinding" bindingConfiguration="TcpCompressedUsernameSslChannel" />-->
      <add scheme="net.tcp" binding="customBinding" bindingConfiguration="TcpCompressedUsernameWindowsChannel" />
      <remove scheme="http" />
      <add scheme="http" binding="wsHttpBinding" bindingConfiguration="SOAPHttp" />
      <add scheme="http" binding="customBinding" bindingConfiguration="HttpBinaryUsernameSslChannel" />
      <add scheme="http" binding="customBinding" bindingConfiguration="HttpsOffloadBinaryUserNameChannel" />
      <add scheme="http" binding="customBinding" bindingConfiguration="HttpsOffloadBinaryAzureChannel"/>
      <add scheme="http" binding="customBinding" bindingConfiguration="HttpsOffloadBinaryIdpChannel"/>
      <remove scheme="https" />
      <add scheme="https" binding="customBinding" bindingConfiguration="HttpsBinaryUsernameChannel"/>
      <add scheme="https" binding="customBinding" bindingConfiguration="HttpsBinaryAzureChannel"/>
      <add scheme="https" binding="customBinding" bindingConfiguration="HttpsBinaryIdpChannel"/>
      <add scheme="https" binding="customBinding" bindingConfiguration="HttpsBinaryWindowsChannel"/>
      <add scheme="https" binding="basicHttpBinding" bindingConfiguration="BasicHttp" />
      <remove scheme="http" />
      <remove scheme="https" />

You can have both protocols enabled at the server. The .sysconfig at the client chooses which one to use.

<EndpointBinding value="UsernameSslChannel" options="HttpsBinaryUsernameChannel|HttpsBinaryWindowsChannel|HttpsOffloadBinaryUserNameChannel|HttpsBinaryAzureChannel|HttpsOffloadBinaryAzureChannel|HttpsBinaryIdpChannel|HttpsOffloadBinaryIdpChannel|HttpBinaryUsernameSslChannel|UsernameSslChannel|Windows|UsernameWindowsChannel" />

I use “HttpsBinaryUsernameSslChannel” to have the client use SSL here on K2021.2.

While I can neither confirm nor deny the use of Tailscale for our solution… I will say that there are some features in Tailscale that allow you to limit that splash damage that Mark is talking about. We have not done anything special to Epicor… sorry Kinetic… to have it functional over our chosen VPN. 100% about making sure you are using HTTPS as your endpoint though. NET.TCP is such a PITA.

One thing I will add. Any MFA solution worth its salt does not give you JUST a Approve/Deny flag anymore. It requires some kind of matching. For example our MFA displays a three digit key you have to enter on your cell phone to approve the connection.

1 Like