Cisco cable-diagnostics with TDR

Some Cisco switches have a way to check the condition of copper cables. This can be done via de command test cable-diagnostics tdr. TDR stands for Time Domain Reflector. More information about Time Domain Reflector can be found at the Cisco Support Community.

The command can be very useful for basic layer 1 troubleshooting.

core01#test cable-diagnostics tdr int gig 5/0/21
TDR test started on interface Gi5/0/21
A TDR test can take a few seconds to run on an interface
Use ‘show cable-diagnostics tdr’ to read the TDR results.
core01#show cabl
core01#show cable-diagnostics tdr int gig 5/0/21
TDR test last run on: August 26 10:10:28

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi5/0/21  1000M Pair A     5    +/- 10 meters Pair A      Normal
Pair B     4    +/- 10 meters Pair B      Normal
Pair C     4    +/- 10 meters Pair C      Normal
Pair D     4    +/- 10 meters Pair D      Normal

The output above shows a successful measurement. The next example shows a failing cable-diagnostics test.

core01#test cable-diagnostics tdr interface gigabitEthernet 5/0/22
Link state may be affected during TDR test
TDR test started on interface Gi5/0/22
A TDR test can take a few seconds to run on an interface
Use ‘show cable-diagnostics tdr’ to read the TDR results.
core01#show cable-diagnostics tdr interface gig 5/0/22
TDR test last run on: August 26 10:04:43

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi5/0/22  100M  Pair A     N/A                Pair B      Normal
Pair B     N/A                Pair A      Fail
Pair C     N/A                Pair D      Normal
Pair D     N/A                Pair C      Normal

Sophos UTM – An unsupported mechanism

I got some strange issues / problems while testing a Sophos UTM appliance with 9.004-34 software. The Web Security feature is filtering requests and using client authentication. The proxy is using Standard Mode with Active Directory SSO authentication. I testing the proxy by changing the proxy settings on a Citrix server. Everything was working without any problems. Next I tried some standalone workstations and laptops, including my own.

I wasn’t able to authenticate. I got an Authentication Failed in my browser and noticed the following entry in the Web Filter logging.

adir_auth_process_negotiate (auth_adir.c:311) gss_accept_sec_context: An unsupported mechanism was requestedNo error

I didn’t know where to look. I tried different things, like rejoining the Sophos UTM in Active Directory, rebooting the appliance and changing the proxy settings. When using the IP address of the Sophos UTM in the proxy settings the authentication mechanism NTLM is being used. When using the hostname or an DNS alias the authentication mechanism Kerberos is being used.

After some more testing I noticed that authentication failures only occurred when using Kerberos authentication. I did some more research on the internet and I found a lot of people complaining about this issues and blaming the “Windows Live ID Sign-In” component. My browser included this add-on. I disabled it in Internet Explorer, but that didn’t help. I stopped the service via msconfig, but that didn’t help either. Eventually I uninstalled the complete Windows Live Essentials suite from my laptop. This solved the problem!!!

Uninstalling the Windows Live Essentials component from the other laptops and workstations also resolved their problems. Till now I still don’t know why Windows Live Essentials “breaks” the Kerberos authentication process.

Citrix Secure Gateway via https-only

Configuring a Citrix Secure Gateway (CSG) server is simple, but provides a powerful solution to access resource from remote locations. CSG is an application installed on a DMZ server. Mostly I also configure the Citrix WebInterface on the same server. The CSG instance listens on TCP/443 and the WI instance listens on TCP/80. To improve the user friendliness of the solution you have to configure a redirect. This redirect changes the protocol from the unsecure http protocol to the secure https protocol. It also redirect the user to the correct login portal, like redirecting http://portal.booches.nl to https://portal.booches.nl/Citrix/XenApp/auth/login.aspx. The HTML code for the redirect is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Refresh" content="1 ;URL=https://portal.booches.nl/Citrix/XenApp/auth/login.aspx" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Citrix Secure Gateway-Booches</title>
</head>
<body>  
<p>
        Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
</p>
</body>
</html>

This configuration requires you to allow the http and https protocols from the internet to the server. When accessing the login page the remote user connects to the CSG instance over https and the CSG instance connects to the WI instance over http. A customer noticed that a user could change the login URL from https to the unsecure http. This means that the remote user connects directly to the WI instance and bypasses the CSG instance. This behavior is not allowed and also unsecure, because username and password are sent clear text over the internet.

I wanted to change this behavior so the user isn’t allowed to connect over http to the login page, but the default redirect from http to https should still be allowed. I looked at solutions on the internet to redirect all IIS traffic from http to https, but this introduced some problems and errors. In the end I simply configured IP Address and Domain Restriction on the /Citrix/XenApp virtual directory. Only the CSG instance needs to connect to the WI instance, so the IP restrictions only allow the localhost and the server IP address. I also changed the default behavior to deny all unspecified clients.

csg-wi-ip

Aruba WPA2 with MAC authentication

Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.

These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.

While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.

The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.

Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP=0.0.0.0 auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=0.0.0.0 User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing

To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.

I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.

aaa profile "WA-Test_aaa_prof"
   initial-role "denyall"
   authentication-mac "MAC_auth_prof"
   mac-default-role "WA-Test_role"
   mac-server-group "MAC-auth_srv"
   authentication-dot1x "default-psk"
   enforce-dhcp

Cisco DHCP server & VRF

I had some issues while configuring some VRF’s on a Cisco router and using that router as a DHCP server. First of all the router wasn’t binding any DHCP request. The DHCP server configuration is defined below.

ip dhcp pool guest
vrf vrf-guest
network 10.10.0.0 255.255.252.0
default-router 10.10.0.1
domain-name internet-only.nl
dns-server 208.67.222.222 208.67.220.222

The configuration of the DHCP server is very straightforward. Exception is the use of the VRF interface to bind the DHCP server to. With this configuration the DHCP server isn’t working, because no IP addresses are bind to clients.

The magic to get DHCP working is found in the command ip dhcp use vrf connected. More information about the command can be found here or here.

The second issue is about configuring some IP address exclusions for the configured pool. This can be done via the command ip dhcp excluded-address vrf <vrf-name> <first ip-address> <last ip-address> (info). Depending on the IOS version used, this command isn’t available in CLI. I had this issue with the CIsco 2811 I was using, so I tried to ip dhcp class command. I added the following to the configuration of the DHCP server.

ip dhcp class dhcp_class_unsecure
remark limit IP addresses
!
ip dhcp pool unsecure
vrf unsecure
network 172.16.252.0 255.255.252.0
default-router 172.16.252.1
domain-name internet-only.nl
dns-server 208.67.222.222 208.67.220.220
class dhcp_class_unsecure
address range 172.16.253.1 172.16.253.255

This isn’t exactly the same as configuring IP exclusions, because the ip dhcp class command is used to group clients on specific characteristics. Clients that match these characteristics are assigned an IP address from the specific class. In my situation the use of the ip dhcp class command fixed the problem.