Hello all,   At present, Remote access users are getting authenticated from our AD server using LDAP. Moving forward we are planning to implement SSO/SAML for authentication.   Is there any way to import the IDP XML metadata directly into the ASA?        https://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/webvpn-configure-users.html#concept_06F1AC0D353C462F9AB48C877F94863A   I am using this link for my reference and configuration.    Any suggestions would be greatly appreciated. Please let me know if you require further information.    Thanks     ... View more

The article is intended for anyone who is familiar with TCP/IP and explains the TCP three-way handshake process.    I have captured the traffic between the client PC and a web server (example.net) using Wireshark.     To establish a connection between client and server, TCP uses a process called three-way handshake. (SYN, SYN-ACK, ACK)   First thing first, why is three-way handshake called as a three-way handshake? The reason being is that three segments are exchanged between the client and the server for TCP connection to be established.   The following sequence shows the process of a TCP connection being established.   Step 1   Packet# 1   The client wants to initiate a connection to the server (93.184.216.34). So, the client sends a packet with SYN bit set. SYN flag announces an attempt to open a connection.     If you look at the TCP header, the source port is randomly selected by Windows and the destination is well-known port 80. Length of the data is zero because this is a SYN packet and no data is transmitted in this stage. If you look at the sequence number, the value is set to zero by Wireshark (Relative sequence number).   The actual value would be a 32 bit randomly selected number which we humans will find hard to keep up with. From the screenshot you can see the actual SEQ number from the client is 1932704549 (I have also attached the picture which shows the actual 32 bits sequence number below)     Step 2   Packet# 2   In step 2, the server will respond to the client with ACK and SYN bit set. Like step 1, Length of the data is zero, no data is transmitted in this stage. The sequence number is set to 0 (relative) and acknowledges the request of the client for synchronization.  The server sends an acknowledgment of 1 to the client. The ACK is specific to the SYN the client sent. The acknowledge number is set to one more than the receive sequence number.       Step 3   Packet# 3   Finally, the client acknowledges the server’s request for synchronization with ACK 1. The ACK is specific to the SYN the server sent. The acknowledge number is set to one more than the receive sequence number.     The above process creates a reliable OSI Layer 4 connection between two hosts.    Thanks for the read ... View more

There are many articles out there about ICMP and PING. This article solely focuses on ICMP traffic passing through Adaptive Security Appliance. With the default configurations ASA will allow a host to ping the interface which is connected to. However, ping from an internal host to the internet would normally fail.   By default, traffic from the Higher Security Zone to (Inside) Lower Security Zone (Outside) is allowed without any Access Lists. Return traffic from Outside to Inside will be allowed through because the traffic was initiated from Inside.     For example, a client accessing a web page on the Internet. When a packet arrives in the Inside interface from the client, the packet is categorized into a flow based on five-tuple which contains the source IP, Source Port, Destination IP, Destination Port, and the Layer 4 protocol. ASA then maintains a state table to track these connections/flows. Based on this state table the return traffic from the web server is allowed through the firewall.   Back to ASA and Ping, ping is part of the ICMP protocol suite and handled differently compared to TCP/UDP. ASA doesn't track ICMP sessions/connections, making it stateless. Because ICMP packets do not themselves contain any connection information. Being stateless, ASA will let the ICMP echo request from Inside to Outside, but it will not allow the ICMP echo reply from Outside to Inside.   Cisco ASA can track ICMP sessions by enabling ICMP Inspection Engine. This results in an ICMP session being tracked, which in turn allows the ICMP reply packets to pass through from Outside to Inside. ICMP inspection can also dynamically allow time-exceeded and destination unreachable messages to pass through the Outside interface. (ICMP traffic has to be initiated from Inside to start with)   Below you will find the ICMP inspection configuration.     So now when the client tries and ping the web server, the ICMP echo-request packet is allowed through. ASA now starts to track this ICMP session.   Finally, when the web server sends echo-reply, ASA determines that this packet is part of an existing session and allows the packet through.   Example ICMP Inspection is disabled. Ping from VPC4 to VPC5 would fail. ASA will let the echo request passes through the ASA however, ICMP reply from VPC5 to VPC4 is denied.    VPC4> ping 10.1.2.100 10.1.2.100 icmp_seq=1 timeout 10.1.2.100 icmp_seq=2 timeout 10.1.2.100 icmp_seq=3 timeout 10.1.2.100 icmp_seq=4 timeout 10.1.2.100 icmp_seq=5 timeout   ASA logs   %ASA-6-302020: Built outbound ICMP connection for faddr 10.1.2.100/0 gaddr 10.1.1.100/18710 laddr 10.1.1.100/18710 %ASA-3-106014: Deny inbound icmp src outside:10.1.2.100 dst inside:10.1.1.100 (type 0, code 0)   Enable ICMP Inspection   TEST-ASA(config)# policy-map global_policy TEST-ASA(config-pmap)# class inspection_default TEST-ASA(config-pmap-c)# inspect icmp TEST-ASA(config-pmap-c)# exit TEST-ASA(config-pmap)# exit     VPCS> ping 10.1.2.100 84 bytes from 10.1.2.100 icmp_seq=1 ttl=64 time=1.441 ms 84 bytes from 10.1.2.100 icmp_seq=2 ttl=64 time=1.482 ms 84 bytes from 10.1.2.100 icmp_seq=3 ttl=64 time=1.438 ms   ASA now tracks the ICMP connection, therefore, the return ICMP reply is allowed through.     Thanks for the Read   ... View more