Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

How does "inspect icmp error" and the ASA treats ICMP packets by default.

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:

migrzela3.png

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.

migrzela4.png

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

Version history
Revision #:
1 of 1
Last update:
‎01-04-2013 08:02 AM
Updated by:
 
Labels (1)