Damascene, in that case you should be able to run a packet capture on that interface and find the MAC address of the device which is sending these multicast packets. Andreas

look this: http://doc.pfsense.org/index.php/SquidGuard_package#Block_download_by_Extension []`s Jack

take a look on anti-lock rule on lan. seems you need just a simple rule on lan interface. If your cups is listening only on localhost, then create a nat from lan to 127.0.0.1:631

Edit your first post subject field with [SOLVED]

Your biggest issue is that is that your source port is not any. You will have the same problem if you did the same in NAT.

Hi there, Yep is an optional interface, but no blocking private IP's. I think CMB is on the right lines, but need to do some wireshark packet captures to try and discover what is going on, but not back in the office till the New Year so will come back then. J

I do it DHCP reservation and then IP block. I only do this for test for like it was just said, you can change a MAC about as easy as you can change an IP. But search and be amazed at what you find.

Seeing a blocked ACK packet means the firewall is only seeing the return traffic, and not the traffic coming in. From that, it sounds like you may have some asymmetric routing happening that is causing the firewall to only see half the traffic.

CMB, Thanks.  I had TCP/UDP on the inbound but only had TCP on the outbound.  Its working now.

Just depends on how comfortable you are with how the rules work and how paranoid you are. With the way you are describing johnpoz, those would be the only servers on the network. If that is the case, then it works well. If you have 100s of servers, not so much, especially if it is only the 2 you have to block for and the rest should be open. It is safer to deny all, but generally speaking, you are only doing that to stop virus or malware spread. Once in the network, it can attack other servers there with no concern with your firewall. Another way is to utilize per server firewalls. Either way, have fun …

You're creating a mess there with trying to statefully firewall asymmetrically routed traffic (with any firewall), you can't add rules to allow that. Firewalls must see both directions to be able to properly filter. No idea why you would want to have that kind of setup, so not sure on what alternative to suggest that's sane.

Won't touch it at the application level, short of some options with reverse proxies in packages that are uncommon. Nothing like what TMG does by default, that's definitely not your issue.

@Metu69salemi: JIMP already said the solution, but as i expected your wan rules isn't allowing even a thing to happen. You could add there a rule that allows management for that pfsense. You should do this before creation of lan, if you really don't want to have management access only in lan side. Action: pass Disabled: unchecked Interface: WAN Protocol: TCP Source: you should determine your wanted ip or any Source port: leave it as is Destination: wan ip Destination port: management port #(could be 80, 443 or what ever you have set) Log: unchecked(usually this would be good trafic to log) Description: something descritive, like firewall management And click save. thanks all. I got it

I am convinced  :)

If you provide a sample of the rules, perhaps someone here can help translate those into firewall rules that can persist past upgrades.

What is odd it that I assumed anything in the 10.x.x.x range was reserved for private subnets. Many cable companies use ip's in these subnets to administer the actual modems.  Quite normal.

Thanks, that was exactly what I was looking for.  Cheers.

Hello all: This is my first post. I have put many hours into attempting to setup the shaper on  2.0. Perhaps it's because I'm a Linux guy, but I can't get my mind around how this shaper config works. No matter what combination I try, I can't get l7 profiles to work. It either completely stops throughput, puts all traffic in the specified queue simply because it's the last floating rule, or has no effect at all. So I think what would help is if somebody can answer the following: 1. Is it better to put l7 in floating, or does it matter? 2. In floating rules what exactly does "Choose on which interface packets must come in to match this rule." mean? Because I have had more luck selecting the iface packets go out from, not in? Is it a typo? 3. Associated to question 2…what does the direction selector do? It seems ambiguous since the option above it is the interface packets "come in" on, implying that the rule only applies to inbound packets anyway. 4. In the advanced section: are they match criteria, or directives? If I specify an l7 profile/container, does that mean it's a criteria to match or is it forcing the box to treat traffic specified in the rule as such data? 5. When creating a rule with a l7 container, should we specify a queue or does the l7 container queue action do that without a specified queue in the rule? 6. The queues themselves are all created with the same names for each iface even though they are separate queues, is there logic in the box to know which queue to use, or is it up to us to change the names after the wizard is run? 7. When specifying an ack queue in a rule, I noticed that unless I specify an ack queue on the same iface, the ack traffic seems to actually go to the default queue on that iface rather than the specified WAN ack queue. Why would the ack queue be on the internal iface instead of the external iface for WAN data? TIA Rick

Yes it works