Interesting problem. The main issue is here:
Oct 3 11:05:56.070 EST: ISAKMP (0:1): Checking IPSec proposal 12
Oct 3 11:05:56.070 EST: ISAKMP: transform 1, ESP_3DES
Oct 3 11:05:56.070 EST: ISAKMP: attributes in transform:
Oct 3 11:05:56.070 EST: ISAKMP: authenticator is HMAC-SHA
Oct 3 11:05:56.074 EST: ISAKMP: encaps is 1 (Tunnel)
Oct 3 11:05:56.074 EST: ISAKMP: SA life type in seconds
Oct 3 11:05:56.074 EST: ISAKMP: SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
Oct 3 11:05:56.074 EST: ISAKMP (0:1): atts are acceptable.
Oct 3 11:05:56.074 EST: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= "router outside IP", remote= ""client Public IP"",
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 172.16.1.6/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2
Oct 3 11:05:56.078 EST: IPSEC(kei_proxy): head = VPN, map->ivrf = , kei->ivrf =
Oct 3 11:05:56.078 EST: IPSEC(validate_transform_proposal): invalid transform proposal flags -- 0x2
The router checks through all the proposals sent by the client, until it finally comes to the matching one (3DES/SHA), and then it fails with "invalid transform proposal flags".
I believe this is due to you having "set pfs group2" under your dynamic crypto map on the router. The client will not propose to use this as it doesn't support it, and the router will never step down and accept what it sees as a lower security offering. It assumes that if you have configured PFS Group2 then you must want to use it, and it will therefore not accept a request without that.
You will have to remove PFS Group2 off the router and both the VPN Client and the router will then agree to not use PFS.
