• I'm having issues setting up OpenVPN for remote access to my Home server while traveling. I have 2 servers in HA/CARP and Multi-WAN (AT&T Fiber with Static IPs & Spectrum Cable DHCP (using xtra router for this CARP). Everything is working fine, EXCEPT my remote access OpenVPN server.

    As I don't need many users connecting this way, I figured the 'localhost' with 'port forwarding' was the best option. (please correct me if I'm wrong). (I figure I'll eventually need to use DynDNS for the DHCP Cable, but I haven't got to that point yet)

    When I try to use the VIP Interface (WAN1, WAN2 or Failover interface), the OpenVPN server service doesn't start on the 2nd server/node. However, I can't really be sure about any of it. I've spent hours trying to get this to work.

    I can get basic OpenVPN remote access to work, but it just connects with the specific node WAN address, not the VIP address. I can't get the OpenVPN server to connect to the VIP address (and also fail over to 2nd node).

    1. Any thoughts on why the OpenVPN server service won't start on the 2nd server/node when I use the VIP interface?

    2. Any recommendations on configuration for this configuration?

    (I wish I could ask more pointed questions, but I'm at a bit of a loss. Any direction would be very appreciated. I'll run with anything that can be provided.


  • Alright - I was able to get it working.

    I found some other conversations on the web referencing similar issues with the OpenVPN server not starting. I was able to fix most of it by deleting the server (and associated rules, etc). Then recreating, using default values.

    Another fix was that the DynDNS did not transfer via CARP, so it was not on the 2nd node. Once I duplicated that, things started working better.

    After double-checking every setting and manually building my client config file, I was able to get it to work quite well. I'm able to fail over to either node and/or fail over to either WAN. (While i'm not 100% sure about this, the node fail over took much longer than the WAN fail-over. I think by using the port forwarding to localhost, the WANs fail-over fairly quickly.

    Outstanding items:

    1. While not intolerable, it does take quite a while for the connection to recover when switching nodes. I want to find the setting to cut down the "reset" time.

    2. More importantly, this is a problem I've always had. I'm barely breaking 500KB - 1MB/s over my OpenVPN remove access (to Home server). I originally purchased hefty hardware so my remote access back home via OpenVPN would be faster. It has made zero difference. I guess the bottleneck has to be the client (Surface Pro (i5-7300U)). Although, the Surface CPU never goes above 25-30%. The server hardware HAS helped my PIA VPN connection. I'm getting ~850MB/s over VPN on my 1GB/s fiber connection. pfSense CPU barely breaks 30-40%.

    Clearly a VPN connection from (Home) server to (PIA) server is much different than (Home) server to (mobile) workstation.

    I just thought of something. Maybe I could run a HyperV OpenVPN Server from my Surface pro, creating a site-site connection, rather than using an OpenVPN client. Sounds like overkill, but maybe it'll work. I need to find something. Remote Access to home server at ~750KB/s is just not going to cut it.

  • After this, I'm going to move this to a different thread. The topic has moved to remote/client performance.

    I did a google search. There are some other users that have had some success with various config settings.

    tun-mtu 9000

    #ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;


    sndbuf 0
    rcvbuf 0

    Along with some other settings that I didn't find helpful. I need a true remote setup where I'm on an alien WAN, at a distance. Best I can do at the moment is test on my AT&T WiFi Hotspot, which is horrible in itself. (Though most hotel WiFi is just as horrible, so...).

    Anyway, unless anyone has anything to add, I'll close this thread down. If I find out anything new/interesting, I'll start a new thread.

    Thanks for listening.

Log in to reply