ASA Service Policies

  • Post author:
  • Post category:ASA / Cisco

The Cisco ASA firewall, Service Policies use the Modular Policy Framework (MPF) to provide a flexible way to configure ASA features, such as connection settings, inspection, QoS, redirection to service modules etc.

A Service Policy is composed of the following elements:

  • A Layer 3/4 class-map is used to identify the Layer 3/4 traffic to apply actions.
  • A Policy Map takes an action on the traffic matched in the associated class-map
  • You can only apply 1 Policy Map per interface
  • A packet can only match one class-map in the policy-map for each feature.
  • When a packet matches a class-map, no further processing of the other class-maps is attempted.

A Service Policy applies the advanced services to the traffic permitted by the ASA

  • One global policy that is applied to all interfaces.
  • One service policy per interface.
  • Interface service policies on ingress interfaces take precedence over the global service policy.

The configuration below represents the default Policy Map and Service Policy settings (enabled globally).

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
!
policy-map global_policy
 class inspection_default
  inspect ip-options
  inspect netbios
  inspect rtsp
  inspect sunrpc
  inspect tftp
  inspect xdmcp
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect esmtp
  inspect sqlnet
  inspect sip
  inspect skinny
!
service-policy global_policy global

Scenarios

To demonstrate ASA Service Policies, the following scenarios will be configured:

  • Set Connection Settings
  • Decrement TTL
  • Disable TCP randomisation

Connection Settings

This scenario is demonstrated using different methods to configure the same setting for different protocols.

  • An ACL is used to identify the host using telnet, in conjunction with a class-map to apply the connection settings, with a telnet connection timeout set just for this host at 30 minutes.
  • In the second example, the traffic is matched on the SSH TCP port using a class-map, which applies to all traffic, with an SSH connection timeout set for 5 hours.
access-list TELNET-CONN extended permit tcp host 192.168.251.1 any eq telnet
!
class-map TELNET
 match access-list TELNET-CONN
!
class-map SSH
 match port tcp eq ssh
!
policy-map SVC-POL
 class SSH
  set connection timeout idle 05:00:00
 class TELNET
  set connection timeout idle 00:30:00
!
service-policy SVC-POL interface INSIDE

Decrement TTL

By default, the ASA does not appear as a hop when tracerouting through the ASA. By setting the decrement TTL (time to live) setting, the ASA will appear as a hop in a traceroute.

class-map TTL
 match any
!
policy-map SVC-POL
 class TTL
  set connection decrement-ttl
!
service-policy SVC-POL interface INSIDE

TCP Randomisation

When BGP MD5 authentication is used between 2 peers either side of the ASA, the TCP sequence number is used in conjunction with the MD5 password to create a hash number. By default, the ASA randomises the sequence number. When the receiving BGP peers receives the BGP packet, it compares the hash number that is included in the packet. As the ASA has randomised the TCP sequence number, BGP MD5 authentication will fail. TCP randomisation can be explicitly disabled per connection.

access-list BGP extended permit tcp any any eq bgp
!
class-map BGP
 match access-list BGP
!
policy-map global_policy
  class BGP
  set connection random-sequence-number disable

Verification

For each scenario, we will confirm the outcome of using the default ASA settings and then the compare the result of configuring the service policy.

Traceroute through the ASA

Traceroute through the ASA to a destination on the far side, note only 1 hop (which is not the IP address of the ASA).

HQ-LAN-RTR#traceroute 1.1.3.1
Type escape sequence to abort.
Tracing the route to 1.1.3.1
VRF info: (vrf in name/id, vrf out name/id)
  1 1.1.1.254 8 msec 18 msec *

 With the decrement-ttl setting configured in the service policy, run a traceroute through the ASA again. From the output below, we can now determine the ASA IP address (192.168.250.1) appears as a hop in the traceroute.

HQ-LAN-RTR#traceroute 1.1.3.1
Type escape sequence to abort.
Tracing the route to 1.1.3.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.250.1 7 msec 5 msec *
  2 1.1.1.254 11 msec 7 msec *

Timeout Connection Testing

The TCP idle connection time is 1 hour, to confirm this run show run | inc timeout below is the output of the default settings. 

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 sctp 0:02:00 icmp 0:00:02

This default settings can also be confirmed by establishing a TCP connection through the ASA and running show conn detail, note the timeout of 1h0m. 

TCP OUTSIDE: 1.1.3.1/23 INSIDE: 192.168.251.1/56258,
    flags UIO , idle 2s, uptime 2s, timeout 1h0m, bytes 698

With the Service Policies configured, from a client device with the IP address as defined in the ACL (192.168.251.1) and connect to a device on the other side of the ASA using telnet. From the output below, we can confirm the source IP address of 192.168.251.1 and the timeout is now 30minutes, rather than the default of 1hour.

ASA(config)# show conn detail | begin OUTSIDE
TCP OUTSIDE: 1.1.2.1/23 INSIDE: 192.168.251.1/16569,
    flags UIO , idle 20s, uptime 20s, timeout 30m0s, bytes 698

Repeat the same test from a different IP address, that is not defined in the ACL. From the output below we can determine the TCP port 23 (telnet), from a source IP address of 192.168.252.1 and a timeout of 1 hour. This is inheriting the default timeout settings that is configured globally.

ASA(config)# show conn detail | begin OUTSIDE
TCP OUTSIDE: 1.1.2.1/23 INSIDE: 192.168.252.1/62088,
    flags UIO , idle 1s, uptime 1s, timeout 1h0m, bytes 698

Run another test and connect to a device using SSH. From the output below, we can confirm that the timeout is 5 hours for the SSH connection.

ASA(config)# show conn detail | begin OUTSIDE
TCP OUTSIDE: 1.1.3.1/22 INSIDE: 192.168.251.1/26477,
    flags UIO , idle 2s, uptime 2s, timeout 5h0m, bytes 3015

BGP MD5 Authentication Testing

With BGP MD5 authentication configured between 2 routes either side of the ASA, by default the authentication will fail with the following error.

*May 29 15:34:53.045: %TCP-6-BADAUTH: Invalid MD5 digest from 192.168.250.2(51922).

With the TCP randomisation setting disabled for BGP connections through the ASA, the BGP adjacency should be established through the ASA.

RTR#show ip bgp neighbors | inc state
  BGP state = Established, up for 00:02:49
  Do log neighbor state changes (via global configuration)
Tags: , ,