Phase I Main Mode Vs. Aggressive Mode

Hi,
I have a quick question; if I have site-to-site VPN and one side is configured for Phase I Main Mode and the other is configured for Aggressive mode, will the VPN work?
Regards,
Haitham

Hi Haitham
AFAIK no it should not work because aggresive mode uses just 3 packets in the exchange and main mode uses 6 packets so the information contained in the exchanges between the two peers would not match.
HTH
Jon

Similar Messages

IpSec in transport mode not completeing phase 2 quick mode

I am trying to connect Solaris 10 to a non Solaris box over IPsec. I know this box has worked with a windows machine running ipsec.
My configuration of ipsec and ike looks to be correct but I must be missing something.
If I turn the ikeadm traces I see that I get through the phase 1 main mode but can not establish quick mode.
I have to use 3des for encryption and sha1 for authentic ion. I have followed the steps in the Solaris 10 ipsec and ike manual but I don't know where to turn now.
This are the ikeadm traces
Wed 20 Jul 2005 12:05:21 BST: in.iked: Quick Mode negotiation failed: code 14 (No proposal chosen).
Wed 20 Jul 2005 12:05:21 BST: in.iked: local_ip = 172.18.10.1, remote_ip = 192.168.25.22,
Wed 20 Jul 2005 12:05:21 BST: in.iked: local_i_id = ipv4(tcp:0,[0..3]=192.168.25.22), local_r_id = No Id,
Wed 20 Jul 2005 12:05:21 BST: in.iked: remote_i_id = ipv4(tcp:2126,[0..3]=172.18.10.1), remote_r_id = No Id,
Wed 20 Jul 2005 12:05:21 BST: in.iked: spsi: ike_send_packet -1
Wed 20 Jul 2005 12:05:21 BST: in.iked: In ssh_policy_phase_ii_sa_freed.
Wed 20 Jul 2005 12:05:21 BST: in.iked: local_ip = 172.18.10.1, remote_ip = 192.168.25.22,
Wed 20 Jul 2005 12:05:21 BST: in.iked: spsi: ike_udp_callback_common -1
Wed 20 Jul 2005 12:05:21 BST: in.iked: In ssh_policy_new_connection_phase_qm (pm_info = 0x85938).
Wed 20 Jul 2005 12:05:21 BST: in.iked: In ssh_policy_qm_select_sa (pm_info = 0x85938).
Wed 20 Jul 2005 12:05:21 BST: in.iked: Number of sas is 1.
Wed 20 Jul 2005 12:05:21 BST: in.iked: pfkey_request: queueing seq 598 type 12/X_INVERSE_ACQUIRE satype 0/UNSPEC
Wed 20 Jul 2005 12:05:21 BST: in.iked: tx_req: posting seq 598 type 12/X_INVERSE_ACQUIRE satype 0/UNSPEC
Wed 20 Jul 2005 12:05:21 BST: in.iked: pf_key_handler: got pid 1242 seq 598 type
6/ACQUIRE sa 0/UNSPEC errno 0 diag 0/No diagnostic len 109
Wed 20 Jul 2005 12:05:21 BST: in.iked: handle_reply: got seq 598 type 6/ACQUIREsatype 0/UNSPEC
Wed 20 Jul 2005 12:05:21 BST: in.iked: SA #0.
Wed 20 Jul 2005 12:05:21 BST: in.iked: Number of proposals = 1.
Wed 20 Jul 2005 12:05:21 BST: in.iked: Proposal 0.
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 0 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 1 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 2 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 3 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 4 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 5 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 6 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 7 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 8 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: ecomb 9 lost
Wed 20 Jul 2005 12:05:21 BST: in.iked: no matching ecomb
Wed 20 Jul 2005 12:05:21 BST: in.iked: No winner.
Wed 20 Jul 2005 12:05:21 BST: in.iked: finish_qm_select_sa: invoked for 85018
Wed 20 Jul 2005 12:05:21 BST: in.iked: Quick Mode negotiation failed: code 14 (No proposal chosen).
Wed 20 Jul 2005 12:05:21 BST: in.iked: local_ip = 172.18.10.1, remote_ip = 192.1
My config file
# more config
local_id_type IP
p1_lifetime_secs 28800
p1_nonce_len 20
p1_xform {auth_method preshared oakley_group 2 auth_alg sha1 encr_alg 3des}
p2_pfs 0
p2_lifetime_secs 10800
label "cmts1"
local_addr 172.18.10.1
remote_addr 192.168.25.22
I have also set up the ike.preshared file with my preshared key
When I do a ikeadm dump preshared I see the correct key
Any suggestions
penright

