“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.
One of our customers wants you use their locally installed Microsoft Outlook through a Citrix Access Gateway (CAG). Sales people from that customer travel through the country and use the Outlook offline to read or prepare e-mail to send later. These people use UMTS technology to connect their laptops to the Internet. The customers wants these sales people to have the ability to use their Outlook offline and actually send/receive mail when connected to a network with Internet access.
The customer is using CAG’s to publish multiple services to the Internet, so together with my colleague Edwin Houben from DigiPulse, we started to look at a suitable solution. The CAG is located behind a CheckPoint firewall and traffic to the internal network needs to go through an ISA server firewall.
First we started to look at the ports Microsoft Outlook uses to connect to the Exchange server. Looking at the settings from a laptop, the connection is made by FQDN of the Exchange server. While performing a netstat -na we noticed that Outlook uses two ports to connect to the Exchange server.
The Outlook clients connects to the Exchange server on FQDN. So the laptop needs to have an IP connection to the Exchange server. So we decided to use the Citrix Secure Access Client to give the user the ability to establish an secure IP connection to the network.
Looking at the customers network, we had to configure access-lists on two locations to make the solution more secure. The first location is a Network Resource in the CAG. The Network Resource enables only the above ports to the Exchange server IP address. The second location is allowing the IP address of the CAG to connect to the Exchange server on the above port numbers through the ISA server.
After configuring both access-list, we did some testing and the solution works perfectly. You can now use the laptop on the internal network and externally with the Citrix Secure Access Client without making any changes in the Outlook configuration.
Later, the customer noticed that he couldn’t use Microsoft Outlook anymore in conjunction with the Citrix Secure Access Client. After digging a bit deeper in the traffic flow between Microsoft Outlook and the Exchange server, I noticed that, beside TCP/135, random ports above 1024 are used. So I changed the Network Resource and the ISA servers to allow TCP/135 and the range TCP/1024-2000. I haven’t used the complete range of registered port numbers, so I hope Exchange doesn’t use a port above TCP/2000.
I didn’t some Googleing (or Googling or whatever) on TCP port 135 and I found some “funny” things:
Some well known Root kits also use this port to transmit data back to home base and download more malware. I also suspect may be an entry point for some root kit /malware for un patched systems or systems that did not patch correctly. Source
Currently inbound scans are likely the Nachi or MSBlast worms. Source
The problem with port TCP 135 is that it is used for multiple services, which are listed below. So blocking port TCP 135 could affect communication between devices or the usage of services.
|Client/Server Communication||DCOM||DHCP Manager|
|Exchange Administrator||Microsoft Message Queue Server||RPC User Manager|
|RPC Service Manager||RPC Port Mapper||SCM used by DCOM|
|SQL Session Mapper||WINS Manager|
Aaarrrgggghhh, I hate it when I would like to telnet into a device and enter the wrong IP address. This means, by default, waiting for 30 seconds before being able to correct the IP address and start a new telnet session, because there is no escape sequence.
Trying 10.100.12.250 …
% Connection timed out; remote host not responding
Luckily there is a command to lessen the time for timing out the connection:
SW01(config)# ip tcp synwait-time <seconds> (Set time to wait on new TCP connections)
Hoera, tcp synwaiting saves the day….
Voice over IP is, as you know for sure, very time-sensitive traffic. That is why VoIP signaling and payload traffic should receive enough bandwidth and as less jitter and delay as possible.
QoS is an important tool to assign VoIP traffic more preference over “normal” traffic. Important for QoS tools to function correctly is placing different kinds of traffic in different queues. To place traffic in different queues, traffic should be classified. All VoIP traffic should be classified and placed in the same queue or given the same priority. I usually use the following ACL’s to match VoIP signaling and payload traffic.
ip access-list extended VOIP-SIGNALING
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended VOIP-PAYLOAD
permit udp any any range 16384 32767
The following table gives some basic explanations for the different permit statements:
|H.323 / H.225||TCP/1720|
|H.323 / H.245||TCP/11xxx|
|Media Gateway Control Protocol (MGCP)||UDP/2427 and TCP/2428|
|Skinny Client Control Protocol (SCCP)||TCP/2000-2002|
|Simple Gateway Control Protocol (SGCP)||TCP/2000-2002|
|H.323 / H.225 RAS||TCP/1719|
|Session Initiation Protocol||UDP/5060|
|Real-Time Transport Protocol (RTP)||UDP/16384-32767, even ports only|
|Real-Time Control Protocol (RTCP)||UDP/16384-32767, odd ports only|