The following enhancement requests have been filed for this though: CSCeh73797, CSCsk86689, CSCsy90223. If you have a cisco accounts team you should follow up with them regarding these enhancements.
... View more
Feature Infomration: The Simple Certificate Enrollment Protocol is a protocol designed to make the issuing and revocation of digital certificates as scalable as possible. The idea is that any standard network user should be able to request their digital certificate electronically and with as little intervention from network adminstrators. For VPN deployments require certificate authentication using the enterprise CA or any 3rd party CA which supports, SCEP, this means the users can now request for signed certs from their client machines without having to involve their network adminstrators. If the user wants to configure the ASA as the CA server itself then SCEP is not what you're looking for, please refer to the following document instead: The Local CA As of ASA v8.3 there are two methods of SCEP that are supported: 1. the old method also called legacy SCEP is what will be discussed in this document. 2. SCEP proxy, is the newer method where the ASA proxies the certificate enrollment request on behalf of the client. This process is neater as it doesn't require an extra tunnel group and is also more secure. However the downside is that SCEP proxy only works with AC v3.x. This means that the current AC client version for mobile devices doesn't support SCEP proxy. You'll find more information related to the feature parity between mobile clients and the latest AC client version documented in bug #CSCtj95743(check the j-comments). Note: If the user requires certificate enrollment for anything other than mobile devices, always use SCEP proxy over legacy SCEP. Only in cases where it isn't supported due to either ASA or client versions should you configure legacy SCEP, and even then in case of the former upgrade the ASA code is the better option. This document will only configure a configuration of the first method, Legacy SCEP. Configuration Steps: When using Legacy SCEP, there are a few things that you have to keep in mind: 1. After the client has recieved the signed certificate, for the ASA to be able to authenticate the client it should recognise the CA that signed the certificate so you need to ensure that the ASA has also enrolled with the CA server. The process of enrolling the ASA should be the first step as it established two things: a. the CA is configured correctly and able to issue certificates via SCEP(if you use URL for enrollment method) b. the ASA is able to communicate with the CA, so if your client isn't able to then it's an issue between the client and the ASA. 2. When the client attempts its first connection it will not have a signed certificate, so there has to be some other way to authenticate the client. 3. during the certificate enrollment process, the ASA plays no role whatsoever. It only serves as the VPN aggregator so that the client can build a tunnel to securely obtain the signed certificate. Once the tunnel has established, the client has to be able to reach the CA server otherwise it will not be able to enroll. Step 1: Enroll the ASA This step is relatively easy and doesn't require anything new. You can find more details on how to enroll the ASA to a 3rd party CA here: Enrolling the Cisco ASA to a CA Using SCEP Step 2: Configure the tunnel to use for enrollment As I mentioned before, for the client to be able to get a certificate it should be able to build a secure tunnel with the ASA using some other method of authentication. To do this you need to configure one tunnel-group that will only be used for the very first connection attempt when the client makes a cert request. Here's a snapshot of the configuration I use to define this tunnel-group, the important lines are marked in bold-italics: rtpvpnoutbound6(config)# sh run user username cisco password ffIRPGpDSOJh9YLq encrypted privilege 0 rtpvpnoutbound6# sh run group-policy gp_certenroll group-policy gp_certenroll internal group-policy gp_certenroll attributes wins-server none dns-server value <dns-server-ip-address> vpn-tunnel-protocol ikev2 ssl-client ssl-clientless group-lock value certenroll split-tunnel-policy tunnelspecified split-tunnel-network-list value acl_certenroll default-domain value cisco.com webvpn anyconnect profiles value pro-sceplegacy type user rtpvpnoutbound6# sh run access-l acl_certenroll access-list acl_certenroll remark to allow access to the CA server access-list acl_certenroll standard permit host <ca-server-ipaddress> rtpvpnoutbound6# sh run all tun certenroll tunnel-group certenroll type remote-access tunnel-group certenroll general-attributes address-pool ap_fw-policy authentication-server-group LOCAL secondary-authentication-server-group none default-group-policy gp_certenroll tunnel-group certenroll webvpn-attributes authentication aaa group-alias certenroll enable Here's the client profile that I've used, you can either paste this into a notepad file and then import it into the ASA or you can configure it using the ASDM directly: <?xml version="1.0" encoding="UTF-8"?> <AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ AnyConnectProfile.xsd"> <ClientInitialization> <UseStartBeforeLogon UserControllable="true">false</UseStartBeforeLogon> <AutomaticCertSelection UserControllable="true">false</AutomaticCertSelection> <ShowPreConnectMessage>false</ShowPreConnectMessage> <CertificateStore>All</CertificateStore> <CertificateStoreOverride>false</CertificateStoreOverride> <ProxySettings>Native</ProxySettings> <AllowLocalProxyConnections>true</AllowLocalProxyConnections> <AuthenticationTimeout>12</AuthenticationTimeout> <AutoConnectOnStart UserControllable="true">false</AutoConnectOnStart> <MinimizeOnConnect UserControllable="true">true</MinimizeOnConnect> <LocalLanAccess UserControllable="true">false</LocalLanAccess> <ClearSmartcardPin UserControllable="true">true</ClearSmartcardPin> <AutoReconnect UserControllable="false">true <AutoReconnectBehavior UserControllable="false">ReconnectAfterResume</AutoReconnectBehavior> </AutoReconnect> <AutoUpdate UserControllable="false">true</AutoUpdate> <RSASecurIDIntegration UserControllable="false">Automatic</RSASecurIDIntegration> <WindowsLogonEnforcement>SingleLocalLogon</WindowsLogonEnforcement> <WindowsVPNEstablishment>LocalUsersOnly</WindowsVPNEstablishment> <AutomaticVPNPolicy>false</AutomaticVPNPolicy> <PPPExclusion UserControllable="false">Disable <PPPExclusionServerIP UserControllable="false"></PPPExclusionServerIP> </PPPExclusion> <EnableScripting UserControllable="false">false</EnableScripting> <CertificateEnrollment> <AutomaticSCEPHost>rtpvpnoutbound6.cisco.com/certenroll</AutomaticSCEPHost> <CAURL PromptForChallengePW="false" >scep_url</CAURL> <CertificateImportStore>All</CertificateImportStore> <CertificateSCEP> <Name_CN>%USER%</Name_CN> <KeySize>2048</KeySize> <DisplayGetCertButton>true</DisplayGetCertButton> </CertificateSCEP> </CertificateEnrollment> <EnableAutomaticServerSelection UserControllable="false">false <AutoServerSelectionImprovement>20</AutoServerSelectionImprovement> <AutoServerSelectionSuspendTime>4</AutoServerSelectionSuspendTime> </EnableAutomaticServerSelection> <RetainVpnOnLogoff>false</RetainVpnOnLogoff> </ClientInitialization> <ServerList> <HostEntry> <HostName>rtpvpnoutbound6.cisco.com</HostName> <HostAddress>rtpvpnoutbound6.cisco.com</HostAddress> </HostEntry> </ServerList> </AnyConnectProfile> Note: You'll notice that's i've not configured a group-url for this tunnel group. This is important because legacy SCEP will not work the URL, you have to select the tunnel group with using it's alias. Step 3: Configure the tunnel that will actually be used by the client for connection user certificates for authentication Once the client has recieved the signed ID certificate it can now connect using cert authentication. But the actually tunnel-group that the client will actually use to connnect has still not been configured. This configuration is very similar to how you configure any other connection-profile(this term is synonymous with tunnel-group and not to be confused with client profile) which uses cert authentication. Here's a snapshot of the configuration I've used for this tunnel: rtpvpnoutbound6(config)# show run access-l acl_fw-policy access-list acl_fw-policy standard permit 192.168.1.0 255.255.255.0 rtpvpnoutbound6(config)# show run group-p gp_legacyscep group-policy gp_legacyscep internal group-policy gp_legacyscep attributes vpn-tunnel-protocol ssl-client split-tunnel-policy tunnelspecified split-tunnel-network-list value acl_fw-policy default-domain value cisco.com webvpn anyconnect modules value dart rtpvpnoutbound6(config)# show run tunnel tg_legacyscep tunnel-group tg_legacyscep type remote-access tunnel-group tg_legacyscep general-attributes address-pool ap_fw-policy default-group-policy gp_legacyscep tunnel-group tg_legacyscep webvpn-attributes authentication certificate group-alias legacyscep enable group-url https://rtpvpnoutbound6.cisco.com/legacyscep enable Verification: As of when going to press, the only situation one should use legacy scep is when using mobile devices so this section only deals with mobile clients. When you attempt to connect the first time, just put in the ASA's hostname or ip address and then select "certenroll" or whatever group alias you configured in step 2. Here you'll be prompted for a username and password and you'll have the "get certicate" button. Once you hit this button, if you check your client logs, you should see the following: [06-22-12 11:23:45:121] <Information> - Contacting https://rtpvpnoutbound6.cisco.com. [06-22-12 11:23:45:324] <Warning> - No valid certificates available for authentication. [06-22-12 11:23:51:767] <Information> - Establishing VPN session... [06-22-12 11:23:51:879] <Information> - Establishing VPN session... [06-22-12 11:23:51:884] <Information> - Establishing VPN - Initiating connection... [06-22-12 11:23:52:066] <Information> - Establishing VPN - Examining system... [06-22-12 11:23:52:069] <Information> - Establishing VPN - Activating VPN adapter... [06-22-12 11:23:52:594] <Information> - Establishing VPN - Configuring system... [06-22-12 11:23:52:627] <Information> - Establishing VPN... [06-22-12 11:23:52:734] <Information> - VPN session established to https://rtpvpnoutbound6.cisco.com. [06-22-12 11:23:52:764] <Information> - Certificate Enrollment - Initiating, Please Wait. [06-22-12 11:23:52:771] <Information> - Certificate Enrollment - Request forwarded. [06-22-12 11:23:55:642] <Information> - Certificate Enrollment - Storing Certificate. [06-22-12 11:24:02:756] <Error> - Certificate Enrollment - Certificate successfully imported. Please manually associate the certificate with your profile and reconnect. Even though the last message says "error" it's infact only to inform the user that this step is necessary for that client to be used for the next connection attempt which will be to the second connection profile configured in step 3.
... View more
Martin, bug #CSCts45189 has been filed for this issue. Unfortunately we haven't been able to reproduce this problem in the lab and due to the impact this has had on customer environments, most people who run into this problem move to using DHCP pools or some other form of address assignment(as Shane indicated). If you haven't done so and you are willing to help us troubleshoot this problem then we will be quite grateful. In that case when you next run into this issue, please open a TAC case right away with the following debugs: 1) logging class ipaa trap 6 2) debug dhcpc error 3) debug dhcpc detail 4) debug dhcpc packet 5) debug dhcpd event 255 6) debug dhcpd packet 255 6) When it's failing, check the loggin database to see whether that ip addr is in use : show vpn-sessiondb anyconnect filter a-ipaddress 7) asp captures on ASA interface that the DHCP server(s) attached to. 8) packet capture on the DHCP server(s) Also what kind of DHCP server are you using: 1) MS server or Alcatel-Lucent QIP DHCP server? 2) multiple DHCP servers as failover pair?
... View more
To configure on Demand or other additional mobile settings for Anyconnect clients from the ASA, one can use the profile Editor to configure the settings by following the steps enumerated below: However, if you are unable to find this option "Addition mobile-only settings" don't get too worried. Most likely what's happened is the version of Anyconnect package installed on the ASA is 2.5.x. While this is understandable since the iphone or ipad AC client version is also only 2.5.x., unforutnately this is also the reason behind you not being able to see the above option. This option was only integrated into the profile editor for AC 3.x packages. So if you were to install a 3.x Anyconnect package on your ASA, everything would work just fine. Do I need to update clients on all devices then? Now, you might be wondering, so does that mean I have to upgrade all my existing non-mobile clients to this version?? NOPE. ASA only requires that a 3.x package be installed in the ASA, not that it be in use by a client. So you can continue to use your existing client version, just add the 3.x client at the bottom of the list, by tweaking the order number in the command: anyconnect image disk0:/anyconnect-win-3.0.5075-k9.pkg <order_no> As long as this order no is greater than the other versions installed on the ASA, this version should never be used. You can do the same thing on ASDM by moving the packages up and down in the window shown below: And voila... you know have the functionality of the 3.x profile editor without having to update your client versions. On a side note, it is definitely a good idea to consider moving to the 3.x code version. Where do I download Ancyonnect client v 3.x from? You can get the 3.x client from Cisco.com, however, unlike the 2.x clients, the 3.x client isn't called Anyconnect VPN client, instead it is called Anyconnect Secure Mobility Client:
... View more
How does the ASA push the rules to the client? One the rules are defined and a connection is being established, the rules are passed to the client via a CSTP handshake during the setup. The agent takes a snapshot of the existing firewall rules and applies the received rules to the native firewall available on the operating system. As of now, this handshake isn't tracked via debugs, any errors are only logged on the client. What platforms are currently supported? Windows XP SP2 Windows Vista Windows 7 MAC OS X 10.5 MAC OS X 10.6 Linux, Windows Mobile and other new mobile platforms are not yet supported. ENH # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtx55751CSCtx55751 has been filed to add support to linux clients Where are the rules applied? 1. Windows The rules obtained from ASA will be applied to the Windows Firewall present on the supported Operating Systems. For older operating systems on which AnyConnect gets installed (Windows 2000 and XP pre-SP2), the firewall feature will softly fail, logging an error message that the OS is not supported for this feature. Rules are applied to all the windows profiles. 2. MAC The rules will be applied to ipfw, the legacy firewall present in MAC. The native application firewall present on OSX 10.5 and OSX 10.6 do not have any APIs that we can utilize. However, its presence does not prevent us from configuring ipfw. So, there is no necessity for us to disable the application firewall. What is the significance of the source and destination port numbers in the access list? The primarily role of the port numbers is ofcourse to identify what service to permit or allow for a certain protocol. However, the ports numbers, and how they are applied also play another very significant role. Depending on whether the source or/and the destination port is defined in the access-list, the direction in which this rule will be applied to firewall will be determined. To enumerate: If source port and destination port are specific number, the rule applies to both inbound and outbound traffic. If source port and destination port are specified as a range or ‘All’ (value of 0), the rule applies to both inbound and outbound traffic. If the source port is a specific number and the destination port is a range or ‘All’, the rule applies to inbound traffic. If the source port is a range or ‘All’ and the destination port is a specific number, the rule applies to only outbound traffic. The ASDM does a poor job of explaining this to users. Bug # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtg79827CSCtg79827 was filed to enhance this. To configured a source port in the ASDM click on the "more" options when adding an ACE. The thing you need to keep in mind while configuring or modifying the acecss-list from the ASDM is that the way ASDM displays the ACLs it won't display the source port, i.e. if you have the following access-list: access-list acl_client_fw_test extended deny icmp any any access-list acl_client_fw_test extended deny tcp any eq 3389 any access-list acl_client_fw_test extended deny tcp any eq 3340 any access-list acl_client_fw_test extended permit tcp any any eq 3340 In the ASDM, this will look like: This doesn't mean the access-list is wrong, it just means it's displayed incorrectly. This should have been addressed by bug # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCse02836&content=summary&format=htmlCSCse02836, but ever since 2k6 no one really got around to it, so if you're in this area feel free to attach this bug to your case. However, there are some caveates: http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtg45671CSCtg45671: on XP machines due to limitations of the OS, the client firewall policy on computers running Windows XP is enforced for inbound traffic only. Outbound rules and bidirectional rules are ignored. CSCtx27707: on win 7 if you define an access-list denying a particular source port then all inbound traffic to that port should be blocked. However, currently what happens when you define such an entry is all outbound/inbound internet access gets blocked. I am nost sure if this applies to XP machines as well, however developer viskrish is working on both issues. What is the difference between Public and Private rules? The value public/private indicates which interfaces to apply the rules on. Public rules are applied on all interfaces on that client machine. Private rules, on the other hand, are applied only to the virtual adapter so for traffic not being encrypted these rules would have no effect. When should the public rules not have any effect even if they are pushed down? The administrator has to explicitly configure split tunneling of some kind for the public firewall rules to take effect. Enabling the firewall feature does not automatically imply opening local LAN. If the agent detects there is no split tunneling configured, the public firewall rules will not be applied and a configuration error will be logged. The connection will proceed. This has no effect on private rules, which will be applied regardless. What happnes if the client is unable to apply all the rules? Currently, if for some reason: applying a public deny firewall rule fails, the agent disables all split tunneling and logs the failure. applying a private rule fails, the error is logged but no further action is taken. Enhancement request # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCtu00005&content=summary&format=htmlCSCtu00005 has been filed to change this behavior so that if the installation fails the adminsitrator has the option to prevent the connection completely. What happens if the local Firewall service is stopped or disabled before Connection? If the firewall service is stopped or disabled, AC wILLenable it and start the service before applying our rules. This is done only when there are firewall rules configured on the ASA. On a service shutdown or VPN disconnect, the original state of firewall SHOULD be restored. However currently if the firewall policy was disabled before the connection, then on disconnect the client machine will lose complete internet access. This is documented in bug # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCts38500&content=summary&format=htmlCSCts38500 and should be fixed as of v3.0.5075. This begs the next question: When should the fw rules continue to apply, even after disconnecting AC? Sometimes even after disconnecting from the ASA, the rules continue to apply. This will usually occur if you have Always on enabled and and ApplyLastVPNLocalResourceRules setting implies that failure policy is “Closed”. This is by design. When the agent starts up, it reads the firewall rules that are obtained from ASA and keeps them in memory. On a service shutdown, they are written to the disk for possible offline usage. If on a service restart, the agent is not able to contact the ASA, the agent reads the stored rules and applies them to the native firewall, and deletes the stored copy. However with Always-on disabled or Always on enabled with Fail Open policy, this should not happen. What happens if a third party software/root user disables the FW after the connection is complete? Currently there is no easy way of securing the firewall rules that are created or lock down the firewall and disallow others from modifying the rules. On Windows, you can use AD GPOs to prevent adding more rules through the Windows Firewall User Interface and to disable deletion of our rules. However, the group policy can apply restrictions only on the basic firewall UI and not to changes made with Advanced Security UI found in Vista and Windows 7. Similarly on MAC, users with root privileges will always be able to modify the rules. So to get around this the client is designed to constantly poll the state of the FW and the rules, and if it notices any modifications, it logs an appropriate error, disables all split tunneling, and configures tunnel-all. ENH # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtx55897CSCtx55897 has been filed to add the ability to secure the rules pushed by the client.
... View more
If you're using ASA code above 8.3 the natting becomes very different, and the above set up may no longer work. If the code is below 8.3 then it maybe possible using SLA monitoring, but I haven't tested it and can't be sure how the natting will be affected.Ideally is ISP2 goes down and SLA monitoring removes the second route, then the static NATs shuold also not function properly, so the nat global should work just fine.
... View more
Symptoms Using IOS 15.0 code, user is able to successfully use auth-proxy with TACACS+ and ACS 4.x. However as soon as the user upgrade his IOS to 15.1 and beyond, auth-proxy fails. Conditions / Environment NAS device running IOS 15.1+ auth-proxy using TACACS+ Cause / Problem Description If you look at the 15.1 or 15.2 tacacs debugs you'll see the following: 265410: Jan 26 14:13:55 EST: TPLUS: processing authorization request id 59 265411: Jan 26 14:13:55 EST: TPLUS: Sending AV service=auth-proxy 265412: Jan 26 14:13:55 EST: TPLUS: Sending AV protocol=ip However if you look at how the service is configured in the TACACS+ section of the interface configuration on the ACS you'll see that the protocol isn't specified: It looks like the older 15.0 code didn't enforce the protocol for auth-proxy as strictly, whereas 15.1 and above does and thus the users faile auth-proxy. Resolution The fix for this is actually quite simple. You can just add ip under the protocol tab in the above section as shown below: However the twist is that ACS doesn't just update the existing service, instead it creates a brand new service called "auth-proxy ip"(the older one was called just "auth-proxy"). So it fix this you need to go into each group which used to have "auth-proxy" enabled and enable "auth-proxy ip" for all of them, and copy over all the customer attributes so that it works exactly the same as before: It's important to keep in mind, however, that until all NAS devices have been upgraded to 15.1+ code, it would be unwise to remove the old service.
... View more
Ideally yes, if your DRAM is at least 512MB you shouldn't see that error message, If you do though, then you need to upgrade your flash: Hardware: ASA5505, 512 MB RAM, CPU Geode 500 MHz Internal ATA Compact Flash, 128MB BIOS Flash M50FW016 @ 0xfff00000, 2048KB Increase the flash is at least 256MB or above.
... View more
[toc:faq] Introduction The SCP feature works on routers however it doesn't work on interfaces which have VRF enabled on it. Since the management interface on the ASR is pre-configured with the VRF and this cannot be removed, it is very important that VRF-AWARE SCP work on ASRs. This document explains how to get it set up. Solution For using SCP on a VRF enable interface you will need to do the following:
1) Configure SSH
2) SSH source-interface must be configured (i.e ip ssh source-interface Ethernet1/0). It is required as SCP uses SSH for connection.
Configuration Example R200#sh ip ssh
SSH Enabled - version 1.99
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
Name Default RD Protocols Interfaces
vpn1 <not set> ipv4 Et1/0
R200#sh run | i source
ip ssh source-interface Ethernet1/0
R200#copy unix:check_run scp://firstname.lastname@example.org://unix:
Address or name of remote host [10.10.10.201]?
Destination username [cisco]?
Destination filename [unix:]? unix:check-12
11 bytes copied in 12.068 secs (1 bytes/sec)
R200#copy scp://email@example.com://unix:check_run unix:
Destination filename [unix:check_run]? unix:chck-11
11 bytes copied in 12.473 secs (1 bytes/sec)
... View more
[toc:faq] Introduction Sometimes when you have two ASAs in failover, and you enter a command like "svc image ...", if you aren't consoled in you may lose connectivity to the ASA itself and when you reconnect the the command isn't there anymore. This document explains why this happens as well as the solution for it. Prerequisites Requirements For information regarding configuration failover on an ASA please go through the following documents: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00807dac5f.shtml Explanation Consider the following syslogs: Nov 30 2011 12:58:33 test-asa : %ASA-6-720032: (VPN-Secondary) HA status callback: id=3,seq=200,grp=0,event=411,op=30,my=Active,peer=Standby Ready. Nov 30 2011 12:58:33 test-asa : %ASA-6-721002: (WebVPN-Secondary) HA status change: event HA_STATUS_CLIENT_NEGOTIATED_VERSION, my state Active, peer state Standby Ready. >> At this point the secondary is active, and the primary is standby. Nov 30 2011 12:58:33 test-asa : %ASA-5-111008: User 'enable_15' executed the 'svc image disk0:/anyconnect-win-3.0.4235-k9.pkg' command. >> User enters command 'svc image disk0:/anyconnect-win-3.0.4235-k9.pkg' Nov 30 2011 12:58:33 test-asa : %ASA-6-720032: (VPN-Secondary) HA status callback: id=3,seq=200,grp=0,event=406,op=130,my=Active,peer=Active. Nov 30 2011 12:58:33 test-asa : %ASA-6-720028: (VPN-Secondary) HA status callback: Peer state Active. Nov 30 2011 12:58:33 test-asa : %ASA-6-721002: (WebVPN-Secondary) HA status change: event HA_STATUS_PEER_STATE, my state Active, peer state Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-720032: (VPN-Secondary) HA status callback: id=3,seq=200,grp=0,event=406,op=80,my=Active,peer=Standby Ready. Nov 30 2011 12:58:34 test-asa : %ASA-6-720028: (VPN-Secondary) HA status callback: Peer state Standby Ready. Nov 30 2011 12:58:34 test-asa : %ASA-6-721002: (WebVPN-Secondary) HA status change: event HA_STATUS_PEER_STATE, my state Active, peer state Standby Ready. Nov 30 2011 12:58:34 test-asa : %ASA-6-720032: (VPN-Secondary) HA status callback: id=3,seq=200,grp=0,event=406,op=130,my=Active,peer=Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-720028: (VPN-Secondary) HA status callback: Peer state Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-721002: (WebVPN-Secondary) HA status change: event HA_STATUS_PEER_STATE, my state Active, peer state Active. >> As soon as the user enters the command, both devices become active Nov 30 2011 12:58:34 test-asa : %ASA-1-103004: (Secondary) Other firewall reports this firewall failed. Nov 30 2011 12:58:34 test-asa : %ASA-1-104002: (Secondary) Switching to STNDBY - Other unit reports that I am failed Nov 30 2011 12:58:34 test-asa : %ASA-6-720037: (VPN-Secondary) HA progression callback: id=3,seq=200,grp=0,event=52,op=12,my=Failed,peer=Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-721003: (WebVPN-Secondary) HA progression change: event HA_PROG_FAILED, my state Failed, peer state Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-720032: (VPN-Secondary) HA status callback: id=3,seq=200,grp=0,event=405,op=20,my=Failed,peer=Active. Nov 30 2011 12:58:34 test-asa : %ASA-6-720027: (VPN-Secondary) HA status callback: My state Failed. Nov 30 2011 12:58:34 test-asa : %ASA-6-721002: (WebVPN-Secondary) HA status change: event HA_STATUS_MY_STATE, my state Failed, peer state Active. >> Secondary firewall which was active until now is informed by the Primary firewall that it has apparently failed, this explains why both devices became active. However, on receiving this communication, the secondary firewal, to diffuse the dual active fw situation switches to failed. Nov 30 2011 12:58:48 test-asa : %ASA-6-611101: User authentication succeeded: Uname: admin Nov 30 2011 12:58:48 test-asa : %ASA-6-605005: Login permitted from 10.11.9.60/1491 to inside:10.11.254.1/ssh for user "admin" Nov 30 2011 12:58:50 test-asa : %ASA-5-502103: User priv level changed: Uname: enable_15 From: 1 To: 15 >> Because the secondary "failed" the user was kicked out and is forced to log back in. Nov 30 2011 12:58:54 test-asa : %ASA-6-720037: (VPN-Secondary) HA progression callback: id=3,seq=200,grp=0,event=101,op=18,my=Sync Config,peer=Active. Nov 30 2011 12:58:54 test-asa : %ASA-6-721003: (WebVPN-Secondary) HA progression change: event HA_PROG_STANDBY_CONFIG, my state Sync Config, peer state Active. >>At this point the secondary has the configuration "svc image disk0:/anyconnect-win-3.0.4235-k9.pk", but the primary doesn't since it hasn't synced with the secondary yet. However, because the secondary "failed" it now tries to sync with the active device, which is the primary. Nov 30 2011 12:58:54 test-asa : %ASA-1-709006: (Secondary) End Configuration Replication (STB) >> Once configuration is replicated, the secondary will no longer have the svc image command because it synced from a device that didn't have the command. This explains why the command got removed entirely, but it doesn't explain why the primary ASA suddenly thought that the secondary had failed. In order to understand that consider the following portion of the configuration: failover polltime unit msec 400 holdtime 4
failover polltime interface msec 500 holdtime 5 This means that the devices are polling each other every 400msec to see if the other device is still active. Now the command we tried to execute is something that's very likely to cause a CPU hog for at least a second, which means that during that second that secondary firewall is in no state to reply to the primary firewall, thus the primary firewall assumes that the secondary is "dead" and send out the communication: Nov 30 2011 12:58:34 test-asa : %ASA-1-104002: (Secondary) Switching to STNDBY - Other unit reports that I am failed Solution Modify the unit poll time to a more reasonable value allowing the ASAs to complete such exhaustive commands.
... View more
Walter, to control the traffic from the spokes so that they only go to the hub before they go anywhere else, you just need to control the routing. For example if you are using EIGRP then removing then enabling next-hop-self instead of disabling it should fix this issue for you. As far as NAT is concerned, just treat the tunnel interface like any other interface for natting, it should work.
... View more
Question Why aren't some of my translated symbols showing up when I load the translated Anyconnect Localisation file? Answer Sometimes when you import the localisation into the ASDM and then open it to view it(or look at the translations on the client itself) you see something similar to this: wherein certain symbols show up as gibberish. The problem here is usually in the kind of encoding used when the file was saved. If you save the file using ANSI encoding, which is the default, then you'll see the problem: In this case, the ANSI encoding for the French character is different from that of UTF-8, and Java uses UTF-8 when sending data. So when you create the localisation using notepad and you save the file you have to ensure that you save it using UTF-8 encoding: Once you save it with the right kind of encoding you're likely to see the correct symbol:
... View more
I am glad you find this one useful, you might find the following document handy for your other requirement: https://supportforums.cisco.com/docs/DOC-15887#Q_How_do_I_configure_the_Mac_builtin_VPN_Client
... View more