Eeesh. I wish I'd signed up for SDN earlier.
I know I'm a year late in replying, but the peer is proposing something in Quick Mode
(Phase 2) that your Solaris box doesn't think is available. Given the combinations
you had (0-9), I'd be interested to know what the peer proposed that didn't match.
You don't mention what ipsecconf(1m) input is, nor what the peer is configured to
do. You say 3des + sha1 - so that should be one of the choices.
One common mistake is to use "auth_algs" in ipsecconf(1m) (which is AH) instead
of "encr_auth_algs" (which is ESP's hash).

DA client getting with error Main mode SA assumed to be invalid because peer stopped responding.

Facing one issue with only DA client , it connects to Direct access for few seconds and then get disconnected.
Looking at error on Event viewer I see below error
Any help appreciated certificate looks ok on client not sure why IPSEC is still failing.
Main
An IPsec main mode negotiation failed.
Local Endpoint:
                Local Principal Name:
                Network Address: fd03:c8e4:6dc5:1000:65c3:ec29:19db:d27
                Keying Module Port:
500
Remote Endpoint:
                Principal Name:
                Network Address: fd03:c8e4:6dc5:1000::1
                Keying Module Port:
500
Additional Information:
                Keying Module Name:         IKEv1
                Authentication Method:      Unknown authentication
                Role:
Initiator
                Impersonation State:
Not enabled
                Main Mode Filter ID:
0
Failure Information:
                Failure Point:
Local computer
                Failure Reason:
No policy configured
                State:
No state
                Initiator Cookie:
9859f832aff8f6c2
                Responder Cookie:
0000000000000000
Quick
An IPsec quick mode negotiation failed.
Local Endpoint:
                Network Address: ::
                Network Address mask:       0
                Port:
0
                Tunnel Endpoint:
fd03:c8e4:6dc5:1000:65c3:ec29:19db:d27
Remote Endpoint:
                Network Address: fd03:c8e4:6dc5:7777::405a:e2f2
                Address Mask:
0
                Port:
0
                Tunnel Endpoint:
fd03:c8e4:6dc5:1000::1
                Private Address:
0.0.0.0
Additional Information:
                Protocol:
0
                Keying Module Name:         AuthIP
                Virtual Interface Tunnel ID: 0
                Traffic Selector ID: 0
                Mode:
Tunnel
                Role:
Initiator
                Quick Mode Filter ID:
148975
                Main Mode SA ID: 9
Failure Information:
                State:
Sent first (SA) payload
                Message ID:
3
                Failure Point:
Local computer
                Failure Reason:
Main mode SA assumed to be invalid because peer stopped responding.

my "Personal"
================ Certificate 0 ================
Serial Number: db275ae51a55dc55fbe5
Issuer: CN=Communications Server
NotBefore: 3/27/2015 5:16 PM
NotAfter: 9/23/2015 5:16 PM
Subject: CN=[email protected]
Non-root Certificate
Cert Hash(sha1): b3 1a 83 46 a7 3b 35 81 d5 b8 df 4a cf c7 b5 84 3d 16 4f 19
Key Container = [email protected]
Unique container name: c8d28464bd8e19954e01e055a437dac2_9a8ca7a5-b032-4abe-aa4f-78479e291b9e
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Signature test passed
================ Certificate 1 ================
Serial Number: acf56029651a29985555bc204feec2906e0e623c
Issuer: CN=Token Signing Public Key
NotBefore: 11/2/2014 1:10 PM
NotAfter: 11/9/2014 1:10 PM
Subject: CN=8cb8436c5273712d
Non-root Certificate
Cert Hash(sha1): 96 40 a0 e3 d8 d3 a1 83 3d 7d 53 89 78 13 ec ea 14 57 59 e2
Key Container = IDENTITYCRL_CERT_CONTAINER_781dc55f-39ad-4acf-908b-077a9f0892c0
Unique container name: fa2317742ecd4995840a96d529ded279_9a8ca7a5-b032-4abe-aa4f-78479e291b9e
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Encryption test passed
================ Certificate 2 ================
Serial Number: 1ecfdba10000000711f6
Issuer: CN=certificates1.bentley.com, OU=IT, O=Bentley Systems Inc, L=Exton, S=PA, DC=bentley, DC=com, C=US
NotBefore: 10/14/2014 3:00 PM
NotAfter: 10/14/2015 3:00 PM
Subject: E=[email protected], CN= user name
Non-root Certificate
Template: 1.3.6.1.4.1.311.21.8.11654720.1572043.7097246.3836610.15498332.49.1051303.5974672, Bentley User
Cert Hash(sha1): 34 b0 4d a3 c0 ea 3f 91 c4 e8 1f bf bc a3 eb 8d 0e 13 71 3b
Key Container = le-BentleyUser-b08f3f78-54cf-490e-9778-24c8c7bb9c0e
Unique container name: fe0554406294c67f04d3b9898a803d95_9a8ca7a5-b032-4abe-aa4f-78479e291b9e
Provider = Microsoft Software Key Storage Provider
Private key is NOT exportable
Encryption test passed

VRF VPN in AWS - Main Mode Failure

The configs are pretty straight forward: http://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmsw_book/ivmvpna.html#wp1054133
Yet I'm having two issues. With external peers I have a main mode failure on the peer who's tunnel was un-shut first. The security groups permits ESP, UDP 500 and 4500. When that didn't work I opened up UDP all the way. I still had the issue.
Between internal peers in AWS my tunnel is up/down. Both isakmp and IPsec SAs are established. But I am unable to pass traffic.
any ideas will be greatly appreciated
[26B]
crypto keyring VTI-2627 vrf F5426
pre-shared-key address 10.10.10.94 key abc123
crypto isakmp profile VTI-2627
keyring VTI-2627
match identity address 10.10.10.94 F5426
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto ipsec transform-set VTI-Set esp-aes 256 esp-sha-hmac
mode tunnel
crypto ipsec profile VTI-2627
set transform-set VTI-Set
set isakmp-profile VTI-2627
set pfs group2
int tunnel2627
desc IPSec VTI to R26A
ip address 10.26.27.1 255.255.255.252
tunnel mode ipsec ipv4
tunnel vrf F5426
tunnel source Gi1
tunnel destination 10.10.10.94
tunnel protection ipsec profile VTI-2627
[27A]
crypto keyring VTI-2726 vrf F5427
pre-shared-key address 20.20.20.218 key abc123
crypto isakmp profile VTI-2726
keyring VTI-2726
match identity address 20.20.20.218 F5427
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto ipsec transform-set VTI-Set esp-aes 256 esp-sha-hmac
mode tunnel
crypto ipsec profile VTI-2726
set transform-set VTI-Set
set isakmp-profile VTI-2726
set pfs group2
int tunnel2726
desc IPSec VTI to R26B
ip address 10.26.27.2 255.255.255.252
tunnel mode ipsec ipv4
tunnel vrf F5427
tunnel source Gi1
tunnel destination 20.20.20.218
tunnel protection ipsec profile VTI-2726
%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer at 20.20.20.218

taburley,
One of the issues that I have encountered in the past is forgetting that if I am creating a tunnel externally the destination may be NAT'd by the AWS infrastructure. What is the route that your tunnel has to take to be formed? If it leaves through an IGW it is possible that you are NAT'd to a public address and the tunnel destination on the opposite side will need to point to that address instead of the 10.X.X.X address. It may be something to check out. Can you ping from 27A to 26B using the tunnel source and destination addresses?
-Nick

IKE Main Mode Configuration

Hi
I have a client that i set up an IPSec VPN for remote access, but it seems their IPS is blocking me. The reason they gave was the IPS doesn't like the IKE agressive mode that we're using, and instead of opening a potential security risk, they've requested i switch to Main Mode. After looking around on google results, i havent found much of anything config wise for Main Mode except the command isakmp am-disable, which ends up killing the IPSec VPN.
The ASA is running 8.4.5
Any help is appreciated.
-Steve

I ended up dropping the IP Sec remote access VPN in favor of an SSL VPN.

Direct Access: No Security Associations under Main mode and Quick Mode: No SA

Could someone please help me with the issue here :'(
Windows Firewall advanced security--> Monitoring --> Main mode (Empty)
--> quick Mode (Empty)
Its been days I am trying to trouble shoot this issue. All the setup seems good. I am not able to figure out this certificate issue.

Hi Sijin,
What is the status of this issue ? If you still have issue please confirm the following.
1) What is the Network Topology?
2) What is the client OS?
3) If you have it configured for Windows 7 and 8 both then do you have Client Authentication Certificate in Personal store and Root Certificate from Internal CA present on client machine?
4) What is the Status of IPHTTPS Interface?
5) Are you able to Ping Direct Access (DNS Server) IP Address (2002:836b:33:3333::1 from client?
6) What is the status of below services on the client machine?
IKE and AuthIP IPsec Keying Modules
IPSec Policy Agent
7) Which Windows Firewall profile is enable on DA Server and Client?
Regards
Kapil

