dynamic crypto map

Hi. I have a question regarding this document from Cisco.com about creating dynamic crypto maps. 

 

http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14131-ios-804.html

 

in this document, our private IP addresses are 10.1.1.0/24 and 10.2.2.0/24 and they configure NAT in such a way that the traffic to/from these IP addresses don't affected by NAT. my question is about NAT. I mean how do the border routers (sam-i-am and dr_whoovie) know about another network private IP address? for example, "sam-i-am" router gets traffic from local client destined to 10.1.1.0/24 that is another sites's private IP address. without any routing enabled on router or tunnel interfaces, how can this traffic be routed to "dr_whoovie" router? I think this document shows just portion of the whole config, otherwise it is impossible for the test ping at the end of the document to be successful. 

Comments

  • Its to do with the order of operations that the router performs on the packet. Have a look here (particularly the last diagram) http://etherealmind.com/cisco-ios-order-of-operation/

    In the case you are looking at, ignore the ingress features and start at the routing lookup. There is only a default route, so all pakets are sent out to the Internet. The next significant one is the NAT lookup - as you have already determined the NAT configuration ensures that the traffic to be encrypted does not get affected by NAT which allows us to to the crypto match on the original addresses. Finally as the outbound interface has a crypto map, the router will check the traffic against that and work out that it needs to be encrypted and sent to a specific peer. Specifically this is the traffic matched in ACL 115 in the example.

    The example you are looking at is slightly more complicated because only one of the ends has the details of the other - this is a fairly common scenario you might need to use where you have a hub site with a fixed IP and a number of remote sites which use DHCP. The result of this is that only the 'remote' router can initiate the connection. The hub router is set up to accept the connection from any per IP address using the dynamic crypto map. Once the remote route has initiated the connection, the hub will then build a record of where to send the return traffic to in its ipsec sa table

  • timaztimaz ✭✭

    do u mean that the spoke router need not to know where other private IP addresses are and if the traffic needs encryption, it is sent to peer IP address configured regardless of routing table?!

  • 1st q - the location of the other private addresses are defined in the crypto map. The peer defines the public IP of the remote router, the address defines the traffic to be encrypted:

    crypto map rtp 1 ipsec-isakmp  


    set peer 99.99.99.1

    !--- Use the set peer command to specify an IPSec peer in a crypto map entry.

    match address 115

    !--- Include the private-network-to-private-network traffic
    !--- in the encryption process.



    2nd q -the encryption takes place after the routing lookup. The router has already chosen the egress interface based on the default route. The encryption process follows that based on the crypto map applied to the egress interface. If the router had multiple interfaces and it had routed the traffic out of an interface without a crypto map applied, no encryption would take place

  • timaztimaz ✭✭

    so if the router don't have a default route pointing the serial interface and instead have more spesific routes, without having a spesific route to remote private IP addresses, can it send the encrypted traffic through tunnel?

  • timaztimaz ✭✭

    hi; for the sake of test, I've created this simple topology to see if lack of routing entry to the remote network on border routers affects the IPSec. there is EIGRP between R2 and R3 and the config is as follows:

    image

    R1:

    --------

    ip vrf A

     rd 1:1

    !         

    ip vrf B  

     rd 2:2   

    !         

    interface FastEthernet0/0

     ip vrf forwarding A

     ip address 12.12.12.1 255.255.255.0

     duplex auto

     speed auto

    !

    interface FastEthernet0/1

     ip vrf forwarding B

     ip address 13.13.13.1 255.255.255.0

     duplex auto

     speed auto

    !

    ip forward-protocol nd

    ip route vrf A 0.0.0.0 0.0.0.0 12.12.12.2

    ip route vrf B 0.0.0.0 0.0.0.0 13.13.13.3    





    R2:

    --------

    crypto isakmp policy 10

     encr aes

     authentication pre-share

     group 5

     lifetime 3600

    crypto isakmp key cisco address 3.3.3.3

    !

    crypto ipsec transform-set TEST_SET esp-aes esp-sha-hmac 

    !

    crypto map TEST_MAP 10 ipsec-isakmp 

     set peer 3.3.3.3

     set transform-set TEST_SET 

     match address TEST_ACL

    !

    interface Loopback0

     ip address 2.2.2.2 255.255.255.255

    !

    interface FastEthernet0/0

     ip address 12.12.12.2 255.255.255.0

     ip nat inside

     ip virtual-reassembly

     duplex auto

     speed auto

    !

    interface FastEthernet0/1

     ip address 23.23.23.2 255.255.255.0

     ip nat outside

     ip virtual-reassembly

     duplex auto

     speed auto

     crypto map TEST_MAP

    !

    router eigrp 10

     network 2.0.0.0

     network 23.0.0.0

     no auto-summary

    !

    ip access-list extended FOR_NAT

     deny   ip 12.0.0.0 0.255.255.255 13.0.0.0 0.255.255.255

     permit ip 12.0.0.0 0.255.255.255 any

    ip access-list extended TEST_ACL

     permit ip 12.0.0.0 0.255.255.255 13.0.0.0 0.255.255.255





    R3:

    --------

    crypto isakmp policy 10

     encr aes

     authentication pre-share

     group 5

     lifetime 3600

    crypto isakmp key cisco address 2.2.2.2

    !

    crypto ipsec transform-set TEST_SET esp-aes esp-sha-hmac 

    !

    crypto map TEST_MAP 10 ipsec-isakmp 

     set peer 3.3.3.3

     set transform-set TEST_SET 

     match address TEST_ACL

    !

    interface Loopback0

     ip address 3.3.3.3 255.255.255.255

    !

    interface FastEthernet0/0

     ip address 13.13.13.3 255.255.255.0

     ip nat inside

     ip virtual-reassembly

     duplex auto

     speed auto

    !

    interface FastEthernet0/1

     ip address 23.23.23.3 255.255.255.0

     ip nat outside

     ip virtual-reassembly

     no ip route-cache cef

     no ip route-cache

     duplex auto

     speed auto

     crypto map TEST_MAP

    !

    router eigrp 10

     network 3.0.0.0

     network 23.0.0.0

     no auto-summary

    !

    ip access-list extended FOR_NAT

     deny   ip 13.0.0.0 0.255.255.255 12.0.0.0 0.255.255.255

     permit ip 13.0.0.0 0.255.255.255 any

    ip access-list extended TEST_ACL

     permit ip 13.0.0.0 0.255.255.255 12.0.0.0 0.255.255.255

    !

    access-list 100 permit icmp any any

     

     

    then I ran a ping test from R1 VRF A to R1 VRF B interface which was unsuccessful. also there was no encrypted packets regarding to the "sh crypto ipsec sa" command and even the "debug ip packet 100" that I've created on R3 to capture any possible ICMP showed no hit. this is the sign of lacking the routing entry on R2 to the remote network (13.13.13.0/24). 

     

    R1(config)#do ping vrf A 13.13.13.1

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 13.13.13.1, timeout is 2 seconds:

    .U.U.

    Success rate is 0 percent (0/5)

     

    if I write a default route on R2 that points to the fast0/1, in this case, it will reaches R3 and ping test will succeeds; but if there is another router between R2 and R3, this default route on R2 will not work again and this additional router will drop those packets due to lacking the routing entry. finally, all of these indicate that border routers will not ignore process of checking the routing table. and will not forward the interesting traffic through established SA while there is no routing entry. 

  • timaztimaz ✭✭

    can someone verify the scenario above ? what is your idea about routing issue while appliying crypto map on physical interface (without creating tunnel between IPSec endpoints)?

  • timaztimaz ✭✭

    I'm waiting guys. would u mind, please, confirming this scenario? I need to fill the gaps. tnx. 

  • Sorry I'm not 100% sure where your confusion lies.

    The IPsec peers will need to be able to route to one another, and also to route the 'interesting traffic'. A default route will usually accomplish both of these tasks.

    Any routers inbetween just need to route between the IPsec peer endpoints (eg the 'public IPs'). They won't be able to see the internal addressing.

  • If you test this scenario, certainly you will see the problem that I've mentioned. the problem is we exclude internal-to-internal traffic (12.12.12.0 to 13.13.13.0 and vice versa) from NAT. suppose we have 10 routers between R2 and R3 that don't have any routing information about our internal networks (12 and 13 networks). in this situation, our IPSec internal-to-internal traffic will be droped due to routing problem. and even border routers (R2 and R3) will not create an IPSec tunnel between each other to pass traffic, due to the same problem. this is not case while creating tunnel interface for IPSec traffic (using VTI-based IPsec). but applying crypto-map on physical interfaces without creating tunnel causes the problem. in some sites they say that they are successful to run this scenario, but I did not managed to make it to run successfully. so what is my mistake?

  • Hi,

    The crypto-defined on R3 has a wrong statement defined for peer address : 

    crypto map TEST_MAP 10 ipsec-isakmp 

     set peer 3.3.3.3   >>>> should be changed to set peer 2.2.2.2

     set transform-set TEST_SET 

     match address TEST_ACL

     

    Deactivating  NAT  on both R2 and R3 and enabling debug crypto isakmp sa on R2 reveals the following :

    No pre-shared key with 23.23.23.3!


    So I added :


    R2 :

    crypto isakmp key cisco address 23.23.23.3

    R3 :

    crypto isakmp key cisco address 23.23.23.2



    After runing the ping again, the following message has been logged on R2 : 


    *Mar  1 00:53:47.575: IPSEC(ipsec_process_proposal): invalid local address 2.2.2.2




    Now, I changed the peer address in the crypto map to 23.23.23.2 and 23.23.23.3 :


    R2#sh crypto map 

    Crypto Map "TEST_MAP" 10 ipsec-isakmp

    Peer = 23.23.23.3

    Extended IP access list TEST_ACL

        access-list TEST_ACL permit ip 12.12.12.0 0.0.0.255 13.13.13.0 0.0.0.255

    Current peer: 23.23.23.3

    Security association lifetime: 4608000 kilobytes/3600 seconds

    PFS (Y/N): N

    Transform sets={ 

    TEST_SET, 

    }

    Interfaces using crypto map TEST_MAP:

     

    FastEthernet0/1



    Running the ping again resulted in success



    R2#sh cry ips sa | i pkts

        #pkts encaps: 111, #pkts encrypt: 111, #pkts digest: 111

        #pkts decaps: 111, #pkts decrypt: 111, #pkts verify: 111

        #pkts compressed: 0, #pkts decompressed: 0

        #pkts not compressed: 0, #pkts compr. failed: 0

        #pkts not decompressed: 0, #pkts decompress failed: 0

     

    Reapplying NAT in the end has no negative effect, packets still get through.

    Although, very important, I have advertised into EIGRP links between R1 - R2 and R1 - R3. Otherwise, routing lookup would fail on R2 and R3.

     

    R1#ping vrf A 13.13.13.1 re 10

     

    Type escape sequence to abort.

    Sending 10, 100-byte ICMP Echos to 13.13.13.1, timeout is 2 seconds:

    UUUUUUUUUU

     

    Success rate is 0 percent (0/10)




    Good luck !

  • yes you're right about wrong peer address that I mistakingly put it there. but after writing right address, again I faced with the same routing problem. and one thing more; you advertised client-side interfaces on R2 and R3 into internet (I mean EIGRP) that is not suppose to be like that. cause these networks are internal to clients and MUST NOT advertised into EIGRP. and my problem is just there though. in other words, I did not managed to run IPSEC and NAT, while applying Crypto maps on physical interfaces, whithout creating some kind of tunnel interface. did u?

  • Hi,

    In your design, you are doing NAT, meaning that the distant router will
    know the source of the packet - as it will be translated to outside
    interface of the IPsec initiating router (btw, I didn't see any nat
    translation statement in your config , i.e. ip nat inside source list 1
    interface fa0/1 overload), but the initiating router will NOT know how
    to route packet to final destination. 

    The first problem that needs to be addressed is the routing problem. You can either create a gre tunnel between the endpoints and encrypt traffic between them matching all traffic in the proxy-acl or you can do what I presented in my above post, that is to present the destination to the router that is initiating the IPsec tunnel. In this case, it has to do the routing lookup for the final destination matched in the proxy-acl.

    Does this make any sense to you ?

     

     

Sign In or Register to comment.