iPhone – Sleep Timer and playing music

Something completely different in this blog post, so no technical stuff on networking. Last week I visited the Fortinet Global Partner Conference in Las Vegas, NV. Travelling from the Netherlands to Las Vegas and back in 5 days results in a big JET LAG for me!! Not only after the flight from the Netherlands to Las Vegas, but also after the flight back I had some problems with sleeping. I bought and tried to take some extra melatonin. This helps to get you in that “sleepy feeling”, but I still had problems to get to bed during the “regular” hours.

I also like it to listen to music to fall in sleep, but it’s not really helpful when the music keeps playing on all night long. After some toggling on the iPhone I found the Sleep Timer function and the possibility to stop playing music after the Sleep Timer counts back to zero. I tested the functionality successfully with several apps, like Apple Music, Spotify and SoundCloud. I guess more apps will support this functionality. Use the following steps to active the Sleep Timer to stop the music from playing:

  1. Start playing for favorite music. I used Apple Music, Spotify and SoundCloud;
  2. Start the “Clock” app;
  3. Select “Timer” at the bottom;
  4. Set the duration to keep playing music;
  5. Select “Stop Playing” as action for “When Timer Ends”;

Like it or not, but it this definitely helped me….

FortiAuthenticator – HA Clustering

FortiAuthenticator can be used when adding strong authentication to a network. FortiAuthenticator has more options, like FSSO (FortiNet Single Sign-On) in conjuction with a FortiGate firewall. You can create a FortiAuthenticator cluster very easily. I normally configure a active/passive cluster and not a load-balancing cluster. When creating an active/passive cluster you should follow these guidelines:

  1. use port1 as the default (production) port;
  2. use port2 as HA cluster port;
  3. The slave unit can only be managed via port2;
  4. When a failover occurs, the slave takes over the IP address of the masters port1;
  5. The HA IP address is always unique, so I use this IP address to register the licenses for both appliances;
  6. Configure priority High for the master and priority Low for the slave, like show in the image;


Often I use FortiAuthenticator with FortiGate or appliances like Citrix NetScaler or Pulse Secure to enable two-factor authentication. Like I stated above, the slave unit takes over the masters port1 IP address. This implies that you only need to configure one RADIUS server in your front-end appliance. This is not true.

I added the master FAC as RADIUS server to a FortiGate firewall. Authentication is working fine. Next I shutdown the master FAC. The slave unit takes over and the “masters” port1 IP address is accessible, so it can be used for authentication. But when you authenticate to the master IP address something “strange” happens. The slave unit response to the RADIUS request with its own port1 IP address. You can see this in the packet sniffer on the FortiGate below. The master IP on port1 is and the slave IP is I shutdown the master unit and try to authenticate.

BZO-FG500-01 # diagnose sniffer packet any ‘udp and port 1812’
filters=[udp and port 1812]
27.067084 -> udp 129
27.074294 -> udp 40
32.070029 -> udp 129
32.070220 -> udp 40

As you can see the FGT sends the RADIUS request to the master IP, but the slave FAC answers with the IP, so authentication is unsuccessful. I needed to add the slave FAC as well to the FortiGate as RADIUS server to successfully authenticate in the event the primary FAC is lost.

Provision Aruba AP via CLI

Below you will find the necessary commands to provision an Aruba access-point via CLI. The commands add the access-point to the AP whitelist and provision the AP in the correct ap-group. Adding the AP to the whitelist is necessary when using control-plane security.

whitelist-db cpsec add mac-address “94:b4:0f:c4:7e:98” description “ap01”
whitelist-db cpsec modify mac-address “94:b4:0f:c4:7e:98” cert-type factory-cert state certified-factory-cert
clear provisioning-ap-list
provision-ap read-bootinfo ap-name “94:b4:0f:c4:7e:98”
provision-ap copy-provisioning-params ap-name “94:b4:0f:c4:7e:98”
provision-ap installation indoor
provision-ap no external-antenna
provision-ap server-name “aruba-master”
provision-ap ap-group “corp-01”
provision-ap ap-name “ap01”
provision-ap no syslocation
provision-ap no remote-ap
provision-ap reprovision ap-name “94:b4:0f:c4:7e:98”
clear provisioning-ap-list
clear provisioning-params

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.

Aruba RAP in bridge mode with remote access

The Aruba Networks Remote Access Points is a nice feature for branch offices or home workers. I use a RAP5WN at home and I configured different SSID’s on the RAP. The SSID’s are in tunnel mode, split-tunnel mode or bridge mode. The bridge mode connections are for my home devices, like my girls iPad and iPhone.

The RAP5WN has four 10/100 FastEthernet ports. I configured wired ap profiles for these ports and they are also configured in bridge mode. All devices in bridge mode receive an IP address from my local internet router (ADSL) and this works without any problems. Devices in bridge mode can directly communicate with each other.

My local internet router has some port forwarding rules configured so I can access the server from the internet. After using the Aruba RAP and physically moving the server from the local router to the Aruba RAP, I couldn’t access the server anymore. I did some more testing and noticed that I couldn’t connect to any device behind the RAP, when I tried to connect to the devices through the uplink port of the RAP.

I checked the configuration of the RAP and especially the wired AP profiles. I couldn’t find any related configuration parameters to change this behavior. Eventually I found the solution within the AP system profile. The setting Session ACL solved my problem. The explanation for the setting is: Session ACL applied on uplink of a remote AP. By default the session acl parameter is configured as ap-uplink-acl. This acl contains the following entries:

ip access-list session ap-uplink-acl
any any udp 68  permit
any any svc-icmp  permit
any host udp 5353  permit

I changed this setting to the session acl allowall to permit all traffic on the uplink interface.

ap system-profile “custom-ap-system-profile”
session-acl “allowall”
ap-group “home-rap-group”
ap-system-profile “custom-ap-system-profile”

I was able to connect remotely to the server after applying the session acl allowall to the AP system profile, which is connect to the correct AP Group. Problem solved!!