C60 BOOT UP IN MAIN MODE AFTER SOFTWARE UPGRADE

Any one aware of why the C60 would go into maintenance mode after software upgrade from TC5.0.1 to TC7.2.1???
Software loaded and appears to install properly ???
Thanks.

Hi Chet,
You can try a factory reset in addition to the suggestions in the following post for similar issue
https://supportforums.cisco.com/discussion/12394476/c60-possibly-faulty
HTH
Manish

Anyone got an idea, mainly mods please.

Hi,
I have another speed issue, again!. These are my results and there done ethernet to my HH4 with no other devices running. I get the same results every time, its as if again BT are putting a fix on my line, I have tried to reset my HH4 but I get the same results again and it hits 21.8MB Downstream and will not go any further no matter how many times I try but my max profile says 26.08MB Downstream. I am now starting to think that BT dont like the fact they have given me an estimate of 18.1MB Downtsream on my telephone number and it is very obvious my line is capable of alot more!. Here are my results:-
1st @http://diagnostics.bt.com/login/?workflow=Speed:-
2nd@http://www.speedtest.btwholesale.com/:-
You will notice it hits 21.8MB and will not go any further no matter how many times I restart the HH4 but the max profile always says around 26MB and above. Anyone any ideas on this one please, is there some kind of fix on the line?
Please click on pink star to the left and say thanks if I have helped you at all!. Thank you. Home Hub Page- http://bthomehub.home/
BT Speed test- http://www.speedtest.btwholesale.com/
Speedtest:-http://diagnostics.bt.com/login/?workflow=Speed
Net Connect test- http://netalyzr.icsi.berkeley.edu/index.html

