Connecting the world…

multiple

Cisco ASA: multiple context and capture

Packet captures are very useful for troubleshooting purposes. The Cisco ASA supports packet captures even in multiple context mode. I normally configure packet captures on CLI level. This can be done by configuring an access-list to match the specific traffic you would like to capture. Add the access-list and the specific interface in a capture command. Mostly I download the capture in raw format for further analysis with a tool like WireShark. The capture can be downloaded via TFTP or via a secure connection (HTTPS) to the Cisco ASA firewall.

When running a Cisco ASA in multiple context mode, I always disable the ability to connect directly to a context for management purposes. That way you have to access the admin context for management access, but this also denies the option to download the capture via a secure connection directly from the Cisco ASA traffic context.

The easiest way to download the capture in multiple context mode is via a TFTP transfer from the system context. Check the example command below. The capture is made within the context named contextA and the capture has the name captureA. The following command can be used to download the capture in raw (pcap) format.

copy /pcap capture:contextA/captureA tftp://10.10.10.10/captureA.pcap

You can now analyse the capture with WireShark

MAB and MDA in an IP Phone environment

I blogged before about the MAC Authentication Bypass (MAB) feature in network environments. MAC Authentication Bypass can be used to secure the wired network by verifying MAC addresses to a central database. By using a radius server, like Microsoft IAS or FreeRadius, you can also redirect verified MAC addresses to a specific VLAN.

Lately I had a new challenge with configuring MAB. These time a single switch port is shared by an IP phone and a workstation. The IP phone is used as a kind of switch. The backend switching network is build on Cisco Catalyst switches. All IP phone traffic is handled by the voice VLAN and all data traffic is handled by  the an access VLAN. The IP phones used in this situation are Mitel 5330 phones. These phones support CDP and also LLDP, which is perfect when using a voice VLAN.

The customer would like the MAC addresses of both devices verified against a central database. In this situation I used Microsoft IAS, because the customer is using Microsoft Active Directory as central database. In Active Directory I created an OU structure with an unique OU and security group for every logical group. So I created an OU voice and a security group voice, and I created a group data and an OU data. The MAC addresses of the components need to be added to Active Directory as users. The account name and the password are exactly the same and equal to the MAC address, like 001f22d712ef. I made the account for the IP phone member of the voice group and the account of the workstation member of the data group.

I started with just connecting a single workstation to the switch and configured IAS to verify the MAC address and automatically redirect the workstation to the correct access VLAN. The configuration of IAS is straightforward. First I installed IAS and registered the service in Active Directory. I added the switch as radius client and configured a radius policy for the data connections. The radius policy checks if the MAC address is member of the data group and returns the access VLAN if the MAC address is positively verified. This works without any problems. The screenshots below show the most important configuration of this policy.

data-radius-match data-radius-authentication data-radius-attribute

Next you see the switch configuration so far.

aaa new-model
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
dot1x system-auth-control
!
interface FastEthernet0/35
switchport access vlan 102
switchport mode access
switchport nonegotiate
switchport voice vlan 150
authentication control-direction in
authentication port-control auto
authentication periodic
authentication timer restart 900
authentication timer reauthenticate 5400
mab
spanning-tree portfast
spanning-tree bpduguard enable
end

I configured another policy, exactly the same, for the voice components. I disconnected the workstation and connected the IP phone to the network. This also works without any problems. The IP phone is authenticated and allowed access to the network. Next I connected the workstation to the IP phone and booted the workstation. I noticed that the IP phone lost his power and checked the switch port status. The switch port went in err-disable state with the following message:

Feb  5 08:54:50.095 GMT+1: %AUTHMGR-5-SECURITY_VIOLATION: Security violation on the interface FastEthernet0/35, new MAC address (0080.647f.c590) is seen.
Feb  5 08:54:50.095 GMT+1: %AUTHMGR-5-SECURITY_VIOLATION: Security violation on the interface FastEthernet0/35, new MAC address (0080.647f.c590) is seen.
Feb  5 08:54:50.095 GMT+1: %PM-4-ERR_DISABLE: security-violation error detected on Fa0/35, putting Fa0/35 in err-disable state

This is a big problem, because both network components aren’t able to communicate with the network. I did some research and found the Multiple Domain Authentication (MDA) feature. Multiple Domain Authentication (MDA) allows both a data device and a voice device, such as an IP phone (Cisco or non-Cisco), to authenticate on the same switch port, which is divided into a data domain and a voice domain. This feature is configured with the authentication host-mode commands and is very useful when combining IEEE 802.1x and/or MAB in an IP phone environment. The following host-modes can be used:

Single-host mode should be configured if only one data host is connected. Do not connect a voice device to authenticate on a single-host port. Voice device authorization fails if no voice VLAN is configured on the port.

Multi-domain mode should be configured if data host is connected through an IP Phone to the port. Multi-domain mode should be configured if the voice device needs to be authenticated.

Multi-auth mode should be configured to allow up to eight devices behind a hub to obtain secured port access through individual authentication. Only one voice device can be authenticated in this mode if a voice VLAN is configured.

Multi-host mode also offers port access for multiple hosts behind a hub, but multi-host mode gives unrestricted port access to the devices after the first user gets authenticated.

I tested the multi-host configuration and it did exactly as explained above. Only one device is authenticated and all next device are allowed without authentication. In my situation I have to use multi-domain. I added the configuration line authentication host-mode multi-domain to the interface configuration above. After this I had a new problem. Both devices are authenticated correctly, but the Mitel IP phone got stuck at DHCP Discovery, while the workstation is working correctly.

