1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Phase 2 of VPN negotiation failing

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by RCILUtica, Aug 14, 2007.

  1. RCILUtica

    RCILUtica LI Guru Member

    I have an RV082 at our remote office and a Cisco 1811 at the main office. I have two existing remote offices with RV082s and persistent VPN connections back to the main office. The one I am having a problem with worked initially until our IP changed from dynamic to static. (initially being for 20 mins of testing while waiting for a call from the ISP with the static).

    Here is the VPN log:


    Time
    Event-Type Message
    Aug 14 15:33:31 2007 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Aggressive Mode 1st packet
    Aug 14 15:33:31 2007 VPN Log initiating Aggressive Mode #79, connection "ips0"
    Aug 14 15:33:31 2007 VPN Log STATE_AGGR_I1: initiate
    Aug 14 15:33:31 2007 VPN Log Informational Exchange is for an unknown (expired?) SA
    Aug 14 15:33:32 2007 VPN Log Ignoring Vendor ID payload Type = [Cisco-Unity]
    Aug 14 15:33:32 2007 VPN Log Received Vendor ID payload Type = [Dead Peer Detection]
    Aug 14 15:33:32 2007 VPN Log Ignoring Vendor ID payload [3013718f1309277f...]
    Aug 14 15:33:32 2007 VPN Log Ignoring Vendor ID payload Type = [XAUTH]
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] <<< Initiator Received Aggressive Mode 2nd packet
    Aug 14 15:33:32 2007 VPN Log Aggressive mode peer ID is ID_IPV4_ADDR: '209.217.205.250'
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] >>> Initiator send Aggressive Mode 3rd packet
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] Initiator Cookies = a14b 39a7 fbb 1b7d
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] Responder Cookies = c5d4 d692 138 277f
    Aug 14 15:33:32 2007 VPN Log initiating Quick Mode PSK+COMPRESS+TUNNEL+AGGRESSIVE
    Aug 14 15:33:32 2007 VPN Log [Tunnel Negotiation Info] >>> Initiator send Quick Mode 1st packet


    Anyone have any ideas? I'm at a loss...

    Thanks
     
  2. RCILUtica

    RCILUtica LI Guru Member

    Also, I have tried without compression and agressive mode. I am also using SHA1 and 3DES as I am using with the other tunnels. I have tested with MD5 and AES128 without success.
     
  3. ifican

    ifican Network Guru Member

    Something is slightly amiss if its not comming up, could me as simple as a space somewhere. You say you verified sha and 3des on both sides, have you verified the vpn acl on the router? The RV is pretty straight forward the 1811 on the other hand is alot more complicated, the most troublesome is the vpn acl and second most i think for most is to make sure crypto-maps then transform sets are identified correctly. Also when you have multiple vpn's on the same router you need to make sure you have a different crypto-map entry for each tunnel.
     
  4. DocLarge

    DocLarge Super Moderator Staff Member Member

    Piggy-backing on what ifican has mentioned, here's an example of how to configure multiple crypto maps; eric.stewart helped me get around the brainlock I was having when he showed me how to do this:
    -----------------------------------------------------------------------------------------------

    Phase I

    crypto isakmp enable
    crypto isakmp policy 10
    authentication pre-share
    encryption 3des
    hash sha
    group 2
    lifetime 28800 (default)
    crypto isakmp identity address (specifies use of remote WAN IP)
    crypto isakmp key 1234 address 22.23.24.25 (Remote WAN IP)
    crypto isakmp keepalive 3600 (max. default)
    crypto ipsec df-bit clear (helps guard against packet loss)

    Phase II

    crypto ipsec transform set cisco esp-3des esp-sha-hmac
    crypto ipsec security-association lifetime seconds 28800 (default)

    Now you need your access-list. Let's assume 172.16.20.0 is your CISCO and 172.16.30.0 is the vpn endpoint on the other side:

    access-list 110 permit ip 172.16.20.0 0.0.0.255 172.16.30.0 0.0.0.255
    access-list 111 deny ip 172.16.20.0 0.0.0.255 172.16.30.0 0.0.0.255

    NOTE: Traffic you don't want to be NAT'd (a.k.a. "inspected") will be based on the "permit ip" statements; together with the "deny ip" statement, it should be interpreted to mean "let it pass through the tunnel (ACL-110)...but don't inspect it (ACL-111)." If I'm off on this translation, one of the more established CISCO dudes will chime in

    Phase III

    Now you need to name your "crypto map" policy which is used to define "particular vpn tunnels:"

    crypto map baseline 110 ipsec-isakmp (110 is merely a sequence; 111, 112, and so one can be used for additional tunnels)
    set peer 22.23.24.25 (Remote WAN Public IP)
    match address 110 (pertains to ACL 110 which is allowed)
    set transform-set cisco (name established above)
    set pfs group2
    set security-association lifetime 28800 (default)

    Phase IV

    You'll use "route-map nonat" to specify which subnets will "not" be NAT'd as they pass through the vpn tunnel:

    route-map nonat permit 10
    match ip address 111 (refers to ACL-111 which will "not" inspect the traffic)

    And finally, you'll apply your route-map nonat statement to an interface to specify which way traffic should go:

    ip nat inside source route-map nonat interface FastEthernet4 overload

    Overload turns on private address translation which basically allows you to utilize your private ip ranges (Class A, B, C) behind one public IP address.

    Doing this in phases makes things easier to interpret (I think).

    I'm using the above config to run three separate tunnels on my 871w.

    Jay
     
  5. RCILUtica

    RCILUtica LI Guru Member

    Guys, thanks for the quick response and detailed info. It turns out that XAuth was enabled and as soon as I disabled it I was in business (sort of). I did notice this in the logs and blew it off.

    I do have another quick question though. Although they are connected and I can ping hosts at the remote site with pretty good returns (50-80ms), other connectivity such as RDP, opening shares, etc is hit or miss. For example I can open c$ on a workstation out there but when I get 2 or 3 folders deep I lose it. I also can not establish an RDP connection. I get the remote desktop and enter user creds, then I lose connectivity.

    Any ideas?
     

Share This Page