How did I RUIN my OpenVPN setup?

  • I had OpenVPN all setup. Employees were simply installing OpenVPN 2.3 and copying the fw01-udp-1194 folder from into their config directory and the rest was as sweet as rock-n-roll.

    I setup the CA, and then a CERT for CompanyVPN.
    I then setup an LDAP server and verified it from the Authentication page in the Diagnostics menu.
    I setup OpenVPN using the wizard using LDAP. Exported the config and all was well.
    I was in. The boss was in. Co-workers were getting in.

    I then went to begin working on a VLAN. I went to the Interface menu, chose assign, went to the VLAN tab and entered the info. Since there were no interfaces showing, I clicked on the + sign. IMMEDIATELY I had a new interface called OpenVPN that I had never seen before and ZOIKS!!! CompanyVPN was listed as the interface for OPT2. I quickly changed it to the new VLAN and hit save.

    I was at home, on the VLAN at the time. I lost my ability to touch anything. I can still log in, but I cannot ping, cannot access files, cannot hit the internal web servers.

    I drove in and changed the interface back to CompanyVPN and then added OPT3 and assigned it to the VLAN. Save. Nada.
    I deleted the definition of the VLAN, then deleted the OPT3 interface. Save. Nada.

    If I can connect but cannot pass any traffic, perhaps it is a rule?! Whoa! Now I have an OpenVPN tab in the rules section with all of the removed attempts at creating the VPN listed. I whack all those old rules leaving only the last one. Save. Nada.
    I looked into the WAN interface and there at the bottom is the rule created by the wizard, untouched.

    So is this an Interface issue, or a Rule issue? What do I have to do to restore the VPN?

  • Rebel Alliance Developer Netgate

    When you add an interface, the system automatically picks the next one in the list. Just bad luck that it grabbed your VPN interface, because if the system touches the VPN interface in that way, OpenVPN must restart before it will pass traffic. Just edit/save the VPN instance or restart from Status > Services.

    It's never a good idea to manage interfaces remotely if you can help it, especially over a VPN if you don't have another way in.

    If OpenVPN is enabled, you will have an OpenVPN tab for the OpenVPN rules.

    As for that other LDAP issue you mentioned over e-mail, that's probably from the OpenVPN wizard caching data from the previous wizard run. It probably just needs to ignore all of the previous run since that could potentially end up causing issues with duplicated certificates as well.

  • Thank you.

    I restarted the OpenVPN service. But was unable to pass traffic. I can connect without a problem.

    Should there be an Interface assigned to "ovpns1 (CompanyVPN)" as OPT2?

    In all my reading, I've not seen that done. I had deleted that interface, along with the VLAN definition and the VLAN interface. When I did, I assume that the only remaining (and apparently valid) rule left in the OpenVPN tab, was also deleted.

    I added a rule back, UDP traffic from any to any. (That only sounds kosher because traffic is going through the VPN and you already had to be authenticated as well as have the proper cert.) I then restarted OpenVPN again. Still cannot ping through.

  • Rebel Alliance Developer Netgate

    You can assign an interface to the VPN if you want, but it is not required. With or without the interface assignment, you still need rules on the OpenVPN tab or assigned interface tab.

    Rules would never be automatically deleted, but if they were on an assigned interface, they wouldn't be active once that interface was removed. The OpenVPN tab itself is always there so long as any OpenVPN client or server is defined.

    Remove the assigned VPN interface, edit/save the VPN instance, make sure you have rules on the OpenVPN tab to pass any traffic ('any' protocol there, not just UDP), etc. Your WAN rule just needs to pass traffic UDP to the wan address on the port where the server listens.

  • Just saw it. The rule in OpenVPN that I added back was only for UDP.

    I had tried a traceroute and then an nslookup. NSlookup worked, UDP.
    Changed the rule to TCP/UDP and we are back.

    Thanks again.

Log in to reply