Connecting the world…


Cisco ASA – Reset TCP connection

“Normal” TCP applications use a three-way handshake to establish a session. After data has been send the session is closed. Some legacy applications don’t always close a TCP session. They keep the session open, even when the session is idle for a long time (+ 2 hours). When the session is idle and a client wants to send data, the clients sends a PSH packet followed by the new data. Both stations use the original session information to maintain the connection.

This behavior is problematic when components, like firewalls are along the path between the two clients. A Cisco ASA firewall for example automatically flushes a TCP session when it’s idle for 1 hour. When the clients start sending data after an idle period of 1 hour, by starting with a PSH command, the firewall doesn’t recognize the session anymore and drops the traffic. Both clients need to flush / restart their TCP session to establish a new valid session through the firewall.

The Cisco ASA firewall has the option to change the default idle timers and even send a reset (RSET) to both clients when the idle timer is reached. The Reset bit in TCP is designed to allow a client to abort / terminate the TCP session with another client. This forces both clients to re-establish a new session, which is learned and maintained by the firewall. This prevents a session from getting dropped in the firewall when it’s idle for more than one hour.

To configure a TCP reset you need to specify the “interesting” traffic for a reset through an access-list and specify the reset parameters via a policy-map like shown below.

access-list reset_tcp extended permit ip host
class-map cm_reset_tcp
match access-list reset_tcp
policy-map global_policy
class cm_reset_tcp
set connection timeout idle 0:15:00 reset

The configuration snippet resets a connection when it’s idle for 15 minutes between the network and the host The sessions are initiated by the remote network. You can view the connection parameters with the show conn command.

fw01# show conn address address detail
TCP DMZ: Inside:,
flags UIOB, idle 3m11s, uptime 51m56s, timeout 15m0s, bytes 165157

The output shows the configured idle timeout of 15 minutes, the real idle timeout and the uptime of the connection.

NBAR and smart filtering

NBAR (Network Based Application Recognition) is a cool Cisco tool to identify and classify content flowing through a router. You can identify applications as mission critical, business-related, non-critical or unwanted. Once these mission critical applications are classified they can be guaranteed a minimum amount of bandwidth, policy routed, and marked for preferential treatment. Non-critical applications including Internet gaming applications and MP3 file sharing applications can also be classified using NBAR and marked for best effort service, policed, or blocked as required.

In the following example you will see how to block access to YouTube and block the extension .exe. I will block the content when it tries to “enter” the router on the internal interface Vlan1. To start with you need to enable NBAR on the interface.

RTR#configure terminal
RTR(config)#interface Vlan 1
RTR(config-if)#ip nbar protocol-discovery

Create a class-map to identify the content which needs to be blocked.

RTR#configure terminal
RTR(config)#class-map match-any cm-blocked-content
RTR(config-cmap)#match protocol http url “*.exe”
RTR(config-cmap)#match protocol http host “*youtube*”

The following step involves creating a policy-map to block the traffic matching the previous class-map.

RTR#configure terminal
RTR(config)#policy-map pm-blocked-content
RTR(config-pmap)#class cm-blocked-content

You can also police or shape the identified content so it cannot “consume” all the available bandwidth. The final steps is to apply the policy-map to the internal interface in the input direction.

RTR#configure terminal
RTR(config)#int Vlan 1
RTR(config-if)#service-policy input pm-blocked-content

To verify the operation of NBAR you need to try to browse to the YouTube website or download a file with the .exe extension. Check the operation with the show policy-map interface vlan 1 command, like shown below.

RTR#sh policy-map interface vlan 1 input


 Service-policy input: pm-blocked-content

  Class-map: cm-blocked-content (match-any)
   228 packets, 121574 bytes
   5 minute offered rate 0 bps, drop rate 0 bps
   Match: protocol http url “*.exe”
    9 packets, 7090 bytes
    5 minute rate 0 bps
   Match: protocol http host “*youtube*”
    24 packets, 12813 bytes
    5 minute rate 0 bps

  Class-map: class-default (match-any)
   111703 packets, 12021043 bytes
   5 minute offered rate 33000 bps, drop rate 0 bps
   Match: any

From now on your users aren’t able to browse to YouTube or download .exe files over HTTP. With NBAR you can also block a specific content type, like streaming  media. I use WireShark to retrieve the content-type I would like to block. By following the TCP stream from a WireShark session you can find the exact content-type or other useful information.

Use the match protocol http mime command to classify a content-type. In MIME type matching, NBAR classifies the packet that contains the MIME type and all subsequent packets, which are sent to the source of the HTTP request. This means that the corresponding policy-map should be applied inbound (input) on the external interface or outbound (output) on the internal interface. For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA)-supported MIME types can be found here.

Microsoft IAG

It has been a while since my last post, but time is short these days.

Today I had to troubleshoot a Microsoft IAG appliance. Microsoft IAG stands for Microsoft Intelligent Application Gateway. And indeed, intelligent it is. NOT. I have seen and configured multiple SSL VPN solutions like Juniper SA, Citrix Access Gateway, Citrix Secure Gateway and Cisco WebVPN. But to be honest, Microsoft IAG is the worst of all.

Microsoft IAG is installed on an appliance and is closely related to Microsoft ISA 2006, which is also installed on the server. Whenever you make some configuration changes to IAG, you have to active the new configuration inside IAG. After activating the configuration, I looked at the new ISA firewall policies and I really couldn’t believe my eyes. IAG configured ISA automatically, when activating the configuration.

A simple portal, where 2 websites and OWA are published and a network connect (SSL IP VPN), results in approximately 10 firewall policy rules in ISA. Okay, I could live with that, but I shivered while taking a closer look at the rules. It is not easy to discover what purpose a specific rule has, without looking to the different tabs while editing the rule.

Besides the crazy management of the appliance, me and a colleague had a lot of problems when testing the appliance. Currently the network connector is not supported on Windows Vista and you receive a lot of (useless) errors when using Internet Explorer 8. The logging functionality is also very basic and hard to find. I had problems with configuring and testing the network connector with the non-split tunneling and disable local area network access option, I couldn’t find any useful logging about the problem. For some reason only specific traffic is routed into the VPN tunnel. I ended up configuring split-tunneling and only route specific network segments into the SSL VPN tunnel.

My opinion till now, Microsoft IAG cannot be compared with other SSL VPN appliances I have seen. I guess Microsoft IAG could test positive when using the appliance in a solely Windows environment, where only Windows services, like OWA and SharePoint, are published to the internet.

Maybe the solution is a lot cheaper compared with the Juniper and Citrix solution, but for know I would rather buy a Cisco ASA 5505 or Cisco ASA 5510. I would definitely not configure the Microsoft IAG as a cooperate firewall terminating the Internet connection.