Crypto Map Flowchart ? How does a router/ASA processes a Crypto Map ?

 

Hi,

Can anybody please explain the process of processing a crypto map on an interface ?

Crypto Map priortiy ? Flow of packet from Engine to interface and then processing of crypto map ?

 

I am trying to do S2S between R1 & R2 and Remote access between a client (connected to ISP) and R1,

and if the priority/line entry of Crypto Map (Remote Acess) is > Crypto Map (S2S) then VPNs stop working properly.

 

(e.g. for RA crypto map entry is at line 10 and for S2S crypto map entry is at 111)

Comments

  • Hi,

         So based on what you're saying, actually the priority for RA crypto-map entry is lower (number) than priority for S2S entry. When a router/ASA receives an inbound IKEv1 negotiation, if the interface on which is received has a crypto-map attached, it negotiates Phase1 and afterwards, for Phase2, it checks all crypto-map entries from lowest entry number (highest priority) to highest entry number (lowest priority) and stops on first perfect match (based on the match acl, set transform-set and set peer); however because the RA entry has no match or set commands, it acts like a catch all, this is why basically both RA and S2S will match on the dynamic crypto-map entry, but S2S will fail because of proxy-acl negotiation failure.

         When the router has a packet in its outbound buffer of an interface where a crypto-map is attached, it checks all crypto-map entries for the match acl statement (top-down based on the crypto-map priority number) and stops on first match, afterwards it starts IKEv1 negotiation with the peer of the respective crypto-map entry.

         Having these said, the dynamic crypto-map entry attached to a static crypto-map should always have a higher entry number (lower priority) than all other static crypto map entries.

    Regards,

    Cristian.

  • Hi Cristian,

     

    Thanx a lot for your valuable feedback. May I take the liberty of extending this conversation a bit more because to be fairly honest I am a bit stuck at a point. 

    "However because the RA entry has no match or set commands, it acts like a catch all, this is why basically both RA and S2S will match on the dynamic crypto-map entry, but S2S will fail because of proxy-acl negotiation failure."

    I get it that Because the RA Crypto Map (when set to a Higher priority as compared to S2S crypto map) catches all the traffic, be it of S2S, and thus happens the clash. Setting the priority of RA low works like a charm.

    But what I am not able to understand is that How come S2S traffic is considered as Interesting Traffic by RA Crypto Map as there are no such parameters for the same (like a Crypto ACL or something like that.)

    (For my convenience, attaching a Screenshot with this reply.)

    When traffic initiates from R1 from its private LAN to the private LAN of R2, how is that traffic going to be identified and processed by RA Crypto Map ?

    image

  • Hi,

        Because with RA VPN, the proxy-ACL is negotiated between the client and VPN gateway (actually it is pushed by the VPN gateway and this is basically the split-tunneling policy), which means the RA crypto-map entry matches on any proy-acl basically, the S2S VPN will match on the RA crypto-map entry (if it has higher priority, lower number), but fail on Phase2 due to the proxy-acl mismatch. Try tp have it configured, issue a debug crypto ipsec, initiate the S2S tunnel and you'll see it by yourself. To fix this there are several solutions, most scalable and recommended would be to use ISAKMP profiles and apply it for all crypto-map entries, thus S2S should no longer match on the dynamic crypto-map entry.

    Regards,

    Cristian.

Sign In or Register to comment.