Skip to main content

Cisco ASA - Order of operations









1. Packet is reached at the ingress interface. 

2. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.

3. Cisco ASA will first verify if this is an existing connection by looking at its internal connection table details. If the packet flow matches an existing connection, then the access−control list (ACL) check is bypassed, and the packet is moved forward.
If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.

4. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count will be incremented by one when the packet matches the ACL entry.

5. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow, and the packet moves forward. Otherwise, the packet is dropped and the information is logged.

6. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built−in inspection engine that inspects each connection as per its pre−defined set of application−level functionalities. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged. Additional Security−Checks will be implemented if a CSC module is involved.

7. The IP header information is translated as per the NAT/PAT rule and checksums are updated accordingly. The packet is forwarded to AIP−SSM for IPS related security checks, when the AIP module is involved.

8. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on global route lookup.

9. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that will take the priority.

10. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. Layer 2 rewrite of MAC header happens at this stage.

11. The packet is transmitted on wire, and Interface counters increment on the egress interface.

Some useful Commands

• Show interface
• Show conn
• Show access−list
• Show xlate
• Show service−policy inspect
• Show run static
• Show run nat
• Show run global
• Show run global
• Show nat
• Show route
• Show arp

Labels:
Location: Bangalore, Karnataka, India

Comments

Post a Comment

Popular posts from this blog

Basic Rules of Checkpoint Firewall

Managing the Firewall Rule Base: Explicit and Implied Rules These are the types of rules in the Rule Base: Explicit rules - Rules that you create to configure which connections the Firewall allows Implied rules - Rules that are based on settings in the Global Properties menu Implied rules allow connections for different services that the Security Gateway uses. For example, the Accept Control Connections option allows packets that control these services: ·          Installing the security policy on a Security Gateway ·          Sending logs from a Security Gateway to the Security Management server ·          Connecting to third party applications, such as RADIUS and TACACS authentication servers Order of Rule Enforcement: Make sure that you understand the importance of the order of rule enforcement to maximize the security of the Firewall. The Firewall always enforces the first rule that matches a connection. It does not enforce later rules tha
Post a Comment
Read more

ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection provide a wealth of information about the state of TCP connections to the ASA. This information can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network. Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command. ASA# show conn protocol tcp 101 in use, 5589 most used TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saAUIO TCP outside 10.23.232.57:5223 inside 192.168.1.3:52412, idle 0:00:23, bytes 0, flag
Post a Comment
Read more

How to Set Up an IPSec Tunnel On PAN-OS - Palo Alto Firewalls

Set Up an IPSec Tunnel  The IPSec tunnel configuration allows you to authenticate and/or encrypt the data (IP packet) as it traverses across the tunnel.  If you are setting up the Palo Alto Networks firewall to work with a peer that supports policy-based VPN, you must define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access-lists (source addresses, destination addresses and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as Proxy-IDs in the first or the second message of the process. So, if you are configuring the Palo Alto Networks firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation you must define the Proxy-ID so that the setting on both peers is identical. If the Proxy-ID is not configured, because the Palo Alto Networks firewall supports route-based VPN, the default values used as Proxy-ID are source
Post a Comment
Read more