A Trace to bbc.co.uk
Ping Test
Dont get me wrong the tracert and ping results are fantastic and I cannot complain but something is a foot with the
downstream!.
I found a result that I thought I would post before the slide just to show it was ok:-
Please click on pink star to the left and say thanks if I have helped you at all!. Thank you. Home Hub Page- http://bthomehub.home/
BT Speed test- http://www.speedtest.btwholesale.com/
Speedtest:-http://diagnostics.bt.com/login/?workflow=Speed
Net Connect test- http://netalyzr.icsi.berkeley.edu/index.html

Ports used in IKE Phase 1

Hi everyone,
Need to confirm during IKE Phase 1
we use port UDP 500
IKE Phase 2 we use ports
ESP -50
NAT-T UDP 4500
TCP-1000 ESP -50
NAT-T UDP 4500
TCP-1000
Regards
Mahesh

IKE phase 1 (main mode/aggressive mode) is udp src and dst 500
IKE phase 2 could be:
IP protocol 50 (ESP)
NAT-T is udp src (client) ephemeral dst (server) udp 4500
The tcp encapsulation found in the older VPN clients was src (client) ephemeral dst (server) tcp 10000 (10,000 in US resp. 10.000 in most of the other world)

IKE Aggressive Mode on VPN3K

Hi,
I have VPN 3005 with 4.7.2 OS (latest one to date). I am looking to disable Aggressive Mode processing (stick to Main Mode only) for Remove VPN clients. Please note, Remote VPN clients and NOT LAN-to-LAN connections.
So far I cannot see how this can be done.
TAC engineer is not coming up with good answers as well.
Anyhow has an idea?
Thanks!
David

