“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 192.168.10.0 255.255.255.0 host 10.10.10.205
match access-list 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 192.168.10.0/24 and the host 10.10.10.205. The sessions are initiated by the remote network. You can view the connection parameters with the show conn command.
fw01# show conn address 192.168.10.2 address 10.10.10.205 detail
TCP DMZ:192.168.10.2/31731 Inside:10.10.10.205/4000,
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 (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(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(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.
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(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
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.
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.