Took a quick look. You do have a firewall rule dropping the majority of traffic for an IP address (you can see it in the Firewall Log). The thing to keep in mind, though, is that that filtering happens after traffic is redirected to MECguard, so web traffic will work (but other traffic will not). The easiest way to block "problem" hosts is to create a new firewall group (e.g. "No Access") and put the IPs of the hosts you want blocked in its members. Then create a firewall rule to block for that group, rather than the IP, and put a "." in the group blocked site list (a "." will catch every website and block it). You might also consider using Blacklist rules instead of Closed Port for this; the order rules are read is "Blacklist" -> "Open Port" -> "Closed Port", so if you use a Closed Port rule, any matching Open Port rule would override it. Under your web filter rules, you want to make sure that you have a rule to not filter your public IP addresses, as otherwise MECguard will catch incoming HTTP requests to your servers from the outside. I see that there is one there, but it's set to "Private LAN" for the source. Change that to "Everyone Else" and you'll probably see the webmail problem go away. As for sending mail, that certainly seems odd. The Joebox only needs to know the IP address of your mail server, not your mail client. Are you sure the clients are trying to use that SMTP server? Or are they perhaps configured to use an off-site SMTP server (e.g. Google). As for access control, Vince was pretty close. Right now the Joebox doesn't have an easy way to give out IP addresses only to static hosts and not do open pool allocation (though you can get around that by creating a very small pool that has the IP statically assigned to something). Network Management (our centralized DHCP setup) only hands out DHCP to known hosts. This alone won't stop students from being able to hard-code IP addresses on their own devices to gain access, though. For that, you need to implement Layer-2 access restrictions. There are a few different ways to do it, and they're slightly different depending on if you use Wired or Wireless. If you're running a Cisco Wireless setup with a controller, then it's likely that the controller already enforces DHCP. For Wired you would be looking for features like "DHCP Snooping" and "IP Source Verification". These can be found on most of the enterprise Cisco offerings but for other vendors you would need to check on the specific platform. "Better DHCP" is on my wish list for Joebox, just not sure when we'll be able to get it improved. On a side note, if you do use static DHCP on the Joebox, be careful to type in the MAC address perfectly; the Joebox doesn't have any error checking and it will cause DHCP to crash if you have a typo... (I know, it drives me crazy too.) On Mon, Sep 12, 2011 at 11:20 AM, James Jalbert <[log in to unmask]> wrote: > I am wondering if anyone has seen or has any information on any of the > following issues my district has seen now that we are using the Joebox as > our router/firewall/filter. > > 1. The old firewall that we were using, I was able to go into the firewall > settings, and block a single IP address completely. We have had issues with > students hard coding IPs into their personal devices, and using them on our > network. I have in the past been able to trace the IP address to an unknown > device(one that is NOT ours), then go to my old firewall(PFSense) and set a > rule to block all traffic to or from this IP address. I have tried this with > the Joebox but have been unsuccessful at doing so. I even tried it with the > IP address that my machine uses, and I was still able to get out to the net. > > 2. I know that the Joebox has an exception area for mail servers. This just > started to happen about 2 weeks ago. Our mail server has been in this > exception list forever, and has worked fine. Just a couple weeks ago, I > noticed that machines sending mail out THROUGH our mail server stopped > sending mail. Also the 3 or 4 ipods that we use in the Tech Department, > could receive mail, but could not send mail. Once all these IPs were added > to the mail exception area, they started working again. What changed? I have > only had to have our mail server in the list from July till now, and > everything worked great. Now I have to add any IP that passes mail through > our mail server to this list also? > > 3. And last, we have now had a few reports of staff members trying to get to > web-mail from home and not being able to. We are using Novell Groupwise 8 > for a mail server. The complaint we are hearing is that when staff go to the > web mail site, they get the login page. Once they login all they get is a > blank white page. The issue right now seems to be with Windows 7, but I have > not fully verified this by testing my self yet. > > Any thoughts, insight, or information on any of these question will be > greatly appreciated. Thank you all in advance. > > James Jalbert > Network Administrator > Eastern Aroostook RSU #39 > Phone: 207-493-4246 > E-Mail: [log in to unmask] > > > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/