0x8000 is the new 0x4124

On new ISR routers with XE-SDWAN version 16.10.3+, you can only log in with the default password once. Over console, there is a message printed that warns you to change the password, but it can easily get lost in all the other console output. 

Breaking boot and setting the register to 0x4124 doesn’t work as you would expect. To get back in (note, your config will be gone), break boot and config the register to 0xA102 or 0x8000. 

rommon 1 > confreg 0x8000
rommon 2 > i

Then, change the configuration register back to 0x2102 and perform a sdwan software reset. This wipes out all the configuration that exists.

Router# request platform software sdwan software reset

After that, the device will reboot, login with the default admin/admin and this time—set a password. 

Source: How to Recover the Password on XE-SDWAN?

FTD Authentication with Azure MFA

I recently configured Azure MFA to authenticate AnyConnect users connecting to a FTD firewall. This required some odd workarounds.

Problems to work around

  1. FTD cannot do SAML, must use RADIUS for AnyConnect AAA
  2. Microsoft NPS with Azure MFA extension must be used for RADIUS Integration to Azure MFA 
  3. Microsoft NPS has a limited number of attributes it can filter incoming RADIUS requests on
  4. Customer has a need to only allow certain AD groups access to certain tunnel groups

Authentication Flow

  1. Firewall sends Access-Request to ISE 
  2. ISE adds RADIUS:NAS Identifier attribute to Access-Request based on CVPN3000/ASA/PIX7x-Tunnel-Group-Name
  3. NPS filters incoming requests based on NAS Identifier to appropriately authenticate different tunnel groups and does primary authentication against AD.
  4. NPS requests secondary authentication from Azure MFA
  5. Azure MFA completes MFA with user, based on the user’s default MFA method. There is no way to select this during the authentication sequence.
  6. NPS sends result back to ISE
  7. ISE proxies result back to FTD

Authentication Diagram

Ftd anyconnect azuremfa

Identity Services Engine (ISE) Configuration

  • External RADIUS Servers – define your NPS server(s) and shared secret here
  • RADIUS Server Sequence
    • Create a sequence per tunnel group that needs to be differentiated 
    • In the Advanced Attribute Settings tab, add the NAS Identifier attribute

Ise modify attrib

  • Policy Sets
    • Create one policy set per tunnel group
    • Conditions: NAS-Port-Type Virtual AND CVPN3000/ASA/PIX7x-Tunnel-Group-Name = MyGroupName
    • Server Sequence: proxy sequence created above

Network Policy Server (NPS) Configuration

  • Install Azure MFA extension and link to Azure AD – https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension]
    • Protip: use a new NPS server. Once you install the extension, all requests authenticated locally will be subject to MFA
  • RADIUS Clients
    • In the NPS console, configure your ISE servers as RADIUS clients, using the same shared secret as above. 
    • Vendor – RADIUS Standard
  • Network Policies 
    • Create one per tunnel group name
    • Type of network access server – Unspecified 
    • Conditions
      • NAS Identifier – the identifier ISE added
      • User Groups – group you want to filter on 
    • NAS-Port-Type Virtual
    • Authentication Methods – I have them all enabled, including PEAP and EAP-MSCHAPv2 You minimally need PAP, but I have lots of logs that say “Custom” for the Authentication Type.
    • Note: The Microsoft documentation says: PAP supports all the authentication methods of Azure MFA in the cloud: phone call, one-way text message, mobile app notification, OATH hardware tokens, and mobile app verification code. *CHAPV2 and EAP* support phone call and mobile app notification.”

Firepower Threat Defense (FTD) Configuration

  • Configure ISE as your RADIUS servers for AnyConnect AAA. 
  • Set the timeout to 60 seconds or longer—if users are waiting for an SMS, phone call, push notification, etc., you want to give them enough time to do it.

User Experience

  • Users will put in their username and password at the AnyConnect client 
  • If their preferred option (set at https://account.activedirectory.windowsazure.com/Proofup.aspx) uses a code (verification code form app or text message), they will see a pop-up after their first authentication. 
  • If their preferred option is a voice call or push notification, the authentication will wait until the verification is complete before granting access. Make sure all timeouts in the chain are long enough to support this. 


The NPS logs are a pain to use for troubleshooting. I wrote a quick python script to help parse the logs. You can find it here: https://github.com/gosse/interpret-nps-logs.

Automating Certificate Install on ASA with Netmiko

Here is a little script I wrote to automate putting certificates onto ASAs. It also activates the cert on the inside interface (mine is a one-armed VPN concentrator). The cert is assumed to already in the correct format and named asabase64.cert.

#!/usr/bin/env python3

from netmiko import Netmiko
import base64
import datetime

# connection config for netmiko
asav = {
"host": "hostname",
"username": "user",
"password": "pass",
"device_type": "cisco_asa",
"secret": "enable secret"

# open and read the cert
with open("asabase64.cert", "r") as f:
cert = f.read().splitlines()

# name the cert with today's date
# this helps when pushing a new cert
# to not have a namespace overlap
today = datetime.datetime.now().strftime("%d-%m-%Y")
certname = today + "starcert"
certcmd = "crypto ca import " + certname + " pkcs12 asaexportpass"
# build the commands needed to install the cert
commands = []
commands.append("conf t")
commands = commands + cert
trustpoint = "ssl trust-point " + certname + " inside"

# connect to the firewall
net_connect = Netmiko(**asav)

# always a good test
output = net_connect.send_command_timing("show int ip br")

# send the commands
for command in commands:

# clean up

FDM FTD HA Upgrade

To upgrade an HA pair of Firepower firewalls managed by FDM, use the following procedure: 

1. Deploy any pending changes
2. Log into standby unit, upload the upgrade and install 
3. After the reboot and copmleted upgrade, on teh standby unit, go High Availability and Switch Mode. This will force failover. 
4. Log into new standby unit, upgrade that unit. 
5. Resume HA (if it does not automatically resume) 
6. Deploy policy if needed 

Restart FDM WebUI

Sometimes, the FDM Web UI stops responding. I’ve found this especially on 6.5 code. To restart tomcat, go into expert mode and disable/enable: 


> expert
admin@fp:~$ sudo su -
root@fp:~# cd /ngfw/var/cisco/ngfwWebUi/
## delete this file if it exists
root@fp:ngfwWebUi# rm .bootstrap-failed
root@fp:ngfwWebUi# pmtool disablebyid tomcat
root@fp:ngfwWebUi# pmtool enablebyid tomcat


The web service takes a while (10+ minutes) to come back online. 

h/t to Pieter-Jan Nefkens at https://www.nefkens.net/fdm-application-fails-after-upgrade/