Net Worker World

  1. Phase I proposal mismatch  Run show crypto isakmp sa  Initiator: MM_WAIT_MSG2 Responder: No info  Most likely this is phase1 proposal mismatch, verify IKEv1 policy, other symptoms:   Initiator log: Information Exchange processing failed All configured IKE versions failed to establish the tunnel Initiator debug: Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping Responder log: Error processing payload: Payload ID Responder debug:  All SA proposals found unacceptable 2. IKE version mismatch:  Run  show crypto isakmp sa  no info at both initiator and responder Initiator log: Removing peer from correlator table failed, no match! Reason: User Requested  All configured IKE versions failed to establish the tunnel Initiator debug: Oakley begin quick mode PHASE 1 COMPLETED IKE Initiator sending 1st QM pkt Removing peer from correlator table failed, no match! Session is being torn down. Reason: User Requested Responder log: Tunnel Rejected: Conflicting protocols specified

  Solution 1 - Use of the DefaultL2LGroup This is the simplest way to configure a LAN-to-LAN (L2L) tunnel betwen two ASAs when one ASA gets its address dynamically. The DefaultL2L Group is a preconfigured tunnel group on the ASA and all connections that do not explicitly match any particular tunnel group fall on this connection. Since the Dynamic ASA does not have a constant predetermined IP address, it means the admin cannot configure the static tunnel-group in order to allow the connection come in, in this situation, the DefaultL2L Group can be used in order to allow the dynamic connections. HQ ASA ! Create objects object network obj-172.16.1.0_24  subnet 172.16.1.0 255.255.255.0 object network obj-172.16.2.0_24  subnet 172.16.2.0 255.255.255.0 object network obj-172.16.3.0_24  subnet 172.16.3.0 255.255.255.0 !Create NAT excemption for L2L VPN and dynamic NAT for Internet access. nat (inside,outside) source static obj-172.16.1.0_24 obj-172.16.1.0_24 destination static obj-172.16.2.0_

  Remote 1 uses main mode with default tunnel-group, Remote 2 uses aggressive mode with named tunnel-group. Central ASA ! Create objects object network obj-10.1.2.0_24  subnet 10.1.2.0 255.255.255.0 object network obj-10.1.1.0_24  subnet 10.1.1.0 255.255.255.0 object network obj-10.1.3.0_24  subnet 10.1.3.0 255.255.255.0 !Create NAT exemption for L2L VPN and dynamic NAT for Internet access. nat (inside,outside) source static obj-10.1.2.0_24 obj-10.1.2.0_24 destination static obj-10.1.1.0_24 obj-10.1.1.0_24 no-proxy-arp route-lookup nat (inside,outside) source static obj-10.1.2.0_24 obj-10.1.2.0_24 destination static obj-10.1.3.0_24 obj-10.1.3.0_24 no-proxy-arp route-lookup ! object network obj-10.1.2.0_24  nat (inside,outside) dynamic interface ! Define IKEv1 policy crypto ikev1 policy 10  authentication pre-share  encryption aes-256  hash sha  group 2 ! Enable ikev1 on outside interface  crypto ikev1 enable outside ! Define transform-set crypto ipsec ikev1 transform-set T-SET esp-aes-

 ISE 2.7: 172.16.1.11 AD: 172.16.1.10 vSwitch: 172.16.1.9 1. Install Device Admin license Administration > System > Licensing, [Import License] 2. Enable Device Admin Service Administration > System > Deployment >, click node "ISE27", check "Enable Device Admin Service" 3. Assume ISE is already added to AD, now create two new groups in AD: Network Admin Helpdesk User 4. Add above two AD groups to ISE: Administration > Identity Management > External Identity Sources, expend Active Directory, select the AD "lab.local", click Groups tab, click Add > Select Groups from Directory. 5. Assume device is already added to ISE, configure device TACACS shared secret In device setting window, check "TACACS Authentication Settings", input shared secret. 6. Configure two TACACS Profiles Configure a basic TACACS Profile for Helpdesk Staff Navigate to Work Centers > Device Administration > Policy Elements >  Results > TACACS Pr

  Security Assertion Markup Language (SAML) is an XML-based, open-standard data format used to exchange authentication and authorization data between parties, specifically between an identity provider (IdP) and a service provider. User Agent SP (Service Provider) IDP (Identity Provider) IDP and SP establish Trust When an user wants to access a SP, he must first authenticate with IDP, after successful authentication, IDP generates a SAML ASSERTION, which is sent to SP, then the user can access SP. The user exists in  IDP, SAML configuration specify what attribute to use to identify user, for example, use email address. IDP side SAML configuration IDP XML and SP side SAML configuration SP XML called Metadata Metadata: It is an XML based document that ensures a secure transaction between an IdP and an SP. It allows the IdP and SP to negotiate agreements. Between IDP and SP: message exchange via BINDINGS: HTTP-POST, HTTP-REDURECT, HTTP-ARTIFACT  In case of Azure as IDP, Anyconnect as SP ID