OpenVPN Client configuration in Snapshot 06-09-21 and previous


  • Rebel Alliance Moderator

    Hi guys,

    just made an update of our WRAP here at the company location to Scott's latest Snapshot. Was using 14-09-06 earlier but had the same problem: OpenVPN configured as "Client" wouldn't connect to our OpenVPN machine in the IP Center. After manually reconfiguring the client configuration it worked like charme but after the update it failed again. I now figured out why. pfSense translates the remote IP and port to a statement like:

    remote %ip.ad.re.ss% %port%
    

    That may be ok (although I don't know it exactly) but it doesn't work (for us). If I rewrite it to

    remote %ip.ad.re.ss%
    port %port%
    

    both parts of the VPN tunnels happily find each other and start to communicate :) I don't know what causes this (as the port statement is an old one) but perhaps you've got some answer in your pockets ;)

    Greets
    Grey



  • remote 
    

    and

    remote <host>port</host> 
    

    are two different things. From the OpenVPN manual (emphasis added):

    @OpenVPN:

    –remote host [port]
        Remote host name or IP address. On the client, multiple –remote options may be specified for redundancy, each referring to a different OpenVPN server.

    [snip]

    –port port
        TCP/UDP port number for both local and remote. The current default of 1194 represents the official IANA port number assignment for OpenVPN and has been used since version 2.0-beta17. Previous versions used port 5000 as the default.

    In other words, when you specify "remote <host><port>", you're saying "connect to host <host>on port <port>", whereas when you say "remote <host>" and "port <port>", you're saying "connect to host <host>on port <port>from port <port>".

    In OpenVPN client mode, the client is assumed to connect from a random client port, and maybe your server is failing to realize that.</port></port></host></port></host></port></host></port></host>


  • Rebel Alliance Moderator

    Ah didn't figure that out - must be missing the "both" keyword in the "ports" keyword description. Thanks for pointing out. Yeah, right, the tunnel is supposed to be established between the two devices on the same port on both ends, as that makes maintaining the firewall ports easier and more transparent.


Log in to reply