educontractor

All sorted thanks to the kindness of a fellow Edugeek. :-)

Hello, Very late to this particular party, but we've inherited a school with lots and lots of these Dell Latitude 3190's supplied by the DfE. The link that I have been provided to access the BIOS passwords from Computacenter no longer works. I'm wondering if anybody would be so kind as to DM me the BIOS password or bypass technique so that I can reimage these? TIA.

Hi guys, Just reporting back that we've solved it. The issue wasn't actually with Smoothwall - it was a combination of JAMF and Mac OS. So we knew that we were pushing proxy settings from JAMF, but I'd assumed (wrongly) that the fact we could enter proxy settings manually when logged in as an admin would override these. Put simply - it doesn't! This explained why (a) the authentication precursor was being passed to the proxy (JAMF didn't have the exceptions right) and (b) why changing the proxy settings to different proxies with different authentication types made no difference whatsoever! With the correct exceptions and using a proxy with Core Authentication the issue is entirely resolved. Thank you all for your valuable assistance!

Just a thought, and I don't know if this is even possible, but if I were to assign the Macs IP addresses within a specific range, could the Smoothwall be configured to assume authentication to a particular group based on the source IP? Alternatively, is there any way of stopping the kerberos pre-pend being added even when no proxy is set?

Seemingly not. The kerberos bit even gets added onto this, which the proxy then tries to resolve. It's as though the OS is sending it to the proxy whether I like it or not, i.e. ignoring the proxy exceptions and the "ignore simple hostnames" part.

For completeness: Adding the simple hostname to HOSTS allowed it to PING without appending the DNS suffix, but the browsing behaviour is identical. Why doesn't it prepend all URL's with smoothwall:813/? Certain ones like the BBC and Microsoft part-load just without images (when I look at the live reporting for my IP I can see calls to the CDN's have the smoothwall:813 added to the front of them, hence why the images aren't loading)

I did, yes. I checked it to be sure and it's definitely ticked for both options.

It can, but possibly only because it's appending the DNS suffix. I'll try adding the simple hostname to the HOSTS file and see if that makes a difference. Apologies for all the ludicrous McCarthyite redactions on the screenshots as well. If it was my site / data I'd be happy to post unedited, but as I'm a contractor I'm being extra cautious.

Thank you again for your ongoing assistance - I really appreciate it. My heart leapt when I read your post - it seemed such a logical solution but, alas, the issue remains (see screenshot). I have requested a ticket with Smoothwall, but I feel that it must be something simple that I'm missing. After all, hundreds of PC's and iPads are concurrently browsing the internet with any issue whatsoever.

Again, thank you for this. I had thought that I had configured it this way, but perhaps I've made a mistake. I wonder if you'd be so kind as to cast your eye over the attached screenshots, and see if I'm missing anything obvious?

Thank you, that's very helpful. I did try enabling a few different proxy ports with different auth methods including a redirect to a login page, but continued to get the above behaviour. Likewise the port/proxy configured for Core Authentication shows the same behaviour... Just to confirm - is the bypass you describe the one set on the clients?

Hello, We have a strange problem. Replaced a bunch of older Mac minis running El Capitan with some M1 based ones running Big Sur. They have the intermediate SSL certificate installed, and trusted. They are using a Proxy configuration that allows Kerberos / NTLM authentication, but falls back to a sane group - Secondary Students for a device that doesn't authenticate. Since the PERL script that authenticates Macs isn't compatible with Big Sur, we assumed this would be fine. The browsing behaviour is strange, though. Some sites e.g. Google, BBC load but the images are blocked. Looking at realtime monitoring of the Web Filter for these sites shows that attempts are being made to download the images through their respective CDN but these requests aren't blocked. Weirder still is that other sites have their URL rewritten, naturally enough resulting in a 504 error as the proxy can't display them. e.g. https://www.yahoo.com is rewritten to http://smoothwall:813/?https://www.yahoo.com/ There isn't a content modification rule that is being applied so does anyone have an inkling as to what's happening here?

Thank you. I originally started that before realising it was HTTPS inspection causing the issue. I had the category created and placed into the web filter as an exceptions list. I must have made a mistake - need to check my work. Thanks for all your help.

Thank you both. The above instructions, in essence are what I have done. I wasn't sure if removing the *. from the Sophos instructions (as is required to save the category in Smoothwall) would in effect apply a wildcard for hosts and subdomains, or it it would instead refer only to the specific URL entered. My rule sits atop all the other inspection policies, so I must have made a mistake. I'll check my work. Thanks again!

Hello all, We've been asked to assist with installing the new cloud (i.e. not Sophos Central) version of Sophos antivirus into a secondary school using a Smoothwall appliance for filtering and monitoring. The web-installer fails, and looking at the logs it fails because the root certificates are invalid when connecting to Sophos' servers to actually download the installer. Sure enough, when we bypass HTTPS inspection on the Smoothwall for the workstation we're testing, the installer downloads and the process completes as expected. However, we can't disable HTTPS inspection for the whole network, even if just for the duration of the install (for obvious reasons). So instead, we added the URL's on this list: https://docs.sophos.com/central/Customer/help/en-us/central/Customer/concepts/DomainsPorts.html To a category, and created a bypass for HTTPS content inspection based on this. This does not work. When we monitor web filter traffic from our IP (to make sure that the URL's match the ones we added to the bypass) we can see URL's that should match the rule for HTTPS inspection bypass. I was wondering if it's because I cannot add wildcard-type subdomains to the category on Smoothwall (unless there's a trick that evades me), despite the Sophos guide requiring them? If anyone has solved this issue, I'd be grateful for any pointers. I know that Smoothwall and Sophos are popular within schools, so hopeful somebody else has trodden this path and resolved the issue! Thank you!

Thanks Michael. You may be right and this is the best we can expect. I wish that I had some hard stats from when the system was installed back in 2012 but subjectively it "felt" faster. I certainly never received any complaints until earlier this year anyway. The thing I keep returning to (like a broken record!) is the disparity between reported download and upload bandwidth. As each test is carried out sequentially, with nothing else using the network, surely each should be the same even if we accept that it will be a long way short of the expected "wire speed"? It's almost as though there's some sort of bandwidth management, or ersatz QoS taking place on the wireless controller. There is a whole section on WMM/DiffServ but nothing has been changed there and when I did a factory reset the settings all remained the same, too.

Comparing apples with oranges, but we have several Ruckus systems in schools with otherwise identical WAN provision (same firewall, same 100Mbit leased lines) and I see 50+ Mbps internet performance when connected at a reported 78Mbps wireless transmit speed. When the wireless connects at 130Mbps+ I see the full bandwidth of the connection. It might well be that this is the best throughput this Extricom kit can manage, but if that's the case it's very disappointing. Also, why would the upstream speed be significantly greater than the downstream bandwidth?

Apologies for letting this thread "fade away" - especially with so many helpful replies. Still having issues with this, and it's very difficult to pinpoint why. This evening, as semi-related exercise I stripped out all of the patch leads from the comms cabinet and recalled it from scratch. As part of this process, I reduced the network to its bares bones: My laptop, the backbone switch (nothing too exciting, a 50 port Gigabit Cisco Small Business SG200), the wireless controller and one access point (the one nearest to me, about 30cm away), and the firewall and everything beyond it. Wired into the switch, running speedtest.net I got 94Mbps down and 92.5Mbps up. Running the same test wirelessly I got 17Mbps down and 26Mbps up. Reset the controller to factory defaults, recreated the channel blankets (radio 1: n/g channel 6, radio 2: n/a channel 36, radio 3: rogue detection), ran the same test wirelessly and got 15Mbps down and 25 Mbps up (take this to be the same as previous accounting for vagaries of internet speed tests). Recreated the channel blankets from scratch on channel 1 and channel 11 (my laptop just didn't seem to fancy connecting on 5Ghz for some reason) with the exact same results bar a couple of Mbps either way. Each time my laptop (Retina MBP) reported itself connecting at 130Mbps. Really got me stumped why the performance would be so poor. Why also would the upload throughput be almost 50% greater than the download? Thank you very much for all of the input thus far, and apologies again for the long period without reporting back.

