Using pfSense 2.5.0. I have (I think) a firewall question. I’ve watched both of Tom’s videos (several times) and read pfSense and PIA instructions. I have several subnets, but for simplicity I’ll focus on two: a computers subnet and an audio/visual subnet (e.g., Roku, TVs). My objective is to have traffic from the computers net go through the PIA VPN, but not traffic from the A/V net. I don’t want a kill switch rule; if the VPN is down, I want traffic routed through the WAN.
I created an outbound NAT rule only for the computers network. I have rules on buth the OpenVPN and PIA interfaces to, in order, send traffic from the computers net to the PIA gateway and all other traffic to the normal WAN gateway. I have rules for my computer net to, in order, send traffic to the PIA gateway and then to the WAN gateway. I’ve modified the “default allow” rule for my A/V net to specifiy the WAN gateway. I’ve experimented with the “Don’t pull routing” option in the OpenVPN client definition. With that option enabled, no traffic goes through the VPN. With the option disabled, all traffic goes through the VPN. It is enabled and I’m having trouble getting to Amazon Prime video on Roku.
I expect that there is a straightforward way to set firewall rules to accomplish my objectives, but after much experimenting, I haven’t found it. Any help would be appreciated.
Rules match from the top down so you should be able to put a rule matching traffic from a device above the rule that sends traffic out of the VPN. The rule would need to have the source IP of the device or create an alias list of the devices.
Tom, thanks for your very quick response. I’m using two aliases for the sources in these firewall rules, one for networks that I want to go out over WAN and the other for networks to go over VPN. You referred to host IP addresses, but I assume that using whole (or even multiple) subnets as the source should work as well.
These rules are in the OpenVPN and PIA interfaces. I did reverse the order, so that the WAN rule is above the VPN rule. The appropriate gateways are assigned in the advanced sections. I’ve modified the default allow rule in the Audio Visual network interface to specifiy the WAN gateway. Still, the public IP address of that network is a PIA address.
Also, I’m confused by the fact that I added outbound NAT rules for OpenVPN only for the networks I want to go through the VPN, but all nets are going there. I enabled the “Don’t pull routing” option in the OpenVPN client defintion, again. That causes nothing to go throught the VPN, and when I disable it again, everything goes through the VPN.
Maybe there’s no other advice you can provide, but I thought I’d let you know what I’ve found here.
Been a while since I have setup PIA and policy routing as it is not something that business use. I do plan to revisit the issue now that pfsense 2.5 is out but until then you might want to try https://forum.netgate.com/ for some more up to date information on policy routing.
Hello,
I have a similar setup on my pfSense box where I only send my .200 VLAN out the PIA VPN interface and all my other traffic goes out my ISP gateway. Yes uncheck the ‘Don’t pull routes’ option in the VPN client setup.
Here’s a screenshot of my outbound NAT rule. I chose to use the ‘Hybrid Outbound NAT’ option so I can let the automatically generated rules do their thing.
Hope this helps…
Thanks, azdeltawye. I did change the interfaces on my outbound NAT rule from the OpenVPN interface to the PIA_VPN interface. I also unchecked “Don’t pull routes” option in the OpenVPN client definition. Still, either all of the subnets are routed through PIA with the option unchecked or none of them are routed through PIA with the option checked.
The result is the same with the NAT Outbound rules set to Hybrid or to Manual, or with the Outbound interface set to OpenVPN or to PIA_VPN.
Maybe the issue is with the firewall rules on the subnet interfaces I’m trying to control. Can you give me an example of the rule you use on the .200 network to force internet traffic to use the PIA_VPN interface? My rule just specifies the source as the computer network, and then specifies the PIA_VPN as the gateway in the advanced settings. This is similar to my default allow rule, which follows and specifies the WAN. I’ve also tried a rule for traffic destined to the virtual IP of the PIA tunnel. None of the rules for this network are blocking rules. I do have a pass port 53 rule above the these other rules.
Tom and azdeltawye,
I thought you’d both be interested to know that I’ve got things working as I want. The key was to reboot pfSense, a lesson I’d learned once before but had forgotten.
Glad you got it working! Strange because I did not have to reboot pfSense to make it work for me…
Yes, forgot to mention, had to add the following rule to allow traffic out the PIA_VPN interface.
Tom
Again thanks for your excellent vidoes on pfSense. I had to reboot multiple times to get the policy routing over VPN to work. And when I tried to change policies, things would go haywire.
I’d been getting the following notice on pfSense since I started using it a couple of months ago: “There were error(s) loading the rules: /tmp/rules.debug:28: cannot define table bogonsv6: Cannot allocate memory” Apparently, that interferes with reloading the rules frequently but not always.
I finally chased it down on the Netgate forums. The default setting for “Firewall Maximum Table Entries” in “System->Advanced->Firewall & Nat” is 400K. Apparently, the “bogonsv6” table is getting very large, so there’s not enough space to update that table. Someone from Netgate suggested setting the value to at least one million.
You indicated above that you might update your pfSense/OpenVPN video to cover pfSense 2.5.x. And I think you’ve indicated on the channel that you might update your loading pfSense from scratch video to the current version, as well. You might consider increasing the default value for maximum table entries in either video update. I think it would have saved a lot of headache for me if I’d done that first.
Yup, lots of new videos to make and changes for sure. 