Blog: firewall

I recently migrated a pair of ATMs from behind a Microsoft Threat Management Gateway to a Cisco ASA.  During this cutover, the change was done very quickly so the VPN traffic for the ATMs was not interrupted. [more]

A few weeks later the ATMs started having problems when the Internet connection was disrupted. The VPN tunnels were connected, but the ATM provider was receiving reset packets from the ATMs. I discovered the ATMs were communicating with the ATM provider using TCP port 2000.

Normally TCP 2000 is used by the Cisco Skinny Client Control Protocol (SCCP) and traffic inspection for SCCP is enabled on the ASA by default.  The packet resets stopped after removing SCCP inspection from the global policy list.

To disable SCCP inspection on the ASA:

CiscoASA# conf t

CiscoASA(config)# policy-map global_policy

CiscoASA(config-pmap)# class inspection_default 

CiscoASA(config-pmap-c)# no inspect skinny


I needed to have access on a branch PC on another subnet ( from the main site’s subnet ( 

Using remote desktop, I turned off Windows Firewall on the PC and could access the C$ share on the remote PC from the main subnet. 

Looking at the Windows Firewall exceptions, I could see that File and Printer Sharing was already checked.  I clicked edit and saw the required ports defined here.  When I clicked “Change Scope”, I saw that it was set to “My network (subnet) only”.  For all four entries, I changed the scope to use a custom list that encompassed all 192.168.x.x networks and was able to browse the C$ share from all subnets. [more]


At a customer site, running a Baracuda firewall, iPhone users were unable to check for devices updates. Everytime the user would have iTunes check for device updates it would fail. One of the rules in the Barracuda is to allow iTunes updates.  The rule to allow iTunes updates was enabled, but the traffic was still being blocked. I monitored the weblog and found the iPhone version check was being blocked by a streaming media filter. I added a URL pattern to allow access to and iPhone update traffic could get through the Barracuda.


If you use the setup wizard for Cisco ASA appliances to allow SSH access it doesn’t auto-generate a key.  It will create the access-rules, but you still won’t be able to SSH to the firewall until the key is generated.  The quickest way to generate the key is via the command:

generate crypto key rsa modulus-size” [more]

Note: The modulus-size can be 512, 768, 1024, or 2048.  The value of 1024 is recommended.



  1. Machines that used to run ISA Firewall client
  2. Uninstallation of ISA Firewall client
  3. New PROXY settings configured
  4. SEP 11.5 installed.

Many machines began getting errors in the application logs from Event Source: crypt32, Event ID: 8.  The description of the error says “Failed auto update retrieval of third-party root list sequence number from: [more]”.

I eventually stumbled across a few forums that eventually led me towards this issue happening after installing SEP 11.5.  What seemed to be happening is that the machines attempted to update its root certificates from Microsoft Update at two hour intervals.  The machine will attempt to connect using the SYSTEM account, so it is important that this account also has the correct PROXY settings.  It is likely that after removal of ISA Firewall client, the settings for the SYSTEM account were left in the registry pointing to the old PROXY server. 

The SYSTEM account can always be found in the registry at HKEY_USERS\S-1-5-18. I found that on machines that were not working, the registry keys under HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings were pointing to the old PROXY script whereas the working ones were pointing to the correct PROXY wpad.dat configuration file.  I had to pull the settings from a newer system because this registry key is a binary key, so you cannot simply type the value.

Be sure that the machine also has unauthenticated user access allowed through any web filtering appliance to also.  
More information can be found at


During a recent information security audit, I ran across a “unified threat management” system that I had not seen before called Untangle (  The bank was using it in place of a traditional firewall.  According the Untangle website, the Untangle Gateway is “the world’s first commercial-grade open source solution for blocking spam, spyware, viruses, adware and unwanted content on the network, provides a free and better alternative to costly, inflexible proprietary appliances.”  The interesting part is that the gateway runs on Linux and all the “modules” (firewall, IPS, web content blocker, etc.) are open source downloads, so the gateway is a free download.  Additionally, the source code for the Untangle gateway is available for download. [more]

You can choose to pay for certain modules such as Untangle support, an Active Directory connector, Kaspersky virus blocker, etc..  However, the rest of the modules can be downloaded and installed from a very simple GUI for free.  So far, I have not been able to find any major vulnerabilities or issues with this software.  Their target market is small to medium businesses that don’t want to pay the big bucks for Cisco, SonicWall, and other proprietary appliances.

Untangle also makes another product called “Re-Router” that is a network gateway/proxy server that runs in background on a Windows XP workstation.


In the past, we had removed the Firewall Client Management Tool (fwcmgmt.exe) from the Startup folder for All Users during Terminal Server setup. This was done to prevent the icon from showing up in the system tray for all users.

It appears that this tool must be running in order for firewall configurations to be pushed out from ISA. Recently we configured the firewall client to disable web proxy in order to force all applications (IE, etc) to use the firewall client. However, these settings were not pushed out for users because the Firewall Client Management Tool was not running. [more]

Adding this tool back to the All users Startup folder enables this process to run for all users. In addition, you can modified an ini file (Documents and Settings\All Users\Application Data\Microsoft\Firewall Client 2004\management.ini) on a server so that the system tray icon will be hidden for all users.


While onsite for an IT audit this week, I had to connect to a bank's network from three separate locations. 

At the first location, I got a couple of DHCP addresses (one for my host and one for VMWare workstation) and had no trouble getting connected to the Internet (via browser, RDP, etc.).

When I connected at the second site, I was able to get Internet connectivity from my host but not from within VMWare.  I fiddled with it for a while and finally made do.

When I connected at the third site, they told me they needed to give me static IPs since they had IP tables in their Checkpoint firewall to define what systems had Internet access.

That got me to ask why I had no problems at the first site and half a problem at the second site.  The root cause of all this was their lack of reviewing the IP table in their Checkpoint firewall.  The whole bank subnet at the first site was allowed access to the Internet (this was leftover from a merger about six months ago).  The IP address DHCP gave my host at the second site just happened to be in their list on the firewall (nobody could remember why that random address was in the table).  It's good to review your configurations or have someone else look over them, because mistakes won't necessarily be obvious.