Showing posts with label Cisco ASA. Show all posts
Showing posts with label Cisco ASA. Show all posts

Tuesday, March 12, 2013

Cisco ASA QoS For VoIP

So the goal is simple, right? You have a hosted VoIP solution and you want to ensure that your data traffic does not delay the VoIP traffic or worst still, you don't want the edge firewall dropping any VoIP packets because of high data usage.

I have a few customers that have deployed hosted VoIP solutions from WaveStreet and 8x8 - the usual complaint from time to time is that "the voice quality is bad" or "I could not hear the other party". Now most of these folks have simple networks like the one depicted below and I have managed to eliminate their VoIP issues with QoS configurations on the ASA.



In this particular example, we have a Cisco ASA 5505, a layer 3 switch with two VLANs, one for data and one for voice. Not included in this blog are the configs for the switches. It is advised that you turn on QoS on the switches if they supported it.

Prioritizing VoIP traffic using a Cisco ASA is well documented but the problem is Cisco's documents tend to omit a few important facts. Their example always use just the outside interface (ISP facing). Now, because QoS only acts on the egress traffic when applied to an interface, this does nothing for the inbound traffic from the ISP - the more important direction!

The second critical detail omitted is that even after you have applied the QoS to the correct interfaces, it does not help when a really long download is saturating the ISP link. Those VoIP packets don't have a chance getting down in time from the Internet to your network over that saturated pipe!

So how do we correct these. I used a nested policy on both the outside and inside interfaces of the firewall. The policy on the inside acts on the egress interface and therefore will impact the inbound traffic from the Internet whereas the outside one impacts the outbound traffic toward the Internet. Unfortunately, you've got to sacrifice the data bandwidth for this solution to work but there is no way around it. In my opinion it's a small price to pay.

Each call takes up about 80Kbps in our example and we have had about 10 simultaneous calls in the past  so I reserved 1Mbps of our 3Mbps Internet pipe for voice traffic. This implies that the data traffic (or all but voip traffic) can share 2Mbps. To do this, you shape the default class to 2Mbps and nest the voice policy so that the voip traffic is omitted from shaping (or drops) which will give it the remaining 1Mbps. Since I had a symmetrical 3Mbps Internet connection, I applied 2Mbps of traffic shaping to both interfaces. Change the shape rate accordingly if you have asymmetrical speeds.

Here's the relevant ASA 5505 configs with some explanations.

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address i.i.i.i 255.255.255.248
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
!I expect you to limit the udp ports to just what your provider has recommended. !I opened up all udp just to keep things simple
!
access-list outside_access_in extended permit udp any any 
!
!Although I used the entire subnet to classify the voip packets, please
!feel free to use dscp, precedence or ports instead
!
!Inbound voip traffic classification
access-list voip_inside extended permit ip any 10.16.1.0 255.255.255.0
!
!outbound (toward Internet) voip traffic classification
access-list voip_outside extended permit ip 10.16.1.0 255.255.255.0 any
!
global (outside) 1 70.35.47.195 netmask 255.255.255.255 nat (inside) 1 10.0.0.0 255.0.0.0 ! access-group outside_access_in in interface outside route outside 0.0.0.0 0.0.0.0 i.i.i.a 1 !
!Enable the piority queues on both interfaces
priority-queue inside
priority-queue outside
!
!Define the class maps for both inbound and outbound voice traffic and prioritize
!the voice traffic
!
class-map voice-inside-class
 match access-list voip_inside
class-map voip-outside-class
 match access-list voip_outside
!
policy-map global_policy
 class inspection_default
  inspect dns migrated_dns_map_1
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect netbios
  inspect tftp
!
policy-map outside-policy
 class voip-outside-class
  priority
policy-map inside-policy
 class voice-inside-class
  priority
!
!Nested policy. Shapes all but VoIP traffic inbound from ISP at 2Mbps.
policy-map ins-policy
 class class-default
  shape average 2000000 8192
  service-policy inside-policy
!
!Nested policy. Shapes all but VoIP traffic outbound to ISP at 2Mbps.
policy-map out-policy
 class class-default
  shape average 2000000 8192
  service-policy outside-policy
!
service-policy global_policy global
service-policy ins-policy interface inside
service-policy out-policy interface outside

This will protect those sensitive real time packets in both directions but remember the bandwidth sacrifice!

Saturday, August 11, 2012

Cisco ASA Management over VPN Client

Here is an example of a working configuration on version 8.4 to manage (via ssh and http or ASDM) a Cisco ASA over a VPN client.

interface GigabitEthernet0/0

 nameif untrust
 security-level 0
 ip address 1.1.5.7 255.255.255.0
!
interface GigabitEthernet0/1
 nameif trust
 security-level 100
 ip address 10.99.18.240 255.255.255.224

ip local pool vpnpool 10.99.81.1-10.99.81.254 mask 255.255.255.0


management-access trust


nat (trust,untrust) source static 10.99.0.0 10.99.0.0 destination static 10.99.81.0 10.99.81.0 route-lookup


ssh 10.99.81.0 255.255.255.0 trust

http 10.99.81.0 255.255.255.0 trust

This allows you to hit the trust interface with ASDM or ssh after you VPN into the Cisco ASA. Note that the 'route-lookup' switch under the nat (exempt) rule is often overlooked!


_k

Wednesday, January 18, 2012

SSL Wildcard Certificate Installation on Cisco ASA 8.x

After searching high and low for instructions, I finally found this link that was most useful:

http://serverfault.com/questions/32443/any-problems-usinga-godaddy-ssl-certificate-on-a-cisco-asa-firewall


Here is the solution taken from the link above:


