Sonicwall’s Application Firewall and blocking BitTorrent

BitTorrent
We’ve just updated the firmware on our NSA 4500 to 5.5.2.0-3o and have started playing with the Application Firewall and DPISSL (Deep Packet Inspection). The 4500 is a Layer 7 firewall and the application firewall feature lets you do some pretty tricky filtering. We’ve noticed that some of the student machines coming in for repair have bittorrent clients installed. At the moment that sort of traffic is blocked by our ISA firewall/proxy which is the gateway for the Student Netbook VLAN, but we want to remove that over the next few months because it causes a bottleneck for heavy traffic, like heavy ClickView use. When we remove ISA we can either use the Sonicwall or ACL rules on the ProCurve 5400 (or both) to filter the traffic between the netbooks and the rest of the world. After the firmware update with the addition of the DPISSL it seemed like a good chance to see how good the filtering was on the NSA4500.

Before creating the new application firewall policy, I had to create an object for the bittorrent traffic. The Sonicwall has an IDP category for all P2P traffic which has signatures for many P2P applications. You can block traffic for particular applications, eg only block Azureus and allow other bittorrent clients

 applicationobject

With the Application object defined, we can create the policy. In this case we wanted to stop all bittorrent traffic, however, its possible to excluded addresses and or users, which would be handy with the SSO. The rule will look for any traffic deemed to be P2P going through the sonicwall and will drop the packets. nice and easy

policysettingse

Any requests that match the rule are blocked and can be checked in the log view, which can be filtered by application firewall

LogFilter

Setting up uTorrent on a test machine and queuing up some files showed that the rule was working properly and not allowing any traffic to get through. The sonicwall not only blocked the file transfer but also the attempts to look for other peers etc
Capture4

The combination of the application firewall and the DPISSL would also prevent this traffic from running over secure ports or ssl vpn type setups.

Application firewall rules can also be configured to shape traffic to/from any site on the web. At the moment we’ve configured a rule to shape traffic to megaupload and other download sites that work over port 80, and depending on Facebook traffic that could be a contender too. Another type of rule that was described in some sonicwall promotional guff was a rule to catch IE6 traffic and redirect it to a warning page to upgrade your version of IE. That rule sounds like a good idea, I think that might be my next one

BSOD Shenanigans and Minidump files

WindowsRecoveredFromErrorSince we imaged our 2740p Tablets with our Windows 7 SOE two weeks ago, we’ve had a few problems with machines blue screening on shutdown and hadn’t been able to work out which application or driver was causing it. When a machine BSOD’s it creates a minidump file with debugging information about why Windows crashed. Usually we can work out what’s caused the BSOD and we can fix it without having to check the minidump, but this one had us stumped.

Downloading Windows Debugging Tools and the Windows SDK sounded like a massive effort for checking the contents of a file, but in the end, it turned out to be nice and easy. PCHell has a nice Step-by-Step guide to viewing minidump files and after downloading and installing the debugging tools, all we had to do was run WinDbg and open the last minidump file to see that NIPALK.SYS was the offender.

WinDbg

WinDbg doesn’t make you trawl through useless info to get to the offending driver, the info you need is at the bottom of the dmp file labelled Probably Caused by!

A search of the computer found NIPALK.SYS in the C:\Windows\Systen32\drivers folder and Google search found lots of results for Labview and Robolab. Since Robolab is in our SOE, we quickly removed it from the system and that seems to have fixed the BSOD issues on shutdown. Looks like we might need to update to the latest version of Robolab for our next SOE 🙁

RemoteApp: Synergetic access from Home

Finding a decent solution for remote access to Synergetic has always been a problem. The Synergetic loader starts the application from a shared network drive, which is fine when Staff are at School but when they’re offsite, it’s tedious loading Synergetic with a 1Mb upload on the School’s internet link.

RemoteApp was a new feature with Server 2008 and has been refined further with 2008 R2 and Windows 7 with the RemoteApp and Desktop Connections. RemoteApp works similarly to the traditional Windows Terminal Server login used with previous versions of Windows Server, but with more functionality. When you configure a program for RemoteApp, the end user gets the same icon on their desktop or start menu that they would if the application was installed locally. The icon is a shortcut for remote desktop(RDP) that loads a full terminal services login, but hides the session and only shows the application, which is running in the TS session. The user’s printers and mapped drives etc can all be used in the RemoteApp, same as an RP session, but is set per program.

Accessing Synergetic via RemoteApp offsite is as seamless as connecting when at School and doesn’t require a VPN connection. Setting up RemoteApp with signed certificates and opening ports on the firewall is the way to go. Users still have to pass AD authentication, and depending on your Synergetic setup, another username and password to login to Synergetic.

 

Video -  loading Synergetic with RemoteApp

After a brief trial of Synergetic with RemoteApp it looks like we’ll be purchasing the necessary RDS User CAL’s (Check here for changes to TS licensing) and using RemoteApp for Staff access to Synergetic from home and getting them to use this setup for their Academic Report writing and avoid the confusion between Synergetic Network/Stand-Alone and importing/exporting reports.

To setup the trial of Server 2008 R2 and RemoteApp, follow something like the TS RemoteApp Step-by-Step Guide which is pretty straight forward. If you have Windows 7 clients, make sure you check out RemoteApp and Desktop Connections where you can set the Win7 machines to check a URL for a list of available RemoteApps and it will update regularly and automatically put shortcuts on the start menu for users

After you’ve configured the TS services, install Synergetic on the TS box and add it as RemoteApp through the Wizard

wiz1

If your a large Synergetic customer, you probably have multiple databases for different users and need to specify different configuration files with command line arguments.

wiz2

Here’s our test RemoteApps for Synergetic

remoteAppPrograms

Pushing the links for RemoteApps out as *.MSI or RDP files via a script or download makes things nice and easy too

I hadn’t paid much attention to RemoteApp and Microsoft’s VDI offerings, which seems like a mistake on my behalf. With the price of EDU licensing for MS Apps, this is a nice and tidy solution to a problem we’ve had since purchasing Synergetic 10-12 years ago. It might be a good solution for getting applications onto our Student Netbooks too… will see how we go