Connecting the world…

payload

Cisco ASA NPE image

I got complains from a customer who wasn’t able to configure 3DES or AES encryption for a VPN tunnel. Sounds familiar with a problem I had a couple of weeks ago. So I gave the customer the advice to upgrade and activate the VPN-3DES-AES feature. He tried but that didn’t solve this problem.

I remotely logged in and checked the software he was using. I noticed he was using the image asa832-npe-k8.bin. Problem found!!!

NPE stands for No Payload Encryption. For export to some countries, payload encryption cannot be enabled on the Cisco ASA 5500 series. For version 8.3(2), you can now install a No Payload Encryption image (asa832-npe-k8.bin).

Features that are disabled in the No Payload Encryption image include:

  • Unified Communications;
  • Strong encryption for VPN (DES encryption is still available for VPN);
  • VPN load balancing (note that the CLI is still present; the feature will not function, however)
  • Downloading of the dynamic database for the Botnet Traffic Filer (Static black and whitelists are still supported. Note that the CLI is still present; the feature will not function, however);
  • Management protocols requiring strong encryption, including SSL, SSHv2, and SNMPv3. You can, however, use SSL or SNMPv3 using base encryption (DES). Also, SSHv1 and SNMPv1 and v2 are still available;

If you attempt to install a Strong Encryption (3DES/AES) license, you see the following warning:

WARNING: Strong encryption types have been disabled in this image; the VPN-3DES-AES license option has been ignored.

I replaced the software image with the regular image and the problem was solved.

QoS matching for VoIP

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.

VOIP SIGNALING

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

VOIP PAYLOAD

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:

Protocol Matching criteria
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