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.