HTTP blocking with different blocking groups is relatively simple to set up. HTTPS is a bit more difficult… I struggled with getting HTTPS filtering set up at our school for a couple of months toward the beginning of this school year. The way I ended up setting it up is by using the "SSL man in the middle Filtering" in the Squid3-Dev package. Unfortunately, this throws certificate errors unless you install a CA cert from pfSense. It's a pain to set up (need to install the CA cert on each individual computer), but once it's in place it works. As far as I know (unless you go the route of DNS-based filtering such as OpenDNS) there is no way to do completely transparent HTTPS filtering without needing to install a certificate on each computer. As for having different blocking groups, you can most certainly do this with Squid. (I use Squidguard here for blocking, by the way, so I'm not familiar with the blocking package used in the tutorial you linked). Under the "Groups ACL" tab you can create a new group, and set up which IP addresses it is applied to (you can do individual IPs, or whole subnets... I just do 192.168.4.0/24 to apply it to the whole .4 subnet). Hopefully that helped some... At what point are you in the setup? Have you gotten the proxy working yet for at least HTTP?

ARP reports all known MAC addresses on a given interface. Bridging is essentially like a switch, so the original MAC address of the device on a separate segment is still used. To me, this is a valid report.

Apparently I had a space at the beginning of the URL string, this was causing the error and is now working.

Thanks for the feedback. Torrenting from any machine tanks the server, I think I already mentioned that. I'll try using a different virtualization solution to see if anything changes. Thank you.

I may have found what I was looking for http://lists.pfsense.org/pipermail/list/2012-April/001952.html Looks like an established TCP connection ha a VERY long time out. So my question is what benefit does this give me? Assuming my router can handle it, how can I use this to better manage/troubleshoot/diagnose/etc? I assume there is a reason for such long time outs. I think I read before that idle connections will get evicted if the state table starts getting full, so these states shouldn't hurt anything. Thanks!

Which aspect does it negate? The Windows 7 OS would not have connectivity. You are simply using the Windows driver to establish a layer2 connection via wifi. As long as you've removed IPv4 and IPv6 from the NIC then there will be no layer3 connection. You may want to remove any other layer3 protocols like netbios etc. The problem might be that the Windows wireless connection manager tries to establish an IP connection and then freaks out when it can't. You can probably do it manually in the driver properties if that's the case. It shouldn't do though because you can connect to wifi network that doesn't have a DHCP server. In that case you can connect but have no IP connectivity unless you set a static IP. Steve

Alright. I'm sorry I didn't keep you updated on this, but the problem was that the operating system was corrupt. All I did was a quick reinstall and that got the job done.

Thankyou!! You solved a major issue for me!

when adding a website to the allow list, you need to click save. and after go the page of the Squad and click apply always click APPLY

Yes rogue dhcp servers can be a huge PIA!  ;) Another user here experienced a similar thing except that the rogue server turned out to be an mobile hotspot application running on an iPhone. The user who's phone it was didn't even realise it was running and of course it was only there during work hours when diagnosing stuff is most difficult. Always worth remembering that story when things are looking really weird. Check the MAC of the DHCP server, you can see if it's the correct one instantly and if it's not you can find out the manufacturer which gives you something to look for. Of course that doesn't help if it's a malicious attack where the rogue server has spoofed your own MAC. Steve

On Windows (I don't know if you can do it under Linux) I usually untick the IPv4 and IPv6 protocol on the network cards which supply connectivity to other network segments. For example : If I have a pfSense box with two network cards (RED = WAN) and (GREEN = LAN) then I usually untick both IPv4 and IPv6 from the WAN interface. The LAN interface I leave as is, as you'll need to have either a static IP (suggested) or dynamic IP on it for you to connect and administrate pfSense. The rest don't need IPv4 or IPv6 either, should you have other network cards. This makes it more difficult for ne'er-do-wells to try and hack the windoze box hosting pfsense.

@pfNeo: can a tcpdump file be converted to exe? In Security Onion, you can recover files in multiple formats. The new pfSense Suricata package also has file capture capability.

You are correct. It did not auto install. Got it going now thanks!

yeah using the same sort code as exists on other pages would be fine, you're welcome to submit a pull request to master/2.2 with that.

Anyone…. ? ::)

@phil.davis: You have set an "upstream" gateway on your LAN. Actually there is no gateway on a pfSense LAN, it is the WAN that has the gateway out to the internet. Interfaces->LAN, change the gateway to none and save. System->Routing - delete the gateway for LAN, and set the WAN gateway to default. Firewall->NAT, Outbound - set it back to Automatic. Now pfSense will understand that LAN is an internal network and WAN is the way out to the big bad internet. It will auto-generate NAT rules from LAN to WAN. Nice one. Didn't catch that when I looked.

Connection to a laptop seemed a bit more stable, but still something like a 1 in 20 chance of auto-neg and the link staying up - it could take 5 minutes or more for it to actually get a connection. PFsense just didnt want to stay connected; i guess it handles weak links differently than my laptop does. I don't remember anything obviously wrong with the v120 before it went pop. worked fine before flicking the switch, and then problems when powering it back up. touch annoying that it only lasted just over 12 months. hope this one lasts longer!

Apologies for resurrecting this thread. I have the same issue as the OP, however, I'm able to add a few extra details and information : pfSense version : 2.1-RELEASE (i386) built on Wed Sep 11 18:16:22 EDT 2013 FreeBSD 8.3-RELEASE-p11 2. 32-bit version 3. Full install (running as a virtual machine) 4. Status - Services do show bandwidthd is running 5. System log - the last few messages I have from bandwidthd is Mar 6 10:43:03 bandwidthd: Monitoring subnet 192.168.0.0 with netmask 192.168.0.0 Mar 6 10:43:03 bandwidthd: Monitoring subnet 192.168.48.0 with netmask 192.168.48.0 Mar 6 10:43:03 bandwidthd: Monitoring subnet 192.168.80.0 with netmask 192.168.80.0 Mar 6 10:43:03 bandwidthd: Opening em3 Mar 6 10:43:03 bandwidthd: Opening em3 Mar 6 10:43:03 bandwidthd: Opening em3 Mar 6 10:43:03 bandwidthd: Opening em3 Mar 6 10:43:03 bandwidthd: Packet Encoding: Ethernet Mar 6 10:43:03 kernel: em3: promiscuous mode enabled Mar 6 10:43:03 bandwidthd: Packet Encoding: Ethernet Mar 6 10:43:03 bandwidthd: Packet Encoding: Ethernet Mar 6 10:43:03 bandwidthd: Packet Encoding: Ethernet I must add that it did work for about 4 to 5 hours before stopping. Now I only get the "has nothing to graph" message.  >:(