Help to set up OpenVPN server


  • I have pfSense set up as a LAN->Multi-WAN firewall/load balancing router, with 3 WAN ports.

    I want to set up an OpenVPN server on the pfSense, so I can connect in to the network from outside (e.g. on my Android phone), and manage the internal network and pfSense.

    I have set up a server with the following settings:
    Remote Access (SSL/TLS)
    Protocol TCP
    Device mode tun
    Interface any
    Local port 1194
    TLS Authentication
    Peer certificate authority - a root certificate I created in pfSense
    DH Parameters length 1024
    Encryption algorithm AES-128-CBC (128 bit)
    Certificate depth One (Client + Server)
    Tunnel network 192.168.6.0/24
    Compression on
    Inter client on
    Duplicate connections on
    Dynamic IP on
    Address pool on

    I created firewall rules for all my WAN ports to allow TCP & UDP traffic for port 1194

    I then used the Client export wizard to download an Android ovpn file, and imported that into OpenVPN for Android

    I can use my phone to connect to the VPN via wireless from the LAN side of the network. However, most of the time I cannot use it to connect via GPRS to the WAN side.

    I get the following log entries in pfSense:

    
    Feb 18 20:32:33	openvpn[13284]: Re-using SSL/TLS context
    Feb 18 20:32:33	openvpn[13284]: LZO compression initialized
    Feb 18 20:32:33	openvpn[13284]: TCP connection established with [AF_INET]31.111.99.130:52364
    Feb 18 20:32:33	openvpn[13284]: TCPv4_SERVER link local: [undef]
    Feb 18 20:32:33	openvpn[13284]: TCPv4_SERVER link remote: [AF_INET]31.111.99.130:52364
    Feb 18 20:32:51	openvpn[13284]: 31.111.99.130:52364 Authenticate/Decrypt packet error: packet HMAC authentication failed
    Feb 18 20:32:51	openvpn[13284]: 31.111.99.130:52364 TLS Error: incoming packet authentication failed from [AF_INET]31.111.99.130:52364
    Feb 18 20:32:51	openvpn[13284]: 31.111.99.130:52364 Fatal TLS error (check_tls_errors_co), restarting
    
    

    Very occasionally it does connect via GPRS, but not usually for long enough to load the pfSense dashboard - it usually drops out, and fails as above when trying to reconnect.

    Is there anything I can do to fix this?


  • I am not sure if "ïnterface any" really works like it is imagined (I imagine that it should listen on all interfaces, but I suspect it listens on 1 determined by some scheme?).
    In multi-WAN situations, I make my OpenVPN server listen on LAN. Then I port-forward the port from each WAN IP to the LAN IP. That way, an incoming connect on any WAN gets forwarded to LAN, where the OpenVPN server is listening. It happily responds and the response gets routed back out on the WAN it came from.


  • "any" binds to *:1194 or whichever port you choose. That isn't very multi-WAN friendly, doing the port forward Phil described is the best solution for multi-WAN in most scenarios.


  • I find this advice confusing.

    With everything set up as I said, interface "any", it works fine from my laptop, connected to a different ADSL line, connecting to any of the WAN ports from outside (or, indeed, to the LAN port, if I plug it in to the LAN instead).

    I can see no reason why listening on all ports should be multi-WAN unfriendly.

    I suspect the problem is the GPRS connection, which may be flaky enough to drop the connection (and maybe change IP address). I note that you can set OpenVPN up to use UDP instead of TCP - would this make it any more resilient to dropped connections?

  • Rebel Alliance Developer Netgate

    Multi-WAN with "any" works with TCP because of how the connections are handled in TCP and pf.

    UDP does not work with "any" on Multi-WAN because OpenVPN will source the reply traffic from the IP of the interface that has the default route, so it does not return the proper path.

    Bind to one interface + port forward the rest, it works fine that way.


  • Thanks, that's clearer.

    I'll do the redirecting bit, so if I decide to change to UDP later (unlikely, but you never know) it won't bite me.