I don't think you can make Remote Access VPN on
the Concentrator work with Main mode, unless
you decide to use Certificate instead of
pre-shared key:
"The Cisco VPN client uses aggressive mode if preshared keys are used and uses main mode when public key infrastructure (PKI) is used during Phase 1 of the tunnel negotiations. After bringing up the Internet Security Association and Key Management Protocol Security Association (ISAKMP SA) for secure communication, the Cisco VPN 3000 concentrator prompts the user to specify the user credentials. In this phase, also known as X-Auth or extended authentication, the VPN 3000 concentrator validates the user against the configured authentication database. If the user authentication is successful, the Cisco concentrator sends a successful authentication message back to the client. After X-Auth, the Cisco VPN client requests configuration parameters such as the assigned IP address, the Domain Name System (DNS) server's IP address, and the Windows Internet Naming Service (WINS) server's IP address. During this phase, known as mode-config, the VPN 3000 concentrator sends the configured parameters back to the client. The final step for a successful VPN tunnel is the negotiation of Phase 2 parameters"

Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode

Hi, I have 10 site-to-site VPN's, they consist of Cisco 837's and 877's. I run a security scan (Qualys vulnerability scanning) against the public IP of the routers and half of them come back with the vulnerability below. They are all using the latest IOS and all connect to a Cisco Concentrator.
Here is the vulnerability, that means nothing to me, is it anything to worry about, all pre-shared keys are 8 characters or more and have letters, numbers, and symbols and capital letters:
Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode
THREAT:
IKE is used during Phase 1 and Phase 2 of establishing an IPSec connection. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. Every participant in IKE must possess a key which may be either pre-shared (PSK) or a public key. There are inherent risks to configurations that use pre-shared keys which are exaggerated when Aggressive Mode is used.
IMPACT:
Using Aggressive Mode with pre-shared keys is the least secure option. In this particular scenario, it is possible for an attacker to gather all necessary information in order to mount an off-line dictionary (brute force) attack on the pre-shared keys. For more information about this type of attack, visit http://www.ima.umn.edu/~pliam/xauth/.
SOLUTION:
IKE Aggressive mode with pre-shared keys should be avoided where possible. Otherwise a strong pre-shared key should be chosen.
Note that this attack method has been known and discussed within the IETF IPSec Working Group. The risk was considered as acceptable. For more information on this, visit http://www.vpnc.org/ietf-ipsec/99.ipsec/thrd2.html#01451.

