Different firewall rules for different OpenVPN servers (on single pfSense)
-
Yes, I thought it might have been an Interface Group, but I was stumped when OpenVPN didn't show up under the Interfaces > Interface Groups.
I had also considered assigning each instance to it's own Interface (under Interfaces > assign), but second-guessed myself about having to enter an IP address for each Interface. Would I just assign the first IP address of the tunnel network configured in the OpenVPN configuration? For example, if my site-to-site uses a tunnel network of 10.0.8.0, I'm guessing I should just assign 10.0.8.1 to the Interface IP?
(perhaps this should be under the OpenVPN category?)
-
No need to assign an IP to the interface at all. Just assign the interface to the ovpns(x) port, give it a name, and save the config.
The OpenVPN server instance already has the IP assigned from the vpn config so no need to add one for the interface.
-
As I mentioned, just enable the interfaces, the description is optional and do not make other settings here.
The IP is managed by OpenVPN. -
Got it, thanks Viragomann. I missed the "no other settings to be made here" part.
Out of interest, you mention that it shouldn't be necessary for me to require different interfaces - I'm open to a different approach, if you could elaborate..?
-
You can just put the rules on the OpenVPN group tab using the appropriate tunnel networks and remote networks as the source addresses.
-
Ah, that makes sense - mostly. But I'm not understanding the purpose of the tunnel vs remote networks.
My site-to-site has a tunnel net and a remote net defined.
My site-to-client only has a tunnel net defined.
Am I correct in thinking that if I want to define a firewall rule, that I should use Source = remote-net for the site-to-site link, and Source = tunnel-net for the site-to-client link?
-
Yes, that's correct.
The source in the rules has to be that IP (range) which the firewall sees when packet come in.
On the remote access server, clients get an IP of the tunnel network. So incoming packets has a source address in the tunnel network.
On a site-to-site, the packets come in with a source address from the remote LAN (without doing NAT). The tunnel network is only a transfer network here. -
Perfect, exactly what I was thinking.
I think I'll avoid separate interfaces, and just identify by the IP range, as it seems fairly clean for only a couple of OpenVPN instances.
-
I don't mean to revive an old thread, but there is a very good security reason to have the VPN instances on their own firewall interface. From a security perspective, you want each VPN instance to have a DROP ALL rule for anything you don't expect that specific interface to have. By sharing a single interface, there are rules for VPN-A that you don't want applied to VPN-B connections. For the most part there is minimal risk because any packets that get through this way would have no route back, however, carefully crafted packets by a skilled attacker could still do significant damage.
tl;dr If your goal is security, all instances should have their own interface and only allow what is needed and drop the rest.
-
I don't mean to revive an old thread, but there is a very good security reason to have the VPN instances on their own firewall interface. From a security perspective, you want each VPN instance to have a DROP ALL rule for anything you don't expect that specific interface to have.
But it seems like most of the OVPN Gurus here, says : Create the IF if needed , but DO NOT put any rules on/in it.
I do agree with your statement above, but it would only be feasible IF it doesnt FSCK up the way OVPN is intended to function on pfsense.
I'm a OVPN newbie my self, and would like to know if it is possible to put (more specific) rules on the logical tunne interface.
Or if that would mess with the already defined OpenVPN interface group rules./Bingo
-
The OpenVPN tab is really just an interface group for all OpenVPN instances. Rules there are processed before the rules on any specific assigned interface tab (all interface group rules are processed before dedicated interface rules).
Actually, the advice I generally give is if you use assigned interfaces, don't put any rules on the OpenVPN group tab and exclusively use the assigned interface tabs. There are probably a number of people who don't know what they are doing, and should have probably hired someone to set up their network,Ā who have both an OpenVPN server defined (technically a LAN) and a connection to a VPN provider (technically a WAN) with pass any any any on the OpenVPN tab.
One can also rely somewhat on OpenVPN itself to not process traffic inbound from a connection with a source address that is not either the connection's tunnel address or any defined remote networks. Of course that is not the same as firewalling. That is probably only effective in server mode, though, thinking about it.
If your threat model does not trust your OpenVPN connections, then the ability to assign interfaces to each instance exists, with a default deny any rule on each of them.
-
I have created interfaces for each openvpn service on my central server for firewalling.
I have 6 separate services running.
One is a tap and as such is part of a bridge to the LAN, do the firewalls apply the same?
I also have an OpenVPN connection from an OPENWRT, this is a little tricky when you don't want clients to client connectivity. I assume I need to create rules for this, as the 'checkbox' does not work for this scenario -
The firewall rules on your bridge will be governed by these
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0sysctls like all bridges. To be honest I do not know how an interface group rule operates on a bridge but I would anticipate it being the same as any other interface.
-
Okay, thanks for the tip. I will have a look at how this changes my firewall behaviour.
