The remote peer is no longer responding

Discussion in 'Cisco' started by soup_or_power@yahoo.com, Oct 23, 2006.

  1. Guest

    I am using VPN client to connect to a PIX firewall. I get the error:
    " Secure VPN connection terminated locally by the Client. Reason 412:
    The remote peer is no longer responding". I am attaching the log below.
    Someone (Walter?) please
    help me. Thanks & Regards


    Cisco Systems VPN Client Version 4.0.5 (Rel)
    Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
    Client Type(s): Windows, WinNT
    Running on: 5.1.2600 Service Pack 2

    1 19:19:48.890 10/22/06 Sev=Info/4 CM/0x63100002
    Begin connection process

    2 19:19:48.906 10/22/06 Sev=Info/4 CVPND/0xE3400001
    Microsoft IPSec Policy Agent service stopped successfully

    3 19:19:48.906 10/22/06 Sev=Info/4 CM/0x63100004
    Establish secure connection using Ethernet

    4 19:19:48.906 10/22/06 Sev=Info/4 CM/0x63100024
    Attempt connection with server "209.178.198.242"

    5 19:19:49.921 10/22/06 Sev=Info/6 IKE/0x6300003B
    Attempting to establish a connection with 209.178.198.242.

    6 19:19:49.921 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd),
    VID(Nat-T), VID(Frag), VID(Unity)) to 209.178.198.242

    7 19:19:49.937 10/22/06 Sev=Info/4 IPSEC/0x63700008
    IPSec driver successfully started

    8 19:19:49.937 10/22/06 Sev=Info/4 IPSEC/0x63700014
    Deleted all keys

    9 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x6300002F
    Received ISAKMP packet: peer = 209.178.198.242

    10 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000014
    RECEIVING <<< ISAKMP OAK AG (SA, VID(Unity), VID(dpd), VID(?), KE, ID,
    NON, HASH) from 209.178.198.242

    11 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000001
    Peer is a Cisco-Unity compliant peer

    12 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000001
    Peer supports DPD

    13 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000081
    Received IOS Vendor ID with unknown capabilities flag 0x00000025

    14 19:19:50.375 10/22/06 Sev=Info/6 IKE/0x63000001
    IOS Vendor ID Contruction successful

    15 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT,
    VID(?), VID(Unity)) to 209.178.198.242

    16 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000082
    IKE Port in use - Local Port = 0x01F4, Remote Port = 0x01F4

    17 19:19:50.375 10/22/06 Sev=Info/4 CM/0x6310000E
    Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated
    IKE SA in the system

    18 19:19:50.375 10/22/06 Sev=Info/4 CM/0x6310000E
    Established Phase 1 SA. 1 Crypto Active IKE SA, 1 User Authenticated
    IKE SA in the system

    19 19:19:50.390 10/22/06 Sev=Info/5 IKE/0x6300005D
    Client sending a firewall request to concentrator

    20 19:19:50.390 10/22/06 Sev=Info/5 IKE/0x6300005C
    Firewall Policy: Product=Cisco Systems Integrated Client, Capability=
    (Centralized Protection Policy).

    21 19:19:50.406 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 209.178.198.242

    22 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x6300002F
    Received ISAKMP packet: peer = 209.178.198.242

    23 19:19:50.453 10/22/06 Sev=Info/4 IKE/0x63000014
    RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 209.178.198.242

    24 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
    MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value =
    192.168.99.1

    25 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
    MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_DNS(1): , value = 192.168.1.6

    26 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
    MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_NBNS(1) (a.k.a. WINS) : ,
    value = 192.168.1.6

    27 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x6300000E
    MODE_CFG_REPLY: Attribute = MODECFG_UNITY_DEFDOMAIN: , value =
    corp.iexpect.com

    28 19:19:50.453 10/22/06 Sev=Info/4 CM/0x63100019
    Mode Config data received

    29 19:19:50.468 10/22/06 Sev=Info/4 IKE/0x63000055
    Received a key request from Driver: Local IP = 192.168.99.1, GW IP =
    209.178.198.242, Remote IP = 0.0.0.0

    30 19:19:50.468 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 209.178.198.242

    31 19:19:50.578 10/22/06 Sev=Info/5 IKE/0x6300002F
    Received ISAKMP packet: peer = 209.178.198.242

    32 19:19:50.578 10/22/06 Sev=Info/4 IKE/0x63000014
    RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:NO_PROPOSAL_CHOSEN) from
    209.178.198.242

    33 19:19:50.578 10/22/06 Sev=Warning/3 IKE/0xA300004B
    Received a NOTIFY message with an invalid protocol id (0)

    34 19:19:51.203 10/22/06 Sev=Info/4 IPSEC/0x63700014
    Deleted all keys

    35 19:19:55.703 10/22/06 Sev=Info/4 IKE/0x63000021
    Retransmitting last packet!

    36 19:19:55.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

    37 19:20:00.703 10/22/06 Sev=Info/4 IKE/0x63000021
    Retransmitting last packet!

    38 19:20:00.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

    39 19:20:05.703 10/22/06 Sev=Info/4 IKE/0x63000021
    Retransmitting last packet!

    40 19:20:05.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

    41 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x6300002D
    Phase-2 retransmission count exceeded: MsgID=041CAED1

    42 19:20:10.703 10/22/06 Sev=Info/6 IKE/0x6300003D
    Sending DPD request to 209.178.198.242, seq# = 1691596402

    43 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to
    209.178.198.242

    44 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 209.178.198.242

    45 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000048
    Discarding IPsec SA negotiation, MsgID=041CAED1

    46 19:20:10.750 10/22/06 Sev=Info/5 IKE/0x6300002F
    Received ISAKMP packet: peer = 209.178.198.242

    47 19:20:10.750 10/22/06 Sev=Info/4 IKE/0x63000014
    RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from
    209.178.198.242

    48 19:20:10.750 10/22/06 Sev=Info/5 IKE/0x6300003F
    Received DPD ACK from 209.178.198.242, seq# received = 1691596403, seq#
    expected = 1691596403

    49 19:20:40.703 10/22/06 Sev=Info/4 IKE/0x63000017
    Marking IKE SA for deletion (I_Cookie=7A8ECEC78AF9ED8C
    R_Cookie=88BADF7979DF25DC) reason = DEL_REASON_PEER_NOT_RESPONDING

    50 19:20:40.703 10/22/06 Sev=Info/4 IKE/0x63000013
    SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 209.178.198.242

    51 19:20:41.218 10/22/06 Sev=Info/4 IKE/0x6300004A
    Discarding IKE SA negotiation (I_Cookie=7A8ECEC78AF9ED8C
    R_Cookie=88BADF7979DF25DC) reason = DEL_REASON_PEER_NOT_RESPONDING

    52 19:20:41.218 10/22/06 Sev=Info/4 CM/0x63100012
    Phase 1 SA deleted before first Phase 2 SA is up cause by
    "DEL_REASON_PEER_NOT_RESPONDING". 0 Crypto Active IKE SA, 0 User
    Authenticated IKE SA in the system

    53 19:20:41.218 10/22/06 Sev=Info/5 CM/0x63100025
    Initializing CVPNDrv

    54 19:20:41.218 10/22/06 Sev=Info/4 IKE/0x63000001
    IKE received signal to terminate VPN connection

    55 19:20:41.250 10/22/06 Sev=Info/4 IKE/0x63000085
    Microsoft IPSec Policy Agent service started successfully

    56 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
    Deleted all keys

    57 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
    Deleted all keys

    58 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
    Deleted all keys

    59 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x6370000A
    IPSec driver successfully stopped
     
    , Oct 23, 2006
    #1
    1. Advertising

  2. In article <>,
    <> wrote:
    >I am using VPN client to connect to a PIX firewall. I get the error:
    >" Secure VPN connection terminated locally by the Client. Reason 412:
    >The remote peer is no longer responding". I am attaching the log below.
    >Someone (Walter?) please
    >help me. Thanks & Regards


    You are getting through Phase 1 okay, but having trouble with Phase 2.

    In my experience, Phase 1 is all exchanged with the public IP of the
    client, but Phase 2 is exchanged with the IP that has been negotiated
    for the link.

    I have seen full Phase 1 with Phase 2 completely failed; in our
    situation, the problem was that the routing for the negotiated IP
    went by a different path than for the basic link IP -- the way we
    had things arranged, it was even going to a different interface and
    different vlan. It was a real puzzle in the beginning, until eventually
    I happened to notice that the interface name I was seeing in the log
    for the Phase 2 negotiations wasn't the expected interface.
     
    Walter Roberson, Oct 23, 2006
    #2
    1. Advertising

  3. Guest

    Walter Roberson wrote:
    > In article <>,
    > <> wrote:
    > >I am using VPN client to connect to a PIX firewall. I get the error:
    > >" Secure VPN connection terminated locally by the Client. Reason 412:
    > >The remote peer is no longer responding". I am attaching the log below.
    > >Someone (Walter?) please
    > >help me. Thanks & Regards

    >
    > You are getting through Phase 1 okay, but having trouble with Phase 2.
    >
    > In my experience, Phase 1 is all exchanged with the public IP of the
    > client, but Phase 2 is exchanged with the IP that has been negotiated
    > for the link.
    >
    > I have seen full Phase 1 with Phase 2 completely failed; in our
    > situation, the problem was that the routing for the negotiated IP
    > went by a different path than for the basic link IP -- the way we
    > had things arranged, it was even going to a different interface and
    > different vlan. It was a real puzzle in the beginning, until eventually
    > I happened to notice that the interface name I was seeing in the log
    > for the Phase 2 negotiations wasn't the expected interface.


    Hi Walter,
    Many thanks for analyzing the logs. The IP address I used was that of
    the PIX firewall. Should I be using the IP address of the host behind
    the firewall? Also, I am not clear about the solution you are
    suggesting. I am attaching the firewall config. Thanks & Regards

    iexpect-corp# show config
    : Saved
    :
    PIX Version 6.1(1)
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password <>encrypted
    passwd <> encrypted
    hostname iexpect-corp
    fixup protocol ftp 21
    fixup protocol http 80
    fixup protocol h323 1720
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sqlnet 1521
    fixup protocol sip 5060
    fixup protocol skinny 2000
    no fixup protocol smtp 25
    names
    name 192.168.5.13 njrep1
    name 192.168.5.150 trig1
    name 192.168.5.151 trig2
    name 192.168.5.61 brett
    name 192.168.5.152 sfg2
    name 192.168.5.9 corp-smtp2
    name 192.168.5.10 corp-smtp
    name 192.168.11.10 corpsmtp2
    name 192.168.11.58 sfg
    name 192.168.11.73 pepsanchez
    access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0
    255.255.255.0
    access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0
    255.255.255.0
    access-list incoming permit tcp any host 209.178.198.243 eq smtp
    access-list incoming permit tcp any host 209.178.198.244 eq smtp
    access-list incoming permit icmp any any echo-reply
    access-list incoming permit icmp any any time-exceeded
    access-list incoming permit icmp any any unreachable
    access-list incoming permit tcp any host 209.178.198.243 eq 5631
    access-list incoming permit tcp any host 209.178.198.243 eq 5632
    access-list incoming permit udp any host 209.178.198.243 eq 5632
    access-list incoming permit udp host 216.34.112.198 eq dnsix any
    access-list incoming permit udp host 216.33.202.54 eq dnsix any
    access-list incoming permit tcp any eq telnet host 216.74.138.147
    access-list incoming permit tcp any host 209.178.198.244 eq telnet
    access-list incoming permit tcp any eq telnet host 209.178.198.244
    access-list incoming permit tcp any host 209.178.198.243 eq www
    access-list incoming permit tcp any host 209.178.198.244 eq www
    access-list incoming permit tcp any host 209.178.198.244 eq ftp
    access-list incoming permit tcp any eq ftp host 209.178.198.244
    access-list incoming permit tcp any host 209.178.198.245 eq 22
    access-list incoming permit tcp any host 209.178.198.245 eq www
    access-list incoming permit tcp any host 209.178.198.243 eq 3389
    access-list incoming permit tcp any host 209.178.198.244 eq 3389
    access-list incoming permit tcp any host njrep1 eq 22
    access-list incoming permit tcp any host njrep1 eq ftp
    access-list incoming permit tcp any host 209.178.198.247 eq 4662
    access-list incoming permit udp any host 209.178.198.247 eq 4672
    access-list incoming permit tcp any host 209.178.198.249 eq www
    access-list incoming permit tcp any host 209.178.198.245 eq 443
    access-list incoming permit tcp any host 209.178.198.249 eq 22
    access-list incoming permit tcp any host 209.178.198.254 eq 5900
    access-list incoming permit tcp 202.138.142.224 255.255.255.224 host
    209.178.198.248 eq 443
    access-list incoming permit tcp any host 209.178.198.249 eq 443
    access-list incoming permit tcp any host 209.178.198.254 eq www
    access-list incoming permit tcp any host 209.178.198.254 eq 129
    access-list incoming permit tcp any host 209.178.198.254 eq 132
    access-list incoming permit tcp any host 209.178.198.243 eq ftp
    access-list incoming permit icmp any host 209.178.198.254
    access-list incoming permit icmp any host 209.178.198.243
    access-list incoming permit icmp any host 209.178.198.248
    access-list incoming permit tcp any host 209.178.198.243
    access-list outgoing permit tcp any any
    access-list outgoing permit icmp any any
    access-list outgoing permit icmp any any echo-reply
    access-list outgoing permit udp any any
    access-list outgoing permit tcp any any eq www
    access-list outgoing permit tcp any host 216.239.35.101 eq www
    access-list outgoing permit udp any host 216.34.112.198 eq dnsix
    access-list outgoing permit udp any host 216.33.202.54 eq dnsix
    pager lines 24
    logging on
    interface ethernet0 10baset
    interface ethernet1 10baset
    mtu outside 1500
    mtu inside 1500
    ip address outside 209.178.198.242 255.255.255.240
    ip address inside 192.168.5.1 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    ip local pool corp-home 192.168.99.1-192.168.99.224
    pdm history enable
    arp timeout 60
    global (outside) 1 209.178.198.252-209.178.198.253
    global (outside) 1 209.178.198.251
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255
    alias (inside) sfg2 209.178.198.249 255.255.255.255
    alias (inside) corp-smtp 209.178.198.243 255.255.255.255
    alias (inside) 192.168.5.149 209.178.198.254 255.255.255.255
    alias (inside) 192.168.11.150 209.178.198.245 255.255.255.255
    static (inside,outside) 209.178.198.245 trig1 netmask 255.255.255.255 0
    0
    static (inside,outside) 209.178.198.246 trig2 netmask 255.255.255.255 0
    0
    static (inside,outside) 209.178.198.243 corp-smtp netmask
    255.255.255.255 0 0
    static (inside,outside) 209.178.198.249 sfg2 netmask 255.255.255.255 0
    0
    static (inside,outside) 209.178.198.254 192.168.5.149 netmask
    255.255.255.255 0 0
    static (inside,outside) 209.178.198.250 192.168.5.63 netmask
    255.255.255.255 0 0
    static (inside,outside) 209.178.198.244 corp-smtp2 netmask
    255.255.255.255 0 0
    static (inside,outside) 209.178.198.248 sfg netmask 255.255.255.255 0 0
    static (inside,outside) 209.178.198.247 pepsanchez netmask
    255.255.255.255 0 0
    access-group incoming in interface outside
    route outside 0.0.0.0 0.0.0.0 209.178.198.241 1
    route inside 192.168.11.0 255.255.255.0 192.168.5.2 1
    route inside 192.168.254.0 255.255.255.0 192.168.5.2 1
    timeout xlate 3:00:00
    timeout conn 3:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
    0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server RADIUS protocol radius
    http server enable
    http corp-smtp2 255.255.255.255 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-ipsec
    sysopt ipsec pl-compatible
    no sysopt route dnat
    crypto ipsec transform-set iexpect esp-des esp-md5-hmac
    crypto ipsec transform-set myset esp-des esp-md5-hmac
    crypto dynamic-map dynmap 10 set transform-set myset
    crypto map corp 1 ipsec-isakmp
    crypto map corp 1 match address ipsec
    crypto map corp 1 set peer 216.74.138.157
    crypto map corp 1 set transform-set iexpect
    crypto map corp 10 ipsec-isakmp dynamic dynmap
    crypto map corp client configuration address initiate
    crypto map corp client configuration address respond
    crypto map corp interface outside
    isakmp enable outside
    isakmp key ******** address 216.74.138.157 netmask 255.255.255.255
    isakmp identity address
    isakmp policy 1 authentication pre-share
    isakmp policy 1 encryption des
    isakmp policy 1 hash md5
    isakmp policy 1 group 1
    isakmp policy 1 lifetime 86400
    isakmp policy 10 authentication pre-share
    isakmp policy 10 encryption des
    isakmp policy 10 hash md5
    isakmp policy 10 group 2
    isakmp policy 10 lifetime 86400
    vpngroup corphome address-pool corp-home
    vpngroup corphome dns-server 192.168.1.6
    vpngroup corphome wins-server 192.168.1.6
    vpngroup corphome default-domain corp.iexpect.com
    vpngroup corphome idle-time 1800
    vpngroup corphome password ********
    telnet 0.0.0.0 0.0.0.0 outside
    telnet corp-smtp 255.255.255.255 inside
    telnet 192.168.5.2 255.255.255.255 inside
    telnet 192.168.11.0 255.255.255.0 inside
    telnet 192.168.5.0 255.255.255.0 inside
    telnet njrep1 255.255.255.255 inside
    telnet corp-smtp2 255.255.255.255 inside
    telnet timeout 5
    ssh 0.0.0.0 0.0.0.0 outside
    ssh 209.178.198.0 255.255.255.0 outside
    ssh njrep1 255.255.255.255 inside
    ssh 192.168.5.0 255.255.255.0 inside
    ssh timeout 5
    terminal width 80
    Cryptochecksum:eca17c51a788c2eefbaebde0f2ea86f0
    iexpect-corp#
     
    , Oct 23, 2006
    #3
  4. In article <>,
    <> wrote:

    >PIX Version 6.1(1)


    You really should upgrade that to get rid of the known security
    problems. If you are the registered owner of the device (e.g., not
    bought used via ebay) then you are entitled to a free upgrade to
    the latest 6.1(*) because of the security issues.

    >access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0 255.255.255.0
    >access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0 255.255.255.0


    >access-list outgoing permit tcp any any
    >access-list outgoing permit icmp any any
    >access-list outgoing permit icmp any any echo-reply


    echo-reply is a subset of 'any' so the second permit icmp is redundant.

    >access-list outgoing permit udp any any
    >access-list outgoing permit tcp any any eq www


    tcp www is a subset of the earlier tcp 'any' so the above permit is
    redundant.

    >access-list outgoing permit tcp any host 216.239.35.101 eq www


    permit tcp to a specific hosts' www is a subset of permitting tcp
    www to 'any', so this statement is redundant against the previous
    (which in turn is redundant against the first)

    >access-list outgoing permit udp any host 216.34.112.198 eq dnsix
    >access-list outgoing permit udp any host 216.33.202.54 eq dnsix


    These udp are subsets of permit udp 'any' so these are redundant.

    These redundancies will not, however, have any effect on your current
    difficulties.

    >ip address outside 209.178.198.242 255.255.255.240
    >ip address inside 192.168.5.1 255.255.255.0


    >ip local pool corp-home 192.168.99.1-192.168.99.224


    >global (outside) 1 209.178.198.252-209.178.198.253
    >global (outside) 1 209.178.198.251


    >nat (inside) 1 0.0.0.0 0.0.0.0 0 0


    >alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255


    I was going to give you the standard warning about alias being obsolete,
    but I see that you are only running 6.1(1), in which it is still
    officially necessary. (Personally I never found a use for it!)

    [several static, none involving 192.168.99.1]

    >access-group incoming in interface outside


    Your access-list 'outgoing' appears to be unused.

    >route outside 0.0.0.0 0.0.0.0 209.178.198.241 1
    >route inside 192.168.11.0 255.255.255.0 192.168.5.2 1
    >route inside 192.168.254.0 255.255.255.0 192.168.5.2 1


    >sysopt connection permit-ipsec
    >sysopt ipsec pl-compatible


    pl-compatible is obsolete unless you a connecting to a PIX 4 system
    running an obscure add-on VPN board that uses protocols that
    predate IPSec.

    >crypto map corp 1 match address ipsec


    >crypto map corp 10 ipsec-isakmp dynamic dynmap
    >crypto map corp client configuration address initiate
    >crypto map corp client configuration address respond
    >crypto map corp interface outside
    >isakmp enable outside


    >isakmp policy 1 authentication pre-share
    >isakmp policy 1 encryption des
    >isakmp policy 1 hash md5
    >isakmp policy 1 group 1
    >isakmp policy 1 lifetime 86400
    >isakmp policy 10 authentication pre-share
    >isakmp policy 10 encryption des
    >isakmp policy 10 hash md5
    >isakmp policy 10 group 2
    >isakmp policy 10 lifetime 86400


    Better security policies should have lower policy numbers. des md5 group 2
    is more secure than des md5 group 1, so put the group 2 entry as
    a lower policy number than than the group 1 entry.

    >vpngroup corphome address-pool corp-home



    Okay, what you've done is configured the vpn client software to get
    a link IP address from you, and that link IP is to be drawn from
    the address range defined by corp-home, 192.168.99.1-192.168.99.224 .

    You do not have a nat 0 access-list for traffic to 192.168.99.*
    so traffic destined to that range will have its source address NAT'd
    in accordance with your nat 1 / global 1 policy. So the outgoing
    VPN traffic will have a source IP of 209.178.198.251, .252, or .253 .

    You do not have any static or alias for the destination address
    range 192.168.99.1-192.168.99.224 so the destination IP for that
    traffic will not be modified by the NAT process.

    At this point, you have a packet that you want to go into the
    VPN tunnel, and the source IP for that packet is
    209.178.198.251 - .253, and the destination IP for that packet
    is 192.168.99.1-192.168.99.224 . That traffic will be compared to
    the defined crypto-map match-address policies. The access-list
    named 'ipsec' is not going to match that traffic because for that
    access-list the destinations are 10.something .

    When you connected via the VPN client software, your connection was
    permitted by way of the crypto dynamic map configurations. That
    connection process automatically generated a new temporary access
    list with a destination equal to the negotiated address for the link,
    and automatically generated a temporary match-address, and corresponding
    security associations will be created.

    Now what you need to know is what the *source* IP range is for that
    automatically generated access-list being used in the temporary
    match-address. And I think what you will find is that the source
    IP for that list is *not* 209.178.198.251, .252, or .253.


    To make a long story short, the fix is:

    access-list nonat permit 192.168.5.0 255.255.255.0 192.168.99.0 255.255.255.255
    access-list nonat permit 192.168.11.0 255.255.255.0 192.168.99.0 255.255.255.255
    nat (inside) 0 access-list nonat

    This will keep the PIX from NAT'ing the source IP for the traffic
    destined to the VPN, so the traffic will match the automatically generated
    access-list. (Test it, though -- I am not certain that the
    automatically generated ACL will include 192.168.11.0 as a source)
     
    Walter Roberson, Oct 23, 2006
    #4
  5. Guest

    Walter Roberson wrote:
    > In article <>,
    > <> wrote:
    >
    > >PIX Version 6.1(1)

    >
    > You really should upgrade that to get rid of the known security
    > problems. If you are the registered owner of the device (e.g., not
    > bought used via ebay) then you are entitled to a free upgrade to
    > the latest 6.1(*) because of the security issues.
    >
    > >access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0 255.255.255.0
    > >access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0 255.255.255.0

    >
    > >access-list outgoing permit tcp any any
    > >access-list outgoing permit icmp any any
    > >access-list outgoing permit icmp any any echo-reply

    >
    > echo-reply is a subset of 'any' so the second permit icmp is redundant.
    >
    > >access-list outgoing permit udp any any
    > >access-list outgoing permit tcp any any eq www

    >
    > tcp www is a subset of the earlier tcp 'any' so the above permit is
    > redundant.
    >
    > >access-list outgoing permit tcp any host 216.239.35.101 eq www

    >
    > permit tcp to a specific hosts' www is a subset of permitting tcp
    > www to 'any', so this statement is redundant against the previous
    > (which in turn is redundant against the first)
    >
    > >access-list outgoing permit udp any host 216.34.112.198 eq dnsix
    > >access-list outgoing permit udp any host 216.33.202.54 eq dnsix

    >
    > These udp are subsets of permit udp 'any' so these are redundant.
    >
    > These redundancies will not, however, have any effect on your current
    > difficulties.
    >
    > >ip address outside 209.178.198.242 255.255.255.240
    > >ip address inside 192.168.5.1 255.255.255.0

    >
    > >ip local pool corp-home 192.168.99.1-192.168.99.224

    >
    > >global (outside) 1 209.178.198.252-209.178.198.253
    > >global (outside) 1 209.178.198.251

    >
    > >nat (inside) 1 0.0.0.0 0.0.0.0 0 0

    >
    > >alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255

    >
    > I was going to give you the standard warning about alias being obsolete,
    > but I see that you are only running 6.1(1), in which it is still
    > officially necessary. (Personally I never found a use for it!)
    >
    > [several static, none involving 192.168.99.1]
    >
    > >access-group incoming in interface outside

    >
    > Your access-list 'outgoing' appears to be unused.
    >
    > >route outside 0.0.0.0 0.0.0.0 209.178.198.241 1
    > >route inside 192.168.11.0 255.255.255.0 192.168.5.2 1
    > >route inside 192.168.254.0 255.255.255.0 192.168.5.2 1

    >
    > >sysopt connection permit-ipsec
    > >sysopt ipsec pl-compatible

    >
    > pl-compatible is obsolete unless you a connecting to a PIX 4 system
    > running an obscure add-on VPN board that uses protocols that
    > predate IPSec.
    >
    > >crypto map corp 1 match address ipsec

    >
    > >crypto map corp 10 ipsec-isakmp dynamic dynmap
    > >crypto map corp client configuration address initiate
    > >crypto map corp client configuration address respond
    > >crypto map corp interface outside
    > >isakmp enable outside

    >
    > >isakmp policy 1 authentication pre-share
    > >isakmp policy 1 encryption des
    > >isakmp policy 1 hash md5
    > >isakmp policy 1 group 1
    > >isakmp policy 1 lifetime 86400
    > >isakmp policy 10 authentication pre-share
    > >isakmp policy 10 encryption des
    > >isakmp policy 10 hash md5
    > >isakmp policy 10 group 2
    > >isakmp policy 10 lifetime 86400

    >
    > Better security policies should have lower policy numbers. des md5 group 2
    > is more secure than des md5 group 1, so put the group 2 entry as
    > a lower policy number than than the group 1 entry.
    >
    > >vpngroup corphome address-pool corp-home

    >
    >
    > Okay, what you've done is configured the vpn client software to get
    > a link IP address from you, and that link IP is to be drawn from
    > the address range defined by corp-home, 192.168.99.1-192.168.99.224 .
    >
    > You do not have a nat 0 access-list for traffic to 192.168.99.*
    > so traffic destined to that range will have its source address NAT'd
    > in accordance with your nat 1 / global 1 policy. So the outgoing
    > VPN traffic will have a source IP of 209.178.198.251, .252, or .253 .
    >
    > You do not have any static or alias for the destination address
    > range 192.168.99.1-192.168.99.224 so the destination IP for that
    > traffic will not be modified by the NAT process.
    >
    > At this point, you have a packet that you want to go into the
    > VPN tunnel, and the source IP for that packet is
    > 209.178.198.251 - .253, and the destination IP for that packet
    > is 192.168.99.1-192.168.99.224 . That traffic will be compared to
    > the defined crypto-map match-address policies. The access-list
    > named 'ipsec' is not going to match that traffic because for that
    > access-list the destinations are 10.something .
    >
    > When you connected via the VPN client software, your connection was
    > permitted by way of the crypto dynamic map configurations. That
    > connection process automatically generated a new temporary access
    > list with a destination equal to the negotiated address for the link,
    > and automatically generated a temporary match-address, and corresponding
    > security associations will be created.
    >
    > Now what you need to know is what the *source* IP range is for that
    > automatically generated access-list being used in the temporary
    > match-address. And I think what you will find is that the source
    > IP for that list is *not* 209.178.198.251, .252, or .253.
    >
    >
    > To make a long story short, the fix is:
    >
    > access-list nonat permit 192.168.5.0 255.255.255.0 192.168.99.0 255.255.255.255
    > access-list nonat permit 192.168.11.0 255.255.255.0 192.168.99.0 255.255.255.255
    > nat (inside) 0 access-list nonat
    >
    > This will keep the PIX from NAT'ing the source IP for the traffic
    > destined to the VPN, so the traffic will match the automatically generated
    > access-list. (Test it, though -- I am not certain that the
    > automatically generated ACL will include 192.168.11.0 as a source)


    Hi Walter
    Many thanks for your kind response in detail. I added the above access
    lists with a minor modification as follows:

    access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.99.0
    255.255.255.255
    access-list nonat permit ip 192.168.11.0 255.255.255.0 192.168.99.0
    255.255.255.255

    Apparently they are not working. Kindly let me know what else to try.

    Best Regards
     
    , Oct 24, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug A Moller

    Need help with peer to peer no hub network

    Doug A Moller, Jun 23, 2004, in forum: Wireless Networking
    Replies:
    3
    Views:
    5,803
  2. James

    Peer no longer responding

    James, Nov 18, 2005, in forum: Cisco
    Replies:
    4
    Views:
    3,966
    James
    Nov 21, 2005
  3. James
    Replies:
    30
    Views:
    326,636
    diggisaur
    Jan 15, 2014
  4. James
    Replies:
    3
    Views:
    2,934
    James
    Oct 3, 2006
  5. Replies:
    5
    Views:
    2,821
Loading...

Share This Page