After some sniffing I saw the Mitel phone sending its DHCP Discovery to the data VLAN, but the phone didn’t receive any DHCP Offer from a DHCP server. Back to the drawing table and I found the solution in the radius configuration. I configured the radius attribute cisco-av-pair in order to tell the switch that the IP phone is allowed on the voice VLAN, see the picture.

MAB-MDAThe following steps are taken during the process:

  1. 1. The IP Phones learns the voice VLAN ID from CDP;
  2. 2. The switch learns the MAC address of the phone and sends an Accept-Request for the phones MAC address to the radius server;
  3. 3. The radius server responds with an Access-Accept and adds the Vendor-Specific Attribute (VSA) Cisco-AV-pair with the value device-traffic-class=voice;
  4. 4. All traffic from the IP Phone is allowed in the voice VLAN and the DHCP process works flawlessly;
  5. 5. The workstation is also authenticated by the radius server and all data traffic is allowed in the data VLAN;

The radius policy for the voice VLAN is almost equal to the radius policy for the data/access VLAN. The only difference is in the radius attributes. Below you see the attributes for the voice radius policy.

voice-radius-attributeI did some testing and the environment is working perfectly. Both devices are authenticated separately from each other. The final configuration of the switch port looks like this:

interface FastEthernet0/35
switchport access vlan 102
switchport mode access
switchport nonegotiate
switchport voice vlan 150
authentication control-direction in
authentication host-mode multi-domain
authentication port-control auto
authentication periodic
authentication timer restart 900
authentication timer reauthenticate 5400
mab
spanning-tree portfast
spanning-tree bpduguard enable
end

Below you see some output from the show authentication sessions command. You can clearly see the domain where the device is authenticated in.

ONLY IP PHONE IS AUTHENTICATED SUCCESSFULLY

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5397s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000065C2FF71B0
Acct Session ID:  0x0000014A
Handle:  0x04000065

Runnable methods list:
Method   State
mab      Authc Success

IP PHONE AND WORKSTATION ARE AUTHENTICATED SUCCESSFULLY

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0080.647f.c590
IP Address:  Unknown
User-Name:  0080647fc590
Status:  Authz Success
Domain:  DATA

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Vlan Policy:  102
Session timeout:  5400s (local), Remaining: 5364s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000068C304A7C5
Acct Session ID:  0x0000014D
Handle:  0x56000068

Runnable methods list:
Method   State
mab      Authc Success

—————————————-
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5340s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000067C3043675
Acct Session ID:  0x0000014C
Handle:  0xE2000067

Runnable methods list:
Method   State
mab      Authc Success

IP PHONE IS AUTHENTICATED SUCCESSFULLY, WORKSTATION ISN’T

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0080.647f.c590
IP Address:  Unknown
User-Name:  UNRESPONSIVE
Status:  Authz Failed
Domain:  DATA

Oper host mode:  multi-domain
Oper control dir:  in
Session timeout:  N/A
Idle timeout:  N/A
Common Session ID:  0A0A421B00000066C300CB6C
Acct Session ID:  0x0000014B
Handle:  0xEB000066

Runnable methods list:
Method   State
mab      Failed over

—————————————-
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5261s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000065C2FF71B0
Acct Session ID:  0x0000014A
Handle:  0x04000065

Runnable methods list:
Method   State
mab      Authc Success

Cisco Aironet: multiple SSID’s

I have been playing with some Cisco Aironet’s today. Configuration is quite simple and straightforward, but maybe not for everyone:

  • Broadcast two SSID’s, unsecure and secure
  • Authentication via WPA version 2 pre-shared key
  • Management IP adres in management VLAN

You are maybe thinking: “stand-alone access points, why no WLAN controller?” I agree, but be honest. Would you use a WLAN controller for less then 5 access points?

The snippet below shows the most important configuration for such a scenario.

dot11 mbssid
dot11 vlan-name secure vlan 11
dot11 vlan-name default vlan 1
dot11 vlan-name unsecure vlan 13
dot11 vlan-name management vlan 10
!
dot11 ssid unsecure
vlan 13
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
dot11 ssid secure
vlan 11
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
bridge irb
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption vlan 13 mode ciphers aes-ccm tkip
!
encryption mode ciphers aes-ccm tkip
!
encryption vlan 11 mode ciphers aes-ccm tkip
!
ssid unsecure
!
ssid secure
!
speed  basic-1.0 basic-11.0 basic-54.0
channel 2412
station-role root
!
interface Dot11Radio0.11
encapsulation dot1Q 11
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 11
bridge-group 11 block-unknown-source
no bridge-group 11 source-learning
no bridge-group 11 unicast-flooding
bridge-group 11 spanning-disabled
!
interface Dot11Radio0.13
encapsulation dot1Q 13
ip access-group internet-only in
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding
bridge-group 13 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
!
interface FastEthernet0.10
encapsulation dot1Q 10 native
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 10
no bridge-group 10 source-learning
bridge-group 10 spanning-disabled
!
interface FastEthernet0.11
encapsulation dot1Q 11
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 11
no bridge-group 11 source-learning
bridge-group 11 spanning-disabled
!
interface FastEthernet0.13
encapsulation dot1Q 13
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 13
no bridge-group 13 source-learning
bridge-group 13 spanning-disabled
!
interface BVI10
ip address 10.1.1.200 255.255.255.0
no ip route-cache
!
ip default-gateway 10.1.1.1
!
bridge 1 route ip

I hope this helps when you are configuring a Cisco Aironet with multiple SSID support.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

HA redundancy

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

  • Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
  • Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
  • Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

  • Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
  • Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
  • Multi-context: one physical firewall is divided in more virtual firewalls;
  • Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

  • No support for VPN services;
  • No support for dynamic routing protocols;
  • No way to configure the sharing of CPU usage between contexts;
  • No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.