Haven't done that I must confess. I can monitor connected devices, for encryption it's set to WPA/WPA2 with AES or TKIP. ASCII PSK for the password.

Nothing exciting to see there, unfortunately. I captured c. 50,000 packets and nothing stood out. A few malformed HTTP sessions, normal amounts of ARP broadcasts, few unanswered ICMP requests. No multicast traffic. My laptop was the biggest talker on the segment... all very "meh".

Actually, embarrassed to say I hadn't though of doing it this way (Wireshark whilst attached to the WLAN) as I usually connect remotely and run Wireshark from a virtual machine on the wired network. Trying that now.

Thanks for replying Michael. Both switch and controller have been rebooted, and the switch is reporting the controller connecting at 1000Mbit/s FDX. The wireless controller's web interface loads snappily and doesn't exhibit any of the sluggishness I'd associate with a problem at the ethernet layer. It's very subjective I realise, but activity on the WLAN (gauged by looking at activity LED's) looks very "broadcasty". It's impossible to sniff traffic AP-side with the extricom controller, however, and running Wireshark on the wired LAN doesn't show excessive broadcast traffic. All very strange.

Hello all, We have a mix of Meru (x2), Extricom (x2) and Ruckus (x12) managed wireless networks across our schools. All have their pros and cons (this isn't the purpose of my thread) but we've experienced problems with one of our Extricom schools recently, related to poor connection speed and throughput. The school (a single form entry Primary) have An Extricom EXSW-800G controller with 8 x EXRP30n access points. They have a 100Mbit Virgin Media leased line paired with a Watchguard XTM330 for firewall/filtering. Wired LAN is using a Cisco SG-200 series 52 port Gigabit Ethernet Switch. The wireless system has been extremely reliable, and performance sufficient that nobody has complained about it since installation in 2012. This is no longer the case, however! Despite there being no physical reconfiguration of the network, performance has become markedly slower and connection speeds to the WLAN have dropped too. Whereas previously it was common to see 100Mbit+ TX connection rates throughout the building, it's far more common now to see 36Mbit and below. Internet speed (as measured - imperfectly I admit - with online speed tests) registers ~10Mbit up/down via the WLAN, but wiring in at the same time sees ~85Mbit down and ~95Mbit up. I've reconfigured the WLAN from scratch to the same specification and the exact same results can be seen. Placing a laptop close to an access point sees *connection* speeds reach 130Mbit (albeit after a minute or two) but throughput is still disappointing compared to a wired connection, never achieving more than 45 Mbit/s in either direction. This certainly didn't wasn't the case previously. Unfortunately, Extricom are pretty much a closed book with regards to support in this country (one of the principle reasons we moved to installing Ruckus) so I can't obtain updated firmware for the controller / AP's and nobody responds to my emails for technical support from Extricom HQ in Israel. Has anybody here got any advice? The following are the software versions the controller is running: [TABLE=width: 100%] [TR] [TD=class: GeneralText, width: 60]OctopusFS:[/TD] [TD=class: GeneralText, width: 614]v4.5.09.10~fr_2011-Dec-28-1758[/TD] [/TR] [TR] [TD=class: GeneralTextBold]Serial Number:[/TD] [TD=class: GeneralText]xxxx[/TD] [TD=class: GeneralText]AppsFS:[/TD] [TD=class: GeneralText]v4.5.09.10~fr_2011-Dec-28-1758 [/TD] [/TR] [TR] [TD=class: GeneralTextBold]Domain:[/TD] [TD=class: GeneralText]xxxx[/TD] [TD=class: GeneralText]Kernel: [/TD] [TD=class: GeneralText]#1 Wed Oct 26 18:14:47 IST 2011[/TD] [/TR] [/TABLE] Forum cliché alert: Thanks in Advance!