I have a GoDaddy (standard, not deluxe) wildcard certificate that I use on my ASA 5510 for ASDM access. ASDM says that "SSL parameters affect both ASDM and SSL VPN access," so if it works for me, it should for you and SSL VPNs.


I did have problems importing a .pem version of my certificate chain. Using a *.pfx (like IIS uses) worked fine.
I grabbed gd_intermediate.crt from https://certs.godaddy.com/Repository.go

In ASDM, Configuration, Device Management, Certificate Management, CA Certificates; click Add, don't change any defaults, install from file, locate the gd_intermediate.crt file.

I also tried loading gd_bundle.crt which some of our certs use and that failed, but since gd_intermediate.crt worked and that's what my wildcard uses, I didn't test any more.

Once the intermediate cert is loaded, go to Identity Certificates (right above CA Certificates) and do something similar (Add, import from file, chose the .pfx file, and enter the password for the .pfx.

Now that the cert is successfully installed, set which interfaces it will be used on. That's under Device Management, Advanced, SSL Settings. Click the interface (probably outside), click Edit, and choose the Trustpoint name of the certificate you added in the last step. Click OK, Apply, and try going to your https://vpn.url and see if it loads the right cert.

Thanks to serverfault.com.

Wednesday, April 13, 2011

Cisco ASA 5500 7.2x to 8.4x upgrade

I just completed this upgrade on two firewalls and want to share some issues I encountered. Our firewalls were using the following basic features:
  • IPSEC VPN client
  • Site to Site IPSEC VPN tunnel
  • PAT
  • Static NATs
  • NAT exempt 
Firstly the image boots up and the new asdm works. You should have no concern about the ASA not booting up. In fact I had to do one that was located in a Data Center in Chicago and we were in California!
  1. The known documented issue with the nat exempt command must be taken care of. The keyword unidirectional is added to the nat exempt (nat 0) rule which must be changed to bidirectional for each nat exempt command you have.
  2. Since the new access rules now references the real IPs of translated addresses I found that none of these got changed on my outside access list! I had to change each ACL entry manually from the public address to its private IP address. 
  3. There is a site to site IPSEC VPN tunnel built that references a translated IP of a local host in the encryption domain. The conversion process added a nat exempt rule for the encryption domain! This, of course, prevented the local host from being translated when it was trying to connect to the remote host across the tunnel. No match was found and so the tunnel never gets established! I removed that nat exempt rule to fix.
That's it! All the best in your upgrades.

Here is the Cisco reference to the 8.4x release notes.

Thursday, March 26, 2009

These Cisco ASA VPN Filters Could Trip You Up!

This filter put a little twist into my powers of reasoning but I finally figured it out.

In our example, a Cisco ASA 5510 is serving as a VPN concentrator to which we have built a LAN to LAN IPSEC Tunnel from a customer peer (192.168.103.41). Basically, a host on the customer end (192.168.48.130) transfers files over the NDM protocol (tcp/1364) to our server (10.122.52.12) and sometimes our server (10.122.52.12) has to do the same to their server.

Summary of traffic over the tunnel:

192.168.48.130 --> 10.122.52.12 (tcp/1364)
10.122.52.12 --> 192.168.48.130(tcp/1364)

Our aim is to build the VPN tunnel when traffic between the two servers is present but limit the traffic to just the NDM protocol.

Configuration Steps

1. First you want the VPN traffic to bypass the filter you have on the interface that the tunnel terminates because we don't want another filter for this traffic. In our case this is the 'untrust' interface. Use this command:

sysopt connection permit-vpn

2. Now define the encryption domain for the tunnel and the Phase 1 (ISAKMP) and Phase 2 (IPSEC) parameters. Whenever, the ASA 'sees' this traffic, it will start the process of bringing up the VPN tunnel.

access-list kis1-vpn-traffic line 1 extended permit ip host 10.122.52.12 host 192.168.48.130

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map untrust_map 10 match address kis1-vpn-traffic
crypto map untrust_map 10 set peer 192.168.103.41
crypto map untrust_map 10 set transform-set ESP-3DES-SHA
crypto map untrust_map 10 set security-association lifetime seconds 28800
crypto map untrust_map 10 set security-association lifetime kilobytes 4608000
crypto map untrust_map interface untrust

crypto isakmp identity address
crypto isakmp enable untrust
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

3. With code 7.x on, you need to define tunnel group parameters first before the IPSEC tunnel will establish. This is where you define the pre-shared key and the filter that acts on the traffic within this tunnel

access-list kis1-vpn-filter line 1 extended permit tcp host 192.168.48.130 eq 1364 host 10.122.52.12
access-list kis1-vpn-filter line 2 extended permit tcp host 192.168.48.130 host 10.122.52.12 eq 1364

group-policy kis1-group-policy internal
group-policy kis1-group-policy attributes
vpn-filter value kis1-vpn-filter

tunnel-group 192.168.103.41 type ipsec-l2l
tunnel-group 192.168.103.41 general-attributes
default-group-policy kis1-group-policy

tunnel-group 192.168.103.41 ipsec-attributes
pre-shared-key *

4. Now let's take a closer look at the filter 'kis1-vpn-filter'. It has the familiar format where in this case, the source address is the far end address (customer host), while the destination address is the local host (10.122.52.12). Line 2 is very logical - it is allowing their host (192.168.48.130) to send traffic to our host (10.122.52.12) on tcp/1364. Nothing wrong here.

The confusion arrives in Line 1. This line permits the local host to send traffic to their host on tcp/1364! So it appears that the filter does not act on the traffic leaving the local host to the remote host, but acts on the return traffic only. Without this you will not make a connection from your local host to the remote host. Seems easy now... :o)