hey folks. You may scrap most of the above. The firewall rule way does work..sortof. AOL still proxies everything via its own means. Any ideas how to make AOL use openDNS? I'm starting to think it's not possible :( Cheers

When you are talking about NAT in this post you mean if someone need access to a computer behind the firewall in some cases? I just see that you say it on LAN and DMZ interface

You need to provide a LOT more information. What steps did you take. How do you test that something "doesnt work". Screenshots of your rules!

Thx for your suggestions. The alias solution have been on my mind - but I was hoping that there was some kind of more "automatic" solution… As far as I know PF has a clear picture of the local network interfaces, its ip adresses and its subnets and hence I was hoping that some kind of dynamic PF table always would always reflect the local interfaces. Kind regards Uffe

@jimp: Did you read the link they gave? That is a vulnerability on Caldera OpenLinux which has nothing to do with FreeBSD, on which pfSense is based. Completely different worlds, and completely different network stacks. Not to mention that was a specific flaw in a specific version of Caldera, by SCO, and no others. It should be enough to tell them that you are not running the vulnerable platform, and that it is a false positive. I explained that in detail and they rejected my response. It's definitely a false positive. Their exact verbiage says that 'only "established" connections are allowed into the network.' I'd like to know just how connections are ever supposed to become established if you don't allow SYN packets through? I don't think this company even understands what a three-way handshake actually is. I hope pfsense 2.0 will allow us to filter on tcp flags. I can imagine other uses for this too.

I would create an alias containing all the IPs i want to block. Have a block-rule on the WAN at the top of all other rules with this alias as source.

@kalidin74: A few suggestions… 1. Create a wide open rule to ensure its nothing there. 2. If you are using a Virtual IP (strongly suggested) make sure you are using the ARP/Proxy version. 3. Create a logging rule to see if the packet is making it to the PFsense box No entries were created when I tried routing FTP requests to a specific address. Tried to allow all FTP requests to pass without a specific path, and nothing in the logs. Which tells me that my cable modem is standing in the way

Have a look at the following topic: http://forum.pfsense.org/index.php/topic,11279.msg62689/topicseen.html#msg62689 It explains how to build the aliases from a file. You would only have to write a script that pull the correct files from IPdeny every once in a while. It seems to work although I must admit that I did not get it working on my pfsense box so be carefull and make a backup first.

@bancha: Hello All, I'm test install pfsense 1.2.2 on ESX and 2 VMNICs and 2 VMNetworks for PfSense. But i'm try config bridge (transparent mode) for protect some VM on ESX.It's can't ping out to any ip.(Policy any to any both LAN and WAN Rules) Anybody can run and work with bridge mode on ESX environment? for My diagram that i'm test as show in attach file. Thanks,  ??? ??? ??? Wait for all updates, Bancha. No one can help me??

Ugh, my stupidity. Sometimes you cant see the forest for the trees… So it turns out that on my iperf test node, the return route went through another gateway instead of the pfSense firewall. Once I set a static route back through the firewall (I thought I had..), the states are now maintained and connections are good. Thanks for the help!

@GruensFroeschli: PING server1.xxxx.se (81.201.219.xxx) from 81.170.214.xxx: 56 data bytes 36 bytes from h-214-226.A163.corp.xxx.se (81.170.214.xxx): Communication prohibited by filter Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst 4  5  00 5400 ab4d   0 0000  3f  01 7b03 81.170.214.xxx  81.201.219.xx Isnt the bold part a response from the router blocking your ping? Seems to me like your ISP is blocking it. I just tested whit the other router/fw whit the same ips and that worked just fine.

Would I then set up the firewall rules for the POS interface to be Block    Interface:POS  Source:Any    Destination:LAN subnet Allow    Interface:POS  Source:Any    Destination:WAN ??

Glad it helped. It is basically what Perry said before only with different weapons. The last 'deny the rest' is there automatically. I like to have it as separate rule to not forget about it.  ;)

You're welcme :) I'm glad it was such an easy fix!