Other Tech

Secure VPN Connection terminated by Peer.
Reason 433: Reason Not Specified by Peer

I ran into this error recently when trying to set up a Remote Access VPN. This error could be caused by multiple problems. However, in my particular case, it was the settings under AAA authentication servers. Upon connection, the VPN client would prompt for logon credentials and then immediately return this error.

In my environment, I was using a Windows Server 2003 Domain Controller for LDAP authentication. The VPN termination point was an older PIX 515 firewall running IOS 8.0. I was also using the latest Cisco VPN client on Windows 8.1.

After some quick troubleshooting, it appeared that the domain account used to query LDAP was either buried too deep in the OU structure or, some of the OU names were causing problems (they had spaces and special characters).

PREVIOUS: Why can’t I access my Cisco firewall through a web browser? (Part II)

In part 2 of our series, we explored whether or not the ASDM image was linked in the firewall’s configuration. And if not, how to create that link. We also checked whether the image even existed on flash with the SHOW DISK0: command. Part 3 explores the possibility that the image file is missing and what is required to remedy this situation.

PREVIOUS: Why can’t I access my Cisco firewall through a web browser? (Part I)

In part one of this series, we explored possible configuration errors that could prevent you from connecting to your Cisco Firewall via a web browser. This involved checking the HTTP commands from the Cisco CLI. In the second part of this series, we will look at other possibilities that could be preventing you from making this connection.

Two other possibilities are that the ASDM image is either not referenced in the firewall configuration, or, the ASDM image is missing entirely. To check on the first possibility execute the following command from the Cisco CLI.

Why can’t I access my Cisco firewall through a web browser? There could be a number of reasons for this. We will explore the different causes in our multi-part series.

One possibility could be that you simply are missing the necessary configuration on your firewall. So let’s check this out.

First, we need to log in using an alternative method. Let’s use PuTTY to access the CLI (Command Line Interface).

I ran into this issue recently while trying to make a Remote Access VPN work on a Cisco ASA 5505 firewall. The VPN had been working at one point but was rarely used. When the end-user tried to use it again they kept getting the following error.

Secure VPN connection terminated locally by the Client.
Reason 412. The remote peer is no longer responding.

Now, this error could occur for many reasons. Including a firewall on the client-side, that is blocking the necessary UDP or TCP ports, or, an unstable internet connection, such as a mobile connection. But in my particular case, it was actually a configuration issue on the firewall itself.

I ran into an interesting problem today. We were retiring our aging B/G radios with brand new dual-band N radios. To fill this need we purchased Cisco Aironet 3502i wireless access points. The Wireless LAN Controller we were using was a Cisco WLC 2106 and could support 6 simultaneous radios. We had confirmed the Wireless LAN Controller was on the latest software release. We attached the first access point and it connected just fine. It discovered, joined and downloaded the updated software from the controller without incident. It showed up in the Cisco management software ready for additional configuration.

We attached the next access point and it got stuck. The status light would alternate green, then red, then off. When we debugged the access point through the console session we could see that it had discovered the correct controller and was sending JOIN commands. However, the handshake would never complete and it would keep cycling the interfaces up and down. It would also give up and occasionally reboot as well, or, show a status that it had reached the maximum number of retries.

We pulled out two more access points – same deal. It seemed so odd because the first one had worked so effortlessly. We knew we weren’t at the maximum radios for the WLC and we knew we didn’t have any problems with territory or county code mismatches. We also checked the WLC clock, certificate, and authentication lists.

The fix was actually quite simple. The 3 WAPs had gone into MESH mode. To remove them from MESH mode was an interesting fix. This is how you do it.