Giving IPsec rule doesn't start the tunnel.

Discussion in 'Cisco' started by AM, Jan 3, 2005.

  1. AM

    AM Guest

    I built up an IPsec tunnel.
    The only rule I gave the PIX was permit "access-list VPN_INTERFACE_cryptomap_12 permit ip Local_LAN 255.255.255.0
    Remote_LAN 255.255.0.0"
    It worked, but it was too large for my proposal.

    I went on holidays (as I hope all of you for the January 1st and 2nd) and I then gave

    no access-list VPN_INTERFACE_cryptomap_12 PERMIT ip Local_LAN 255.255.255.0 Remote_LAN 255.255.0.0
    access-list VPN_INTERFACE_cryptomap_12 DENY ip Local_LAN 255.255.255.0 Remote_LAN 255.255.0.0

    to avoid unwanted traffic in my absence.

    PIX warned me there was no access-list specified for VPN_INTERFACE_cryptomap_12 I though it was right and when I will be
    back to my office I'll change the rule from deny to permit.
    Now I've changed the rule but with debug crypto IPsec I receive these warning messages

    "IPSEC(crypto_map_check): crypto map VPN_INTERFACE_map 12 incomplete. No peer or access-list specified."

    Also the PDM shows me there no protect rule for LAN's connected by this IPsec tunnel, but a "wr term" shows me

    access-list VPN_INTERFACE_cryptomap_12 permit ip Local_LAN 255.255.255.0 Remote_LAN 255.255.0.0

    How can I go out this embarassing situation?
    I gave PIX the "sysopt connection permit-ipsec" but it doesn't work.
    I can re-build the protect rule via PDM but I would know which command I must use to resolve this situation.

    Might anyone help me?

    Thanks,
    Alex
     
    AM, Jan 3, 2005
    #1
    1. Advertisements

  2. AM

    AM Guest

    Have I to rebuild the IPsec tunnel? Or can I startup the existing I've defined?

    Alex
     
    AM, Jan 3, 2005
    #2
    1. Advertisements

  3. AM

    rave Guest

    Hi Alex,

    when you remove the access-list from the pix and it is a crypto acl
    then the
    "crypto map mymap match address VPN_INTERFACE_cryptomap_12 "
    command will vanish and that is what the error message you are seeing.
    so after making a new acl make sure you bind the acl with the crypto
    map, make sure the below command is given first:
    "no crypto map mymap interface outside"
    Then rapply the crypto map once again:
    "crypto map mymap interface outside"
    check and then update me.

    Regards,
    Rave
     
    rave, Jan 3, 2005
    #3
  4. :when you remove the access-list from the pix and it is a crypto acl
    :then the
    :"crypto map mymap match address VPN_INTERFACE_cryptomap_12 "
    :command will vanish and that is what the error message you are seeing.

    Exactly.

    :so after making a new acl make sure you bind the acl with the crypto
    :map, make sure the below command is given first:
    :"no crypto map mymap interface outside"
    :Then rapply the crypto map once again:
    :"crypto map mymap interface outside"

    That step is not strictly necessary, but it can be a good practice.

    The reason that it is a good practice is that changes to an ACL
    applied via a crypto map take effect immediately when the PIX is
    deciding whether particular traffic should be part of an IPSec tunnel
    or not. Often while you are working on an ACL, it is temporarily
    not what you want. If the ACL used for a crypto map temporarily
    matches too much traffic (perhaps you made a typing mistake) then
    if the ACL is active on a crypto map, the PIX will notice that
    the extra traffic is coming in to the PIX unprotected and will drop
    the traffic. That can have the unfortunate side effect of locking you
    out of the PIX if you happen to be working remotely.

    Even if you do not lock yourself out, while you are changing the ACL
    the remote system is not going to be updated at the exact same time
    (you will probably change all of one side before going to change the
    other), so you could end up with a mismatch between the two ends
    and that could cause important traffic to be discarded.

    The step that rave suggests, of disabling the crypto map on the
    outside interface, will prevent there from being an inconsistant
    active crypto ACL. You will, though, still have the problem
    that if you are trying to work remotely through the VPN that
    you will immediately lock yourself out when you effectively
    turn off the VPN :( You will also have the big inconsistancy
    between the two ends that one will think that some traffic should
    be protected by the tunel, while the other (the one with the VPN disabled)
    will think that none should be protected, so you still end up with
    problems unless you disable the tunnels on both sides while you do
    the work.


    To avoid at least some of the problems with the inconsistancies,
    there is a slightly different approach you can take which will reduce
    the time-window during which the two sides are out of synchronization.
    In this approach, instead of updating the ACL that is applied
    via the crypto map, you create a -new- ACL that has the characteristics
    that you want. You may end up doing a lot of copy-and-paste... you
    might find it easier to display the acl, copy that into a WordPad
    or other window, change the ACL name throughout with a global search
    and replace, and then make the changes you want. When you are done,
    paste the new ACL in at the PIX configuration prompt.

    When you are satisfied that the new ACL is what you want the new
    configuration to be, and you have done the same for the other end
    so that both new ACLs are ready, then you are ready to put the
    new ACL into effect. Instead of turning off the VPN though, create
    a new crypto map policy with a higher policy number than the old one
    (so the old one is still in effect for the moment), with the new
    map policy having a 'match address' statement referring to the new ACL.
    Do the same on the other side of the link. Then when both sides have
    the new higher-numbered policy in place, use the 'no' configuration
    command to remove the old policy... e.g., no crypto map MyMap 1000
    This will effectively remove the old policy and activate the new
    policy in its place, all as a single step; do the same on the
    other side and the policies will be in sync once again.

    This procedure does not totally eliminate all possibility of
    inconsistancies between the two sides, but it can take the
    inconsistancies down to a few seconds instead of being however many
    minutes it would have taken you to type the new ACL in on each side
    and edit your mistakes and so on. This procedure also removes the
    standard problem where you are configuring remotely and you start the
    ACL with something other than a statement that permits your VPN
    access, thus locking yourself out because the implicit 'deny' on the
    end of ACLs takes effect before you get a chance to type in the
    statement that gives you back access...
     
    Walter Roberson, Jan 4, 2005
    #4
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.