The description of the vulnerability specifies IKE aggressive mode. So my first question would be whether you are using IKE in aggressive mode or in main mode? In my experience most router based site to site VPN use main mode (though aggressive mode is an option) while many Remote Access VPN use aggressive mode. So which mode are you using?
The second part of my response goes back to what I said in my earlier response. What kind of key are you using? How long is it and how strong is it? When you think about it any time we authenticate using shared keys there is some degree of vulnerability to brute force attack. The longer the key and the stronger the key the more you have mitigated the risk.
HTH
Rick

Disable aggressive mode

We wanted to know if there is a way to disable âAggressive modeâ on the VPN concentrator.
For example, on the ASA, we can do it using the command âisakmp am-disableâ
On a router we can do it using the command âcrypto isakmp aggressive-mode disableâ.
Is there a similar command on the VPN concentrator ?
Your help is appriciated.

Fadi,
Are you using Pre-Shared Keys or Certificates for Authentication. Please refer the below link for information on VPN Client AM and MM.
http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_data_sheet090
0aecd801a9de9.html
Aggressive Mode is the default and the only mode available for Pre-shared key and Main Mode is only available for the Cert authentication.
So, it is my understanding that it is not possible for VPN clients to use main mode to authenticate to the VPN3000 with pre-shared keys.
Regards,
Arul
*Pls rate if it helps*

IKE Aggressive mode vulnerability

Hello All,
I am currently working on a project to remove security vulnerability present in the network due to IKE Aggressive mode. Below is my understanding:
1. In aggressive mode, initiator and responder IDs are sent in clear text, as against main mode and this is the vulnerability we are trying to remove.
2. For Site to Site VPNs we can disable the aggressive mode, but this is not possible to achieve in Client to Site VPNs till we are using PSKs.
I am seeking help on below points based upon my understanding:
1. Validation of my understanding
2. In case we go for certificate based authentication instead of using PSKs, can we disable the aggressive mode and remove the vulnerability. If yes, is it a mandate to have a local CA server installed or can we go for a publicly hosted CA server.
Please advice.

Hi Vikas,
Your understanding is correct. More info on this...
http://www.cisco.com/warp/public/707/cisco-sn-20030422-ike.html
If you go with certificate- yes you can mitigate the issue. Some firms go with practice of frequently changing & longer PSK.
Also, if you have second level authentication ex:RSA for successful authentication, this can be acceptable.
You can go with a local MS CA server-
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080930f21.shtml
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008073b12b.shtml
You can as well use a IOS router as CA server.
Hth
MS

Aggressive Mode and Encryption

Hi Everyone.
I read below
Aggressive mode does not give identity protection of the two IKE peers, unless digital certificates are used. This means VPN peers exchange their identities without encryption (clear text). It is not as secure as main mode.
Currently we have setup RA VPN without digital certs sp does it mean that pre shared keys which are exchanged between client and ASA are
clear text without any encryption.?
Regards
MAhesh

Mahesh,
RFC answers those questions
start with
http://tools.ietf.org/html/rfc2409
Just to make a simple quote (a bit out of context, but here goes)
   While the last roundtrip of Main Mode (and optionally the last
   message of Aggressive Mode) is encrypted it is not, strictly
   speaking, authenticated.
To encrypt you need to agree on a key. have a look at aggresive mode exchange :-)
M.

Aggressive Mode IKE

We used to use IPSEC VPN, but now use Anyconnect SSL VPN. We have a third party scan our firewall externally, and they are recommending that we disable Aggressive Mode IKE. Is this only used for IPSec VPN's? Is it safe to remove this from our configuration on our ASA 5505?
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
Thank You.

Hi Bill,
The aggresive mode (3 pkt exchange) is only used for the IPsec remote access. The site to site VPN uses main mode (6 pkt exchange). If you do not have any site to site VPN you can disable these commands however if you do have site to site VPN then removing these will break them.
There is nothing called aggressive mode in Anyconnect. Anyconnect uses a totally different protocol called SSL (TCP/UDP port 443).
Hope this answers your question.
Thanks,
Vishnu Sharma

Phase I Main Mode Vs. Aggressive Mode

Similar Messages

Maybe you are looking for