Booches.nl

NBAR and smart filtering

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#configure terminal
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#configure terminal
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.

RTR#configure terminal
RTR(config)#policy-map pm-blocked-content
RTR(config-pmap)#class cm-blocked-content
RTR(config-pmap-c)#drop

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#configure terminal
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

Vlan1

 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
   drop

  Class-map: class-default (match-any)
   111703 packets, 12021043 bytes
   5 minute offered rate 33000 bps, drop rate 0 bps
   Match: any
RTR#

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.

Cisco ASA remote management via VPN

By default, remote access VPN users aren’t able to manage a Cisco ASA firewall on the inside interface using any kind of management protocol (SSH, telnet, HTTPS).

You can enable remote management by specifying the management-access interface. You can specify the interface via the CLI or via the Cisco Adaptive Security Device Manager (ASDM). Both methods are specified below.

CLI

fw01/booches.nl/act# configure terminal
fw01/booches.nl/act(config)# management-access inside

ASDM

When using the Management Access feature with remote VPN connections (IPSec or SSL VPN) don’t forget to add the VPN pool to the corresponding management access protocols on the interface you specified as management access interface

XS4ALL, Cisco 877 and IPv6

A while ago my ISP XS4ALL started with the distribution of IPv6 prefixes to their customers. So as a network engineer I wanted to have my own /48 prefix. Sadly I didn’t had time to start testing at the beginning of the IPv6 “launch”.

Last week I found some time to start my testing. I started by configuring my external DSL interface to run in dual-stack mode. The IPv4 configuration is straightforward and isn’t part of this article.

Below you see the basic configuration of the Dialer interface to enable IPv6. The commands configure the Dialer interface as DHCP client (autoconfiguration on the interface) and the prefix delegation name is “my_prefix”.

interface Dialer1
ipv6 address autoconfig
ipv6 enable
ipv6 dhcp client pd my_prefix rapid-commit
end

You can check the allocation of the IPv6 address prefix with the following command:

C877W#show ipv6 general-prefix
IPv6 Prefix prefix_ipv6, acquired via DHCP PD
2001:980:3441::/48 Valid lifetime , preferred lifetime
BVI1 (Address command)

More information about the allocation can also be obtained with the following command:

C877W#show ipv6 dhcp interface
Dialer1 is in client mode
State is OPEN
Renew will be sent in 00:11:48
List of known servers:
Reachable via address: FE80::90:1A00:1A1:88E6
DUID: 000200000A4C453332302F373435414333334558322F01
Preference: 0
Configuration parameters:
IA PD: IA ID 0×00100001, T1 3600, T2 5760
Prefix: 2001:980:3441::/48
preferred lifetime 7200, valid lifetime 7200
expires at Jan 31 2011 12:24 PM (4310 seconds)
DNS server: 2001:888:0:6::66
DNS server: 2001:888:0:9::99
Information refresh time: 0
Prefix name: my_prefix
Rapid-Commit: enabled

Now you need to configure IPv6 routing, especially the default route and enabling unicast-routing, with the following commands:

ipv6 unicast-routing

ipv6 route ::/0 Dialer1

The next step involves the configuration of the LAN interface to support IPv6. RFC 3177 recommends the delegation of /48 prefixes to home network subscribers, small and large organizations. It looks like my ISP follows that recommendation. The same RFC states that a /64 prefix should be assigned to different host subnets. So I can configure 2^16 host subnets and each subnet can contain 2^64 IPv6 addresses. Seems enough for my home environment.

The inside interface (a Bridged Virtual Interface in my scenario) is configured with the following /64 prefix.

ipv6 address my_prefix 0:0:0:1::/64 eui-64

You can use the following command to look at the IPv6 configuration of the different interfaces.

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1::FFFF
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684

The basic IPv6 configuration is done. The next step is testing IPv6 connectivity via an IPv6 ping to ipv6.google.com

C877W#ping ipv6 2a00:1450:8005::68 source bvi1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A00:1450:8005::68, timeout is 2 seconds:
Packet sent with a source address of 2001:980:3441:1::FFFF
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms

Ping can reply with different characters. The characters are listed below.

