Question about OpenVPN firewall rules

  • I am running both an OpenVPN client (connecting to PIA) and OpenVPN server (UDP and TCP) on my pfsense device. I was double checking my settings and I noticed that under Firewall: Rules: OpenVPN, I have "pass any" rules that were put there by the OpenVPN Remote Access Wizard.

    I just wanted to check that these rules are ok in this situation.  Would they somehow allow someone to be able to access my LAN through the PIA gateway?

  • LAYER 8 Netgate

    If you are using PIA there must also be an OpenVPN assigned interface so you can perform outbound NAT. That will be the tab that governs what happens when traffic arrives at your firewall into the PIA connection. (Actually I'm not exactly sure that those rules won't pass anything into your PIA connection that manages to get there. Inbound pass any any on outside interfaces makes me nervous in general.)

    You can break certain things by having traffic coming into your firewall over OpenVPN that matches rules on the OpenVPN group tab when you actually want to perform actions based o the assigned interface tab. I generally make assigned interfaces for all servers and clients and don't put any rules on the OpenVPN tab.

  • Just to make sure I understand… You are suggesting that I create (virtual) interfaces for each of the Open VPN servers, and then delete the automatically generated pass rules from the Open VPN tab and recreate them on the tabs for each of the Open VPN server interfaces?

  • LAYER 8 Netgate

    Yes. Unless there's a reason to have all your rules on the OpenVPN group tab. In my opinion assigning interfaces is the way to go in general.

  • I followed your suggestion - created the virtual interfaces and added "pass any" rules to both of them, and deleted the 2 rules in the OpenVPN interface that I posted above.  Now although I can connect, I have not access to the internet through the VPN tunnel. What am I missing here?

    I restarted the Open VPN service and things started working again.

    Now that the base configuration is working, are there any traffic blocking rules for each of these interface tabs that you would recommend?
    The only user of the VPN is me (as the admin), and I don't mind if I have access to all my vlans over VPN.  I feel that the OpenVPN is well secured, using both certificates and user name/password, so someone else getting in that way seems very, very, very unlikely. I just want to make sure that by having "pass any" rules on these interfaces that I am not unintentionally opening up any security holes (e.g. unsolicited traffic from PIA being able to get into my network; or other devices from the host LAN being able to piggyback on my incoming Open VPN connection when I connect to the server; or some other thing I haven't though of)

  • LAYER 8 Netgate

    Only you know what traffic should pass and what should be blocked.

  • I understand that.  I am just looking for some guidance on good security practices.  Since I have no NAT rules that even mention the Open VPN server interfaces, am I right to assume that no traffic on my LAN can cross over to that interface?

    And does having a "pass any" rule on the Open VPN server interface allow traffic from outside (I mean traffic that is outside the VPN tunnel that I am using)?  Or is there no way for traffic to pass from the WAN interface to the Open VPN server interface unless I specifically allow it (which I don't think I have)?

  • LAYER 8 Netgate

    The OpenVPN rules affect traffic coming in from OpenVPN tunnels.

    Best practice is to pass only what is necessary and block everything else. So I yould have no rules on OpenVPN, no rules on PIA, and rules on the site-to-site for only the traffic necessary.

  • Great - that helps sort things out for me.  I do have not rules on OpenVPN or PIA tabs.  Although I do have pass any rules on my VPN server interface tabs, since I am the only one who can connect to the Open VPN server and generate incoming traffic on those interfaces, I don't think passing all traffic should present a problem?

Log in to reply