Giving IPsec rule doesn't start the tunnel.

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

AM wrote:

> 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

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

Alex

AM

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

In article < om>,
rave <> wrote:
: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...

--
Look out, there are llamas!

Walter Roberson