Prefix Delegation (PD) in IPv6 is very useful when deploying IPv6 in the network. The deployment of IPv6 to hosts also involves the distribution of additional parameters, like IPv6 DNS servers. The next step involves the configuration of Router Advertisement (RA) messages on the Bridged Virtual Interface.

I configured an DHCPv6 pool and configured the BVI interface as DHCP server interface with the following commands:

ipv6 dhcp pool ipv6_inside
dns-server 2001:888:0:6::66
domain-name booches.nl
!
interface BVI1
ipv6 address my_prefix 0:0:0:1::/64 eui-64
ipv6 nd other-config-flag
ipv6 dhcp server ipv6_inside rapid-commit
end

The other-config-flag sets the O-bit in IPv6 RA messages to inform hosts that they can use autoconfiguration for their IPv6 configuration. This results in DHCPv6 INFORMATION-REQUEST messages from the hosts to the DHCPv6 server. The router will reply to these message, because it is configured as DHCP server for the prefix.

I started testing, but my hosts didn’t receive any IPv6 address and debugging IPv6 on the router didn’t output any useful information. Of course the hosts couldn’t receive any IPv6 address, because of the well-known bug CSCej50923 (CCO ID required) on BVI interface routing, which does not work for IPv6 addressing. I didn’t want to upgrade my router directly, so I created another VLAN with the appropriate Switched Virtual Interface. I configured the same commands as under the BVI interface, but this time with prefix 0:0:0:2::/64. Now I have 3 interfaces enabled for IPv6 addressing, like shown below:

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1:21A:6DFF:FE7D:B684
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684
Vlan2                      [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:2:21A:6DFF:FE7D:B684

You can see the difference in the prefix between BVI1 and Vlan2. I issued a ipconfig /release6 and ipconfig /renew6 on the hosts and IPv6 is working like a perfectly.

The complete output of the ipconfig /all and a ping to ipv6.google.com can be found below.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : booches.nl
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : 00-25-64-F6-1C-D7
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:980:3441:2:c527:8966:a47f:55d2(Preferred)
Temporary IPv6 Address. . . . . . : 2001:980:3441:2:cd4d:b38b:e861:f43(Preferred)
Link-local IPv6 Address . . . . . : fe80::c527:8966:a47f:55d2%11(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.2.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, January 31, 2011 4:02:01 PM
Lease Expires . . . . . . . . . . : Thursday, February 03, 2011 4:02:00 PM
Default Gateway . . . . . . . . . : fe80::21a:6dff:fe7d:b684%11
10.10.2.1
DHCP Server . . . . . . . . . . . : 10.10.2.1
DHCPv6 IAID . . . . . . . . . . . : 234890596
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-65-AE-74-00-25-64-F6-1C-D7

DNS Servers . . . . . . . . . . . : 2001:888:0:6::66
10.10.2.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
booches.nl

C:\Users\RJN>ping ipv6.google.com

Pinging ipv6.l.google.com [2a00:1450:8005::68] with 32 bytes of data:
Reply from 2a00:1450:8005::68: time=29ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=26ms

Ping statistics for 2a00:1450:8005::68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 28ms, Average = 26ms

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.

XenServer and Multicast with IGMP support

Today I tried to add a virtual Terminal Server within a XenServer to a NLB cluster. The current NLB cluster contained only physical servers. When adding the virtual server to the NLB cluster with the NLB manager, the server lost all IP communication. It isn’t possible to connect to or from the server. Together with the system administrator, we searched multiple forums and we found the solution to the problem.

It looks like XenServer doesn’t support multicast by default, because of the bridge design of the network interfaces. We found an interesting article on the internet to enable multicast on the virtual interface.

In the end we took the following steps to enable multicast support on the virtual interface of the XenServer.

1. 1. Install the XenServer tools on the virtual server;
2. 2. Execute the ifconfig command, like shown below, to enable multicast on the virtual interface;

# Retrieve the DOMID of the virtual server
xe vm-list name-label=<VMNAME> params=dom-id

# Enable multicast on the virtual interface of the virtual server
ifconfig vif<DOMID>.0 multicast

We restarted the virtual server and the DOMID changed, but multicast with IGMP support was still working and the server was still part of the NLB cluster. The system administrator will do some more testing and he will try to add another virtual server to the NLB cluster.