If you failover to WAN2, then the your Local Public IP changes, in relation to what is configured on the Firepower. So that makes perfectly sense. The Firepower creates a tunnel to WAN1 IP address, if the MX IP changes to that of WAN2, that Firepower can no longer reach its Peer. ... View more

I know, you can get discounts up to ridiculous levels.  But if they would start off with list prices that are more comparable to the competition it would be easier to sell it. As a Cisco first engineer it sometimes is hard to defend Cisco against cheaper alternative to the smaller businesses we are working with. ... View more

@alemabrahao is right - Cisco ISE is "da bomb".   I see 99.999% of companies using Microsoft NPS still.  Hard to beat the price.   ps. There are zero changes to NPS in newer versions of Windows.  To migrate, you just export the config on the old server and then import it on the new server. ... View more

@Marc_Abaya  as Dave mentioned above credentials are cached on the device, our users authenticate once and it just works.  ... View more

Was the issue  resolved, have very similar issue. ... View more

Although all of my staff laptops are members of an Active Directory domain and are managed by Group Policy, I do not manage wireless profiles on those devices using a group policy. The staff member who uses each laptop actually signs into the device using a local account, not a domain account. This means I can use a local administrator account on the affected machines to delete the faulty profile and then import an "all user" profile for the same SSID.   School laptops that are used by students do have wi-fi managed through group policy (primarily to prevent them from connecting to cell phone hotspots as a way to bypass the school firewall). However, I have never experienced this issue on those laptops.   After doing some experimenting over the last few weeks, I think the issue can be avoided if I join the device to wi-fi at the right time during setup.      1. Install a (non-domain) image onto the device over ethernet using MDT.      2. Connect to wi-fi using the local administrator account.      3. Join the laptop to the domain (over wi-fi).      4. Create the local account for the end-user.   If the device is domain-joined with MDT as part of sysprep or domain-joined over ethernet after setup has finished and THEN connected to wi-fi, the resulting wireless profile will be "per user", but will not exhibit any issues.   If the local user account is created and that account is used to join wi-fi, then not only will the wireless profile be "per user", but the wi-fi connection will drop whenever a running task owned by 'SYSTEM', 'LOCAL SERVICE', or 'NETWORK SERVICE' attempts to access something over the network.   ... View more

@BrechtSchamp wrote: A hidden SSID still sends out beacon frames, it just doesn't contain the SSID name. Note that hidden SSIDs don't add much security. You just have to wait untill an actual client comes by and connects to know the SSID name: https://ethicalhackingblog.com/uncovering-hidden-ssids/   The problem is (particularly for roaming) is that some drivers (some Intel ones for sure) will not send probe packets on DFS channels, so unless there is a device already using the channel in question the client device will simply never find the SSID on that channel. On it's own that's enough reason never use a hidden SSID, the fact that they are useless is (now to me) fairly minor compared with the strange issue they can cause. I think I still have my logs from back in 2005 when I used to log Access points (including the hidden ones) from the top deck of a London bus and that was when the hide your SSID and limit to known MAC addresses made you super secure. BTW the customer made up the bit about requiring the SSID to be hidden to get PCI compliance in the EU.   ... View more