cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

1302
Views
0
Helpful
1
Replies
Highlighted
Beginner

All remote wireless IPSec remote clients fail connecting to ASA suddenly, what gives??

I thought long and hard before posting this problem but I've completely run out of options to consider and need the help of the community.

We have two ASA 5500 series Firewalls running 8.4(1).  One in New York, another in Atlanta.

They are configured identically for simple IPSecV1 remote access for clients.  Authentication is performed by an Radius server local to each site.

There are multiple IPSec Site-to-Site tunnels on these ASA's as well but those are not affected by the issues we're having.

First, let me start with the famous last words, NOTHING WAS CHANGED.

All of a sudden, we were getting reports of remote users to the Atlanta ASA timing out when trying to bring up the tunnel.  They would get prompted for their ID/Password, then nothing until it times out.

Sames users going to the NY ASA are fine.

After extensive troubleshooting, here is what I've discovered.

Remote clients will authenticate fine to the Atlanta Firewall ONLY IF THEY ARE USING A WIRED CONNECTION.

If they are using the wireless adapter for their client machine, they will get stuck trying to login to Atlanta.

These same clients will get into the New York ASA with no problems using wired or wireless connections.

Windows 7 clients use the Shrewsoft VPN client and Mac clients use the Cisco VPN client.  They BOTH BEHAVE the same way and fail to connect to the Atlanta ASA if they use their wireless adapter to initiate the connection.

Using myself as an example.

1. On my home Win 7 laptop using wireless, I can connect to the NY ASA with no issues. 

2. The same creditials USED to work for Atlanta as well but have now stopped working.  I get stuck until it times out.

3. I run a wire from my laptop to the FiOS router, then try again using the same credentials to Atlanta and I get RIGHT IN.

This makes absolutely no sense to me.  Why would the far end of the cloud care if I have a wired or wireless network adapter?  I should just be an IP address right?  Again, this is beyond my scope of knowledge.

We've rebuilt and moved the Radius server to another host in Atlanta in our attempts to troubleshoot to no avail.  We've also rebooted the Atlanta Firewall and nothing changed.

We've tried all sorts of remote client combinations.  Wireless Internet access points from different carriers (Clear, Verizon, Sprint) all exhibit the same behavior.  Once I plug the laptops into a wired connection, BAM, they work connecting to Atlanta. 

The New York ASA is fine for wired and wireless connections.  Same with some other remote office locations that we have.

Below I've detailed the syslog sequence on the Atlanta ASA for both a working wired remote connection and a failed wireless connection.  At first we thought the AAA/Radius server was rejecting us but is shows the same reject message for the working connection.  Again, both MAC and Windows clients show the same sequence.

Where the connection fails is the "IKE Phase 1" process.  I have no idea what happens during this process.

-------------------------------------------------------------------------------------------------------------------------

WORKING CONNECTION

-------------------------------------------------------------------------------------------------------------------------

%ASA-6-713172: Automatic NAT Detection Status: Remote end is|is not behind a NAT device This end is|is not behind a NAT device

NAT-Traversal auto-detected NAT.

%ASA-6-113004: AAA user aaa_type Successful: server = server_IP_address, User = user

%ASA-6-113005: AAA user authentication Rejected: reason = string: server = server_IP_address, User = user

%ASA-6-113009: AAA retrieved default group policy policy for user user

%ASA-6-113008: AAA transaction status ACCEPT: user = user

%ASA-5-713130: Received unsupported transaction mode attribute: attribute id

The device received a request for a valid transaction mode attribute (XAUTH or Mode Cfg) that is currently not supported.

This is generally a benign condition.

%ASA-6-713184: Client Type: Client_type Client Application Version: Application_version_string

The client operating system and application version appear. If the information is not available, then N/A will be indicated.

%ASA-6-713228: Group = group, Username = uname, IP = remote_IP_address Assigned private IP address assigned_private_IP to remote user

IKE obtained a private IP address for the client from DHCP or from the address pool.

%ASA-5-713119: Group group IP ip PHASE 1 COMPLETED

IKE Phase 1 has completed successfully.

%ASA-5-713049: Security negotiation complete for tunnel_type type (group_name) Initiator/Responder, Inbound SPI = SPI, Outbound SPI = SPI

An IPsec tunnel has been started.

%ASA-5-713120: PHASE 2 COMPLETED (msgid=msg_id)

IKE Phase 2 has completed successfully.

%ASA-5-713049: Security negotiation complete for tunnel_type type (group_name) Initiator/Responder, Inbound SPI = SPI, Outbound SPI = SPI

An IPsec tunnel has been started.

%ASA-5-713120: PHASE 2 COMPLETED (msgid=msg_id)

IKE Phase 2 has completed successfully.

-------------------------------------------------------------------------------------------------------------------------

FAILED CONNECTION

-------------------------------------------------------------------------------------------------------------------------

%ASA-6-713172: Automatic NAT Detection Status: Remote end is|is not behind a NAT device This end is|is not behind a NAT device

NAT-Traversal auto-detected NAT.

%ASA-6-113004: AAA user aaa_type Successful: server = server_IP_address, User = user

%ASA-6-113005: AAA user authentication Rejected: reason = string: server = server_IP_address, User = user

%ASA-6-113009: AAA retrieved default group policy policy for user user

%ASA-6-113008: AAA transaction status ACCEPT: user = user

%ASA-5-713130: Received unsupported transaction mode attribute: attribute id

The device received a request for a valid transaction mode attribute (XAUTH or Mode Cfg) that is currently not supported.

This is generally a benign condition.

%ASA-6-713184: Client Type: Client_type Client Application Version: Application_version_string

The client operating system and application version appear. If the information is not available, then N/A will be indicated.

%ASA-6-713228: Group = group, Username = uname, IP = remote_IP_address Assigned private IP address assigned_private_IP to remote user

IKE obtained a private IP address for the client from DHCP or from the address pool.

ASA-5-713201: Duplicate Phase 2 packet detected. Action

The ASA has received a duplicate of a previous Phase 1 or Phase 2 packet, and will transmit the last message. A network performance or connectivity issue may have occurred, in which the peer is not receiving sent packets in a timely manner.

%ASA-5-713201: Duplicate Phase 2 packet detected. Action

The ASA has received a duplicate of a previous Phase 1 or Phase 2 packet, and will transmit the last message. A network performance or connectivity issue may have occurred, in which the peer is not receiving sent packets in a timely manner.

%ASA-5-713201: Duplicate Phase 2 packet detected. Action

The ASA has received a duplicate of a previous Phase 1 or Phase 2 packet, and will transmit the last message. A network performance or connectivity issue may have occurred, in which the peer is not receiving sent packets in a timely manner.

1 REPLY 1
Beginner

Re: All remote wireless IPSec remote clients fail connecting to

As you can see, this is one of those completely crazy issues we all encounter one in a while.

So far I've eliminated:

1. The client sofware.  Both Mac and Win7 clients see the same thing.

2. The machines.  Multiple laptops and desktops were used to test, all showing same behavior.

3. The ISP.  Multiple carriers were used to test.

4. The wireless hardware:  Multiple wireless access points, cable modem and FiOS remote ends were used.  Do we need to test dial up? 

5. Configuration changes on the ASA.  The only change was to add another subnet to a network object group used for a site to site VPN.  This was removed and the behavior remained.

6. The AAA/Radius server.  A completely new box was rebuilt to host the Radius and the ASA was pointed to it.

7. Wacky ASA behavior.  The ASA has been running for 280 days and was rebooted, no change in behavior.

What am I missing?

Thank you in advance for all suggestions.