<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Do snort and pfBlockerNG need to be pointed at secondary interfaces?]]></title><description><![CDATA[<p dir="auto">First time poster. Glad to be here.</p>
<p dir="auto">I've been using pfSense for about a year as my main router / firewall. I feel good about it. Thank you for making it available.</p>
<p dir="auto">My question: I'm using OpenVPN with a TAP interface so I can bridge into my home network from out of town. It was a little tricky to find the instructions but it works well. I had to create a new interface to make it work.</p>
<p dir="auto">I'm also using snort, pfBlockerNG, and a custom list of IP addresses to keep the bad guys out on a normal, daily basis. Snort assigned to the WAN interface. pfBlockerNG is pointed to both WAN and LAN. The custom block list is pointed to WAN.</p>
<p dir="auto">I just noticed I can create a snort instance that points to the OPENVPN-bridged interface that supports TAP. pfBlockerNG can also be pointed to other interfaces.</p>
<p dir="auto">Should I create separate instances for OpenVPN-bridged or is the one pointed to WAN and / or LAN all I need?</p>
<p dir="auto">I'm reasoning 'no' because the WAN inerface gets everything first and the bridge to OpenVPN TAP is secondary. LAN is unnecessary for OpenVPN-bridged since it is only for remote access to the home network and LAN is safe at this point. (A TUN pass through is used for remote browsing.)</p>
<p dir="auto">What do more experienced users think?</p>
]]></description><link>https://forum.netgate.com/topic/97467/do-snort-and-pfblockerng-need-to-be-pointed-at-secondary-interfaces</link><generator>RSS for Node</generator><lastBuildDate>Tue, 06 Oct 2026 09:18:16 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/97467.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 02 Apr 2016 12:47:58 GMT</pubDate><ttl>60</ttl></channel></rss>