When you create a new rule(s), you need to reset the state table to clear connections already established. Then the rule should take effect and it should be blocked.

The Status > Interface was showing collision errors on the OPT1 and OPT2 interfaces that make up the bridge. The bridge interfaces were set to Default (no preference, typically auto-select) on the interface setting. On the Status > Interface it was showing 100 half duplex. Changed the interface to match of 100baseTX and rebooted the box. Once back ran test and still low throughput and the Status > Interfaces still show collisions.[image: 1576869774853-2019-12-20-14_18_19-window.png]

No problem, only took a couple of minutes to validate ;) I was pretty sure without doing it - but always good to be "extra" sure.. Again though in the big picture not really an issue anyway if you ask me.. I turned bogon and rfc back off once I validated ;)

Use a traffic shaper to limit downloads/uploads: https://docs.netgate.com/pfsense/en/latest/trafficshaper/index.html

@bcruze said in Force/Redirect DNS queries to 8.8.8.8 to another DNS server (internal or external): i do this with several devices on my network. create static mappings for the devices find the device under services > DHCP server > at the bottom of the page edit the properties of the device > under DNS servers. add which ever DNS server you want. then apply/ apply. and reboot the device This has no effect on hardcoded DNS servers. You should use nat with redirection

In my case we have users who work remotely via VPN who whall get the same filters as those who work locally.

@kiokoman Thank you for your assistance!

You don't need to setup a lot of deny rules... It can be done with 1.. Are you trying to connect from your mobile phone to your vpn from your own internal wifi network? For why? Is your own internal network hostile?? Mobile phone on their cell network sure ok - that rule would be on your wan not your lan.. Not sure where there is to play with with chromecast - its L2, its not going to talk to pfsense in anyway at all.. Clicking and making rules without any idea of how they work isn't going to get you anywhere! ;) The raktar_kaputelefon to Mobilevoipclients - not sure what that is suppose to do? The only source on your mobile wifi could be IPs on your mobilewifi, and then I assume mobile voip clients are also on this mobile wifi network - traffic between devices on the same network, ie mobile wifi would not even touch pfsense - so how would that rule come into play?

I have done some testing since my original post, and have managed to reproduce the aforementioned behaviour. When I enable an unrelated firewall rule - one which was temporarily switched off in order to close unused ports - the metered traffic for the firewall rule on port 9987 is, for whatever reason, reset. Any states which were active upon resetting no longer contribute to the traffic total for that firewall rule. Strangely enough, this only appears to affect a couple of the many firewall rules I have in place - i.e. only a couple of them have their cumulative traffic reset. This leads me to think that this behaviour is unintended. Is anybody able to shed some light on this?

OK it isn't my router. I setup a VPN and everything works fine via the VPN. I filed a ticket with my ISP. thanks for listening, david

@rajbps sure: https://docs.netgate.com/pfsense/en/latest/book/firewall/aliases.html URL Aliases With a URL type alias, a URL is set which points to a text file that contains a list of entries. Multiple URLs may be entered. When Save is clicked, up to 3,000 entries from each URL are read from the file and imported into a network type alias. If URL (IPs) is selected, then the URLs must contain IP address or CIDR masked network entries, and the firewall creates a network type alias from the contents. If URL (Ports) is selected, then the URL must contain only port numbers or ranges, and the firewall creates a port type alias from the contents. URL Table Aliases A URL Table alias behaves in a significantly different way than the URL alias. For starters, it does not import the contents of the file into a normal alias. It downloads the contents of the file into a special location on the firewall and uses the contents for what is called a persist table, also known as a file-based alias. The full contents of the alias are not directly editable in the GUI, but can be viewed in the Tables viewer (See Viewing the Contents of Tables). For a URL Table alias, the drop-down list after the / controls how many days must pass before the contents of the alias are re-fetched from the stored URL by the firewall. When the time comes, the alias contents will be updated overnight by a script which re-fetches the data. URL Table aliases can be quite large, containing many thousands of entries. Some customers use them to hold lists of all IP blocks in a given country or region, which can easily surpass 40,000 entries. The pfBlocker package uses this type of alias when handling country lists and other similar actions. Currently, URL Table aliases are not capable of being nested. If URL Table (IPs) is selected, then the URLs must contain IP address or CIDR masked network entries, and the firewall creates a network type alias from the contents. If URL Table (Ports) is selected, then the URL must contain only port numbers or ranges, and the firewall creates a port type alias from the contents.

Set Type to Network, not Host. Then using CIDR notation is just the three entries you listed.

@johnpoz Well...the only scenario I could think of is a virus or malicious software sitting on the lan and using bogon addresses LOL....Ok, I removed that rule. It should only be set on the WAN

I don't see what other way ... here is a diagram: [image: 1575990060683-untitled-diagram.png] All the devices connected to the wifi get IP from the VLAN 51 where that standalone DHCP is running. In the pfsense logs I get this kind of messages: DHCPREQUEST for 192.168.51.120 (192.168.30.1) from aa:aa:aa:aa:aa:aa via igb1: wrong network.

@flow544 said in Snort with bridge: My PFSENSE is configured in bridge mode Do you realize that mode defeats your pfSense box!

That is very true... Would for sure check there first before having to setup a sniff ;)

Usually that means that some other commit that happened before it needs to also be applied. It might be a new form field, something else that changed nearby, etc. Since the failure is in usr/local/www/services_dyndns_edit.php then there must be a commit that happened on that file after 2.4.4-RELEASE-p3 but before the patch you're trying to apply. Looking at the history, there were a number of changes to that file from PRs for various DynDNS changes. You could hand edit out just the part of the patch that is touching that file.