nope not working anymore

@Gob: now there's lateral thinking! Sure. It would get boring otherwise, wouldn't it?  ;-) 1. allow MAC OS 2. allow Windows 3. deny the rest How about that? Rules out iPhones as we just learned. But I'm sure you come up with some VAXes or other uncommon gear and it doesn't work this way. Anyone surfing with a PSP?   ;-)))

One is probably the console (keyboard/video, or serial) logged in and sitting at the menu. The other is probably the interactive session you're using.

It could be like you mentioned where it gets to the UPNP process on the firewall before reaching the firewall rules. I just tried creating a block rule for 2189 and I can still get to the UPNP process.

Only option I can think of is send all internet traffic through the proxy and bypass proxy for some sites. In Squid disable transparent proxy. In "Internet Explorer"(not sure if other browsers supports this) > Options > Connections > Lan settings : set proxy address x.x.x.x port 3128. Under "advanced" you can add addresses that will not use the proxy server. Hope this helps

It is exactly the brute force (crawl through) attacks I'm trying to prevent.  Anyone with any sort of services on the internet who scan logs knows that the brute force attacks are the major traffic inflows to many of them.  This has nothing to do with if you are famous or not as a bot army doesn't care one bit.  It just knows there is a service and knows that it  might get lucky.  Also it doesn't take long looking at the logs to understand the bot armies are fairly coordinated in their attacks in how they go about guessing.  Doing things such as limiting the number of wrong guess before shutting down the service helps but the armies are relentless. Security should be a multi-layer approach and one layer of that approach should be to limit who can get to your front door.  The concept of "false sense of security" doesn't apply since by definition if as service is on the internet it is unsecured.  There are several other threads in this forum that talk about adding the entire China and Korea net blocks to the deny list.  Doing Geographic DNS blocking takes that approach several more steps.  Yes it requires more maintenance then not having this layer at all but I see this much less maintenance than manually maintain a small allow list or trying to somehow fill up a huge deny list.  Other threads have talked about an option in the filter list per country.  I would be happy with that option as well. For my ssl servers the multi-layer approach includes implementing denyhosts (http://denyhosts.sourceforge.net/faq.html) as well as possibly not using port 22, possibly turning off password authentication, forcing long passwords, frequent passwords changing, etc depending upon what I'm trying to protect. The geographic DNS interests me for use in PPTP and any of the other very few tunnels I might allow in. Though it would be great for ssh as well.  PFsense PPTP client doesn't try to prevent brute force attacks so adding this layer would greatly reduce the number of attacks.  In one of my networks I have a multi-routed ActiveDirectory network being served  behind a pfsense server and pfsense's PPTP server doesn't play very nice in this situational.  It looks like I'll be (trembling to even write this) be using Microsoft built in PPTP server and I wanted an extra layer of protection before exposing the entire internet to the PPTP server. I would love to go to 2 factor authentication as one of my layers of security but that is should be a subject of a different thread. So back to my question.  Am I dreaming if this is something that only I think is an important layer of protection.  I see this as a something special that pfsense could offer that is either not being offered by the commercial vendors or is very pricey.

You may want to look at the SpamD package, works like a charm for me.

Remove squid or configure squid to deny all HTTP traffic via Access Control.

what, so now that there are paid support services, nobody can seem to help out on this forum any more?

Ok thanks.

You do not need to allow DNS. Just use your pfSense Box as an dns forwarder…

Upgrade to 1.2.3 release.

I think you can use traffic shaper and squid. Check their features. Good luck jigp

Hi. To block website, use squid. Once installed, you can play with blocking sites at access control. jigp

Ok, good, sort of, it doesn't indicate any problems in itself then. Thanx,

@mavsol: Is is possible to patch or configure the system to see the rule name in web log? This is very useful when traffic is blocked that you think shouldn't be. Unfortunately, the only reference to the rule in the pf log is the rule number, and since this number can change (as the poster before me guessed correctly), it's not 100% reliable. There's no easy way to capture this when it's actually logged either.

Howdy all! This may be an old thread but was recently passed my way in an email of somebody reporting the exact same problem. (Who found it on google for "204.11.51.59" I suspect) So I figured I'd chime in on it! I can't speak for all of the IPs, but as far as 204.11.51.59, 208.78.169.234 and 208.78.169.236 go, these are F5 BigIP load balancers. Specifically Global Traffic Managers (GTMs).  The GTMs do their best to find the fastest datacenter to serve you content from, their preferred method (which may not be perfect, but works pretty well) is to send a DNS_DOT query to your DNS server. Unfortunately this is often classified as the aforementioned attack. All the GTMs are using from this query is the response time, no other information is gleaned (or stored) from the probed DNS server. The load balancers at those IPs serve some high profile sites and the marketing content for countless more, so triggering a probe from them is pretty common. Realistically blocking traffic from them will result in sites being slow and/or unavailable. Hope this helps clear up any confusion anyone has. F5 has a knowledge base article regarding it (though it is admittedly behind their support wall), which I have quoted below. Cheers, Nick (at FederatedMedia dot Net if anyone would like to reach me) SOL6480: LDNS probing may appear to be an attack ( https://support.f5.com/kb/en-us/solutions/public/6000/400/sol6480.html ) When a client or a local DNS server direct a DNS request to the BIG-IP GTM, the BIG-IP GTM attempts to probe the local DNS server to obtain path metrics. In addition, all other F5 Networks devices that are equipped with a big3d agent and are included in the configuration will probe the local DNS server. The metric information collected by the big3d agents is used to make wide area load balancing decisions based on network conditions between the big3d agent and the local DNS server. By default, big3d agents first attempt to probe the local DNS with a DNS_DOT query. If the probe attempt fails, big3d attempts the following tasks, in the following order: DNS_REV query UDP echo TCP port 53 socket connection ping (ICMP echo) Attackers commonly use similar probing techniques when looking for security vulnerabilities. Therefore, the BIG-IP GTM probing may appear to be an attack or a prelude to an attack and may be reported by intrusion detection systems. Administrators that have noticed the BIG-IP GTM probing generally report the following symptoms: Local DNS servers are being excessively pinged by the source addresses of F5 Networks devices. Border routers are intercepting an unusual number of pings from the source addresses of F5 Networks devices. Unusually large numbers of attempted connections to TCP or UDP port 53 appear to be an attack. Unusual methods are used to query a DNS server (DNS_REV or DNS_DOT). The path metrics provided by the BIG-IP GTM probing are required to make dynamic load balancing decisions.

Thanks guys. Those suggestions worked great.

There is a FAQ that explains the best way to setup wifi AP. http://doc.pfsense.org/index.php/Use_an_existing_wireless_router_with_pfSense That is the best solution. Now if you are trying to access a single device from one network to the other network then you should create an alias for that device, ie 'dlink', and then firewall pass rule to pass LAN traffic to OPT1: [ * | LAN net | * | dlink | ] and vice verses on OPT1: . This should give any PC on the LAN side access to your dlink. Basic MANY to ONE. Now for MANY to MANY you wont need to set up any aliases just striaght firewall rules pointing LAN subnet to OPT1 subnet. LAN: [*|LAN net|*|OPT1 net|*], OPT1: [*|OPT1 net|*|LAN net|*]. This should allow all traffic in both directions. and last the ONE to ONE. whereby you would create two aliases one for a 'PC' and one for 'dlink' and then create firewall pass rule to pass PC traffic to dlink: [ * | PC | * | dlink | *] and vice verses on OPT1:* . This should allow access from your PC to your dlink ONLY and should not pass anyother traffic from LAN to OPT1.