Nowadays with a limited number of IPv4 addresses using PAT is very common. Many hosts on our internal network hiding behind a public address. Have you ever wondered how the table is very common when using PAT, and what's possible for us to retrace ASA? First, some theory. ICMP is a protocol layer 4 and is zdefiniowamne in RFC 792 We call it the Internet Control Message Protocol and is widely used in the diagnosis of the network. How we use there "types" and "Cody", we will focus on two: type 0 and 8 code 0, which correspond to echo reply and echo request. In short, if you type on your computer ping <IP will be sent an ICMP type 8 code 0, and if we are lucky we will be sent an ICMP type 0 code 0 As I mentioned in RFC 792 on page 13 is defined as a package should look for types 0 and 8: https://tools.ietf.org/html/rfc792 Such a package should contain additional fields such as the "Identifier" and "Sequence number". These fields will be used by ASA to create a table for an ICMP session or during translation PAT. 1 We start with a simple case in which we use the access list. For all the examples we will use the same network topology. Before we add ACL on ASA1: R1#ping 192.168.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:   .....   Success rate is 0 percent (0/5) As you can see ping reached the R3 and was sent but not returned to R1: R3# *Mar  1 01:05:09.935: ICMP: echo reply sent, src 192.168.0.3, dst 10.0.0.1 *Mar  1 01:05:11.919: ICMP: echo reply sent, src 192.168.0.3, dst 10.0.0.1 *Mar  1 01:05:13.919: ICMP: echo reply sent, src 192.168.0.3, dst 10.0.0.1 *Mar  1 01:05:15.907: ICMP: echo reply sent, src 192.168.0.3, dst 10.0.0.1 *Mar  1 01:05:17.899: ICMP: echo reply sent, src 192.168.0.3, dst 10.0.0.1 What we see on ASA1: ASA1# sh asp drop  frame acl-drop   Flow is denied by configured rule                           5 Now let's add an ACL for the return movement. (In this case, do not keep any state table, just allow for any movement containing "echo reply" even that which is not expected): access-list outside_in line 1 extended permit icmp any any echo-reply (hitcnt=1) 0x46105ee8 After adding ACL and generate ping again everything works as it should: R1#ping 192.168.0.3   Type escape sequence to abort.   Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:   !!!!!   Success rate is 100 percent (5/5), round-trip min/avg/max = 20/52/140 ms 2 Unfortunately, the ACL permit each incoming ICMP reply as such for which he generated a query (echo request). What if we want to block all incoming traffic if it is not initiated by us? We can use for this purpose inspekcjęICMP. We change ACL on ASA1: access-list outside_in line 1 extended deny ip any any (hitcnt=0) 0x4cc7a6a3 and we disable: policy-map global_policy class inspection_default   inspect icmp Now generate table of R1 and R2 to R3 and ASA1 see: ASA1#show conn detail ICMP outside:192.168.0.3/0 inside:10.0.0.1/18 ICMP outside:192.168.0.3/0 inside:10.0.0.2/3   ASA1# sh service-policy   Global policy:     Service-policy: global_policy       Class-map: inspection_default         Inspect: icmp, packet 10, drop 0, reset-drop 0 As you can see the inspection work, together with a state table for these connections. Table entry is deleted from the times after the response or after the defined timeout icmp. They were created two entries for R1 (10.0.0.1 identifier 18) and for R2 (10.0.0.2 identifier 3) ASA1 wrote the identifier but they did not change and sent the packet to what we see in wiresharku: Let's look at the SRC / DST and Identifier: They are exactly the same as those in our array of connections. 3 Now let us send the PAT and packages with the same identification number. Additional configuration for ASA1: ASA1(config)# nat (inside) 1 10.0.0.0 255.255.255.0 ASA1(config)# global (outside) 1 interface We generate pings from R1 and R2, and let's look at ASA1 again: ASA1#show conn det ICMP outside:192.168.0.3/0 inside:10.0.0.1/21 ICMP outside:192.168.0.3/0 inside:10.0.0.2/21 ASA1#show xlate PAT Global 192.168.0.254(5) Local 10.0.0.1 ICMP id 21 PAT Global 192.168.0.254(6) Local 10.0.0.2 ICMP id 21 We see that the table was set up connections for both packages with the same identification number 21 for different source addresses. At the time of inclusion PAT ASA device in each case will replace the identification number of ICMP packets. We need to look at tables tranclacji to see which number has been replaced with the original number, and see that it was a 5 and 6 as well as we can see in wireshark: In summary, when using PAT, ASA generate new identification numbers, creates an array of connections and the translation table which will know where to send the return package. ... View more

To understand how the inspection icmp error should first understand how the default ASA acts upon receipt of the ICMP packet. All examples are based on the topology: Basic configuration: ########### #####R1#### ########### ! interface Loopback0 ip address 13.0.0.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ! interface FastEthernet0/1 mtu 1000 ip address 10.10.10.1 255.255.255.0 !      ip route 0.0.0.0 0.0.0.0 10.0.0.254 ip route 11.0.0.0 255.255.255.0 Null0 ip route 12.0.0.0 255.255.255.0 10.10.10.4 ########### #####R2#### ########### ! interface FastEthernet0/0 ip address 192.168.0.2 255.255.255.0 ! interface FastEthernet0/1 mtu 1000 ip address 172.16.0.2 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 172.16.0.3 ip route 10.0.0.0 255.255.255.0 192.168.0.254 ########### #####R3#### ########### ! interface FastEthernet0/1 ip address 172.16.0.3 255.255.255.0 ! ip route 10.0.0.0 255.255.255.0 172.16.0.2 ip route 192.168.0.0 255.255.255.0 172.16.0.2 ########### #####R4#### ########### ! interface Loopback0 ip address 172.16.0.3 255.255.255.0 ! interface Loopback1 ip address 10.1.1.3 255.255.255.0 ! interface FastEthernet0/0 ip address 10.0.0.4 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.0.0.1 ########### ####ASA1### ########### interface Ethernet0/0 nameif outside security-level 0 ip address 10.0.0.254 255.255.255.0 ! interface Ethernet0/1 nameif inside security-level 100 ip address 192.168.0.254 255.255.255.0 ! route inside 0.0.0.0 0.0.0.0 192.168.0.2 1 We will focus on a few basic packages such as ICMP echo request, echo reply, host unreachable, port unreachable, time exceeded and fragmentation needed. 1 Simply configure the access list for ASA letting all ICMP packets: access-list outside_in extended permit icmp any any access-group outside_in in interface outside Check now our equipment and we ping from R4 to R1, R3 source address (lo0 on R4). R1 look at your routing table and sends back the ping to ASA1 and this then to R2 and R3. Turn debugi on our routers and watch what happens. R4#ping 10.0.0.1 source lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: Packet sent with a source address of 172.16.0.3 ..... Success rate is 0 percent (0/5) R1# *Mar  1 02:32:45.019: ICMP: echo reply sent, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:47.055: ICMP: echo reply sent, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:49.051: ICMP: echo reply sent, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:51.047: ICMP: echo reply sent, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:53.031: ICMP: echo reply sent, src 10.0.0.1, dst 172.16.0.3 R3# *Mar  1 02:32:44.755: ICMP: echo reply rcvd, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:46.767: ICMP: echo reply rcvd, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:48.799: ICMP: echo reply rcvd, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:50.795: ICMP: echo reply rcvd, src 10.0.0.1, dst 172.16.0.3 *Mar  1 02:32:52.747: ICMP: echo reply rcvd, src 10.0.0.1, dst 172.16.0.3 As you can see ICMP echo reply despite the fact that inquiry has not been generated by someone from the internal network and no state table has not been created, was passed by the ASA. We see how the R1 packet is sent and the R3 get it even though it has not generated a. This is expected behavior when the ASA have ACL to allow ICMP traffic on each. Are we able to prevent this? Yes, see section 3 Is this will be the case all ICMP packets? Fortunately not! 2 Wygenerujmy Now the rest of the interesting packages:      "host unreachable" generate R1 us when we try to ping the network 11.0.0.0/24,      "time exceeded" and "port unreachable" will be returned to us during query "traceroute". "traceroute" We will send a UDP packet to port 33434 with a TTL of 1 The first device will discard the packet and send back "time exceeded" (this will be our first step), and so increase the TTL and send UDP again. All intermediate steps they will send us a "time exceeded" to the last device that will send us a "port unreachable" when we know that it was the last unit.      "fragmentation needed" is like sending a package about the size of 1300 with DF bit set to 1 ktróry after reaching the R1 has to be divided into smaller ones. It is impossible (for DF = 1) for which R1 sends us ICMP packet with the information. Thus, we generate it from R4: R4#ping 11.0.0.1 so lo0 - R1 wygenmeruje nam "host unreachable" R4#ping 12.0.0.1 size 1300 df-bit source lo0 - R1 wygeneruje nam "fragmentation needed" R4#traceroute 12.0.0.1 source lo0 - pierwsze zostanie odesłane "time exceeded" z adresem źródłowym R1 R4#traceroute 10.0.0.1 source lo0 - jako, że to ostatni krok R1 odeśle "port unreachable" None of the packets generated by R1 does not pass through the ASA: If you apply the "capture interface outside NAME trace details" we will see exactly what has happened with the package: ASA1# sh cap NAZWA packet-number 1 trace det <ominięte kilka linii> Result: output-interface: inside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule The reason for the rejection of the package is despite ACL ACL hit count increases. (here the developers can be a little better than that). Let's try to catch the ASA "ASP_DROP capture type asp-drop" ASA# sh cap ASP_DROP    4: 04:33:33.509266 10.0.0.1 > 172.16.0.3: icmp: host 11.0.0.1 unreachable <usunięte>    6: 03:22:44.410547 10.0.0.1 > 172.16.0.3: icmp: 12.0.0.1 unreachable - need to frag (mtu 1000) <usunięte>   10: 03:23:23.369670 10.0.0.1 > 172.16.0.3: icmp: time exceeded in-transit <usunięte>   13: 03:23:34.758734 10.0.0.1 > 172.16.0.3: icmp: 10.0.0.1 udp port 33434 unreachable As we have seen in the case of ICMP traffic permit same ACL is not enough to package its way through the ASA. It's the end of the device and most of the tools to identify network uses ICMP packets, and the default behavior of network devices. 3 Let's see what happens when you turn on "inspect icmp" Add configurations for ASA1: policy-map global_policy class inspection_default   inspect icmp service-policy global_policy global This time, the package is not passed and the reason is: ASA1# sh cap NAZWA packet-number 24 trace det Result: output-interface: inside output-status: up output-line-status: up Action: drop Drop-reason: (inspect-icmp-seq-num-not-matched) ICMP Inspect seq num not matched As you can see when you turn on "inspect icmp" will be created backplane for ICMP traffic generated from inside the network. If the ASA does not find an entry in a table simply discard the packet. 4 As default, the ASA retains the "traceroute" Let's add a static intensity and the possibility of "traceroute". ASA1(config)# static (inside,outside) 10.0.0.3 172.16.0.3 access-list outside_in extended permit udp any any range 33434 33464 Now generate a "traceroute" from R1 to R3 hidden behind NAT on ASA1 (10.0.0.3) What kind of response we see on R1: R1#traceroute 10.0.0.3   Type escape sequence to abort. Tracing the route to 10.0.0.3   1 10.0.0.3 40 msec 16 msec 24 msec   2 10.0.0.3 60 msec *  92 msec R1#ping 10.0.0.3 size 1300 df-bit Type escape sequence to abort. Sending 5, 1300-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with the DF bit set M.M.M As you can see I do not aspirin reduces the TTL by what is like invisible to the 'traceroute' and at the same time masks the response of R2 (all the steps on the route to a destination if there were more) as you can see in debagach: R1# *Mar  1 04:07:01.526: ICMP: dst (10.0.0.1) frag. needed and DF set unreachable rcv from 10.0.0.3 R1# *Mar  1 04:07:33.638: ICMP: time exceeded rcvd from 10.0.0.3 R1# *Mar  1 04:07:36.842: ICMP: dst (10.0.0.1) port unreachable rcv from 10.0.0.3 According to RFC 792 all ICMP packets telling us about an error message ("error message") should include a fragment packet that generated the error. Knowing this fragment contained in the IP header and the next header of 8 bytes (if UDP fits on the whole). After the ASA knows just how ICMP packet generated an error and can check whether it is the original package its session table. If not then just discard the packet. 5 Let us now now "inspect icmp error" Re-run the previous command, and observe what's going to happen: R1#traceroute 10.0.0.3   Type escape sequence to abort. Tracing the route to 10.0.0.3     1 192.168.0.2 52 msec 20 msec 20 msec   2 10.0.0.3 56 msec *  72 msec R1#ping 10.0.0.3 size 1300 df-bit Type escape sequence to abort. Sending 5, 1300-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with the DF bit set M.M.M Success rate is 0 percent (0/5) As you can see in debagach now answers come from the actual product. ASA does not hide the intermediate devices. R1# *Mar  1 04:16:00.922: ICMP: time exceeded rcvd from 192.168.0.2 R1# *Mar  1 04:16:04.114: ICMP: dst (10.0.0.1) port unreachable rcv from 10.0.0.3 R1# *Mar  1 04:15:51.950: ICMP: dst (10.0.0.1) frag. needed and DF set unreachable rcv from 192.168.0.2 * This will occur only when the ASA will not set different rules laminates. If for example, you would add the PAT: nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface To get the previous error and packages do not come back to us: ASA1# sh cap NAZWA packet-number 3 trace det    3: 04:19:07.802296 c201.1754.0000 00ab.cd92.5201 0x0800 70: 192.168.0.2 > 10.0.0.1: icmp: time exceeded in-transit [tos 0xc0]  (ttl 255, id 77) <usunięte linie> Result: output-interface: outside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule ... View more

Dynamic L2L Dynamic crypto maps gives us the opportunity to create a L2L tunnels where the remote peer's address is unknown. The ASA configuration we have built a group called DefaultL2LGroup. If you do not configure any other matchowania to tunnel-group that is also where you will land a dynamic peer.   W tym przypadku będziemy szyfrować traffic pomiędzy R1 i R2. Obydwa peery maja zmieniajace sie dynamiczne IP. Uzyjemy ASA jako hub aby hairpin traffic pomiedzy nimi (czerwona linia) . Na R1 i R2 stworzymy crypto-mape zawierajaca 10.0.0.0/16 subnet.   In this case, we will encrypt the traffic between R1 and R2. Both peers may changing dynamic IP. We'll use ASA as a hub for traffic between them hairpin (red line).     Required configuration: ASA1 will be HUB:   ASA1 interface GigabitEthernet0/0 nameif outside security-level 0 ip address 192.168.0.254 255.255.255.0 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.0.0.254 255.255.255.0   To grant the Route hairpin or otherwise u-turn:   same-security-traffic permit intra-interface   Create a dynamic map and binds it to static:   crypto ipsec transform-set Tr_Set esp-3des esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map Dyn_Map 10 set transform-set Tr_Set crypto dynamic-map Dyn_Map 10 set reverse-route crypto map VPN 10 ipsec-isakmp dynamic Dyn_Map crypto map VPN interface outside crypto isakmp enable outside crypto isakmp policy 10 authentication pre-share encryption 3des hash sha group 2 lifetime 86400   Remote dynamic peer will land here so I set the password:   tunnel-group DefaultL2LGroup ipsec-attributes pre-shared-key Cisco123   For demonstration purposes permit ping:   policy-map global_policy class inspection_default   inspect icmp   Configure the remote routers R1 and R2. (for dynamic related companies usually configure L2L VPN tunnel):   R1 interface FastEthernet0/0 ip address 192.168.0.1 255.255.255.0 duplex auto speed auto crypto map VPN   interface Loopback0 ip address 10.0.1.1 255.255.255.0   Basic L2L configuration:   crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set Tr_Set esp-3des esp-sha-hmac ! crypto map VPN 10 ipsec-isakmp set peer 192.168.0.254 set transform-set Tr_Set match address VPN   Crypto map consist networks behind ASA and R2:   ip access-list extended VPN permit ip 10.0.1.0 0.0.0.255 10.0.0.0 0.0.255.255   We add routes, so router knows which interface to send traffic out:   ip route 0.0.0.0 0.0.0.0 192.168.0.254 R2 interface Loopback0 ip address 10.0.2.2 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.0.2 255.255.255.0 duplex auto speed auto crypto map VPN   Basic L2L configuration:   crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set Tr_Set esp-3des esp-sha-hmac ! crypto map VPN 10 ipsec-isakmp set peer 192.168.0.254 set transform-set Tr_Set match address VPN   ip access-list extended VPN permit ip 10.0.2.0 0.0.0.255 10.0.0.0 0.0.255.255   ip route 0.0.0.0 0.0.0.0 192.168.0.254 R3 interface FastEthernet0/1 ip address 10.0.0.3 255.255.255.0   Here, for demonstration purposes, configure IP and route:   ip route 0.0.0.0 0.0.0.0 10.0.0.254   Let's try to pick up a tunnel between R1 and ASA:   R1#ping 10.0.0.3 source lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 .!!!!   ASA1# show crypto ipsec sa interface: outside     Crypto map tag: Dyn_Map , seq num: 10, local addr: 192.168.0.254           local ident (addr/mask/prot/port): ( 10.0.0.0/255.255.0.0/0/0 )       remote ident (addr/mask/prot/port): ( 10.0.1.0/255.255.255.0/0/0 )       current_peer: 192.168.0.1         #pkts encaps: 4 , #pkts encrypt: 4, #pkts digest: 4       #pkts decaps: 4 , #pkts decrypt: 4, #pkts verify: 4         local crypto endpt.: 192.168.0.254, remote crypto endpt.: 192.168.0.1   R1#ping 10.0.2.2 source lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 .....   We can see that the packets destined to R2 reach ASA firewall but does not know where to send:     ASA1# show crypto ipsec sa         #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4       #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9   Lets bridge the tunnel up between R2 and ASA:   R2#ping 10.0.0.3 source lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with a source address of 10.0.2.2 .!!!!   ASA1# show crypto ipsec sa       Crypto map tag: Dyn_Map , seq num: 10, local addr: 192.168.0.254           local ident (addr/mask/prot/port): ( 10.0.0.0/255.255.0.0/0/0 )       remote ident (addr/mask/prot/port): ( 10.0.2.0/255.255.255.0/0/0 )       current_peer: 192.168.0.2          #pkts encaps: 4 , #pkts encrypt: 4, #pkts digest: 4       #pkts decaps: 4 , #pkts decrypt: 4, #pkts verify: 4          local crypto endpt.: 192.168.0.254, remote crypto endpt.: 192.168.0.2   We see you're using our dynamic map Dyn_Map, we used split tunneling option and we sent their proposals to the network between which you want to encrypt traffic. ASA and accept it because the option will add a reverse-route remote network to the routing table:   ASA1# sh route S    10.0.2.0 255.255.255.0 [1/0] via 192.168.0.2, outside S    10.0.1.0 255.255.255.0 [1/0] via 192.168.0.1, outside   Now we can freely communicate between R1 and R2:   R1#ping 10.0.2.2 source lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 !!!!!   For confirmation, we can look at the counters:   ASA1# sh cry ips sa interface: outside     Crypto map tag: Dyn_Map, seq num: 10, local addr: 192.168.0.254         local ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)       remote ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)       current_peer: 192.168.0.1           #pkts encaps: 9 , #pkts encrypt: 9, #pkts digest: 9       #pkts decaps: 14 , #pkts decrypt: 14, #pkts verify: 14         local crypto endpt.: 192.168.0.254, remote crypto endpt.: 192.168.0.1         Crypto map tag: Dyn_Map, seq num: 10, local addr: 192.168.0.254           local ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)       remote ident (addr/mask/prot/port): (10.0.2.0/255.255.255.0/0/0)       current_peer: 192.168.0.2         #pkts encaps: 9 , #pkts encrypt: 9, #pkts digest: 9       #pkts decaps: 9 , #pkts decrypt: 9, #pkts verify: 9     Discontinuous subnets. We now add the L2L tunnel between R1 and R5 (green line). Observe that previously defined the alread traffic between 10.0.0.0/16 we must pay attention to the order will attach crypto maps.   Required configuration:   R1   crypto map VPN 5 ipsec-isakmp set peer 192.168.0.5 set transform-set Tr_Set match address L2L_VPN     ip access-list extended L2L_VPN permit ip 10.0.1.0 0.0.0.255 10.0.5.0 0.0.0.255 R5     interface Loopback0 ip address 10.0.5.5 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.0.5 255.255.255.0 crypto map VPN   Basic L2L configuration:   crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 !         ! crypto ipsec transform-set Tr_Set esp-3des esp-sha-hmac ! crypto ipsec profile DMVPN set transform-set Tr_Set ! crypto gdoi group GDOI identity number 1 server address ipv4 10.0.105.1 ! ! crypto map VPN 5 ipsec-isakmp set peer 192.168.0.1 set transform-set Tr_Set match address L2L_VPN   We define interesting traffic between R1 and R5:   ip access-list extended L2L_VPN permit ip 10.0.5.0 0.0.0.255 10.0.1.0 0.0.0.255   And of course we must condemn the interface:   ip route 0.0.0.0 0.0.0.0 192.168.0.254   Let's raise our first Pre-configured dynamic tunnels between ASA and R1:   R1#ping 10.0.0.3 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 .!!!!   R1#show crypto ipsec sa   interface: FastEthernet0/1     Crypto map tag: VPN, local addr 192.168.0.1      protected vrf: (none)    local  ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)    remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)    current_peer 192.168.0.254 port 500      PERMIT, flags={origin_is_acl,}     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4   Let's try now initiate traffic from R1 to R5. You'll notice that we already have the SPI for the traffic (between R1 and ASA). Adding additional crypto map number 5 because we used an additional tunnel will be raised:   R1#ping 10.0.5.5 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.5.5, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 .!!!!   R1#show crypto ipsec sa   interface: FastEthernet0/1     Crypto map tag: VPN, local addr 192.168.0.1       protected vrf: (none)    local  ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)    remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)    current_peer 192.168.0.254 port 500      PERMIT, flags={origin_is_acl,}     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4        local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.254      path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1      current outbound spi: 0xD269F443(3530159171)      protected vrf: (none)    local  ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)    remote ident (addr/mask/prot/port): (10.0.5.0/255.255.255.0/0/0)    current_peer 192.168.0.5 port 500      PERMIT, flags={origin_is_acl,}     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4   It will be also operated game will be initiated traffic R5 to R1.   R5#ping 10.0.1.1 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: Packet sent with a source address of 10.0.5.5 .!!!!   Proper crypto map is used on R1:   R1#show crypto ipsec sa   interface: FastEthernet0/1     Crypto map tag: VPN, local addr 192.168.0.1      protected vrf: (none)    local  ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)    remote ident (addr/mask/prot/port): (10.0.5.0/255.255.255.0/0/0)    current_peer 192.168.0.5 port 500      PERMIT, flags={origin_is_acl,}     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4     Scenario 2 Problem: User need to set up L2L VPN between two devices.The VPN needs to pass traffic for several sub-nets.There are routers behind all the equipment, so routing isn't a problem, and I understand how to do the traffic matching ACLs so that we get the correct traffic sent over the link. Background info, this is a CME router that's portable in a case, and is designed to operate either off a satellite link or a direct Ethernet link to some public Internet access. The router does an IPSec L2L VPN back to home, and allows an H.323 trunk to permit calling between the phones on the remote system and the main phone system at the head end site. Main site is an ASA 5505 with a static public IP. Remote site is a 2911 router The router has a fixed IP address on a satellite link (FastEthernet 0/1) That link is connected to a satellite modem. The router also has FastEthernet 0/0 set up as DHCP. User have a VPN config in the ASA and in the router that works for the satellite link, using the DefaultL2L tunnel group. At one time, that worked OK for the initial setup. Now, I'm trying to use the same router, connected to the FastEthernet0/0 interface, with it getting a dynamic IP from an ISP. The satellite would be shut down.   The same crypto map is applied to both the FastEthernet 0/0 and FastEthernet0/1 interfaces - so the same VPN tunnel should try to come up over whichever interface is available.   Cisco Doc The Cisco document states that the IPSec L2L tunnels require static IP addressing on each end - "tunnel-group 172.17.1.1 type ipsec-l2l !--- In order to create and manage the database of connection-specific  !--- records for ipsec-l2l—IPsec (LAN-to-LAN) tunnels, use the command !--- tunnel-group in global configuration mode. !--- For L2L connections the name of the tunnel group MUST be the IP  !--- address of the IPsec peer. tunnel-group 172.17.1.1 ipsec-attributes pre-shared-key * !--- Enter the pre-shared-key in order to configure the  !--- authentication method". I asked the vendor for the CME equipment about just using EasyVPN in NEM mode, since I know that would route networks, but he said that won't work for multiple subnets behind routers behind the VPN-endpoints. Is it in fact possible to establish an IPSec L2L VPN tunnel between an ASA with a fixed IP and a remote 29XX router with a dynamic IP address, and route several subnets over that link? Solution:   Well actually to establish a L2L from a unknown IP address, you have two options: 1- Use the DefaultL2LGroup. 2- Use certificate authentication. If a connection arrives as a L2L and the ASA does not have either a crypto map or a tunnel-group, the connection will be landed on the DefaultL2LGroup and the correct dynamic-map. So, please check this out: Dynamic IPsec Tunnel Between a Statically Addressed ASA and a Dynamically Addressed Cisco IOS Router http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b3d511.shtml You can have multiple subnets behind the inside interface of an EasyVPN remote. The feature is named "Multiple Subnet Support" and is described in the configuration-guide: http://www.cisco.com/en/US/partner/docs/ios-ml/ios/sec_conn_esyvpn/configuration/15-0m/sec-easy-vpn-rem.html#GUID-D7DBF82F-FC4C-4A04-A060-21A10647DB7B   Source Discussion: https://supportforums.cisco.com/discussion/11559901/2900-router-asa-l2l-vpn-router-side-dynamic-ip ... View more