Showing posts with label PaloAlto. Show all posts
Showing posts with label PaloAlto. Show all posts

PaloAlto-Traffic Error Logs:-

=====================
aged-out
=====================

1)Generally Session aging is an operation to identify expired sessions and remove them from ager and flow lookup table and return to free session pool. It can be triggered by timer event or packet arrival event. A session is considered expired if
• Session state is CLOSING, in this state session is subject to immediate expiration.


At various phases during packet processing, a session may close due to causes such as:
Session denied or time out
Dropped packets due to threat various treat conditions
Reset by any of end hosts

2)The purpose of introducing the session tracker feature is to provide precise reasons for mitigation actions taken on particular sessions.

3)There are multiple tracker stage statuses, such as:

======================
SESSION END REASON
=======================

Aged out - Occurs when a session closes due to aging out
TCP FIN - Occurs when a TCP FIN is used to close half or both sides of a connection
TCP RST - client - Occurs when the client sends a TCP reset to the server
TCP RST - server - Occurs when the server sends a TCP reset to the client
appid policy lookup deny - Occurs when a session matches a security policy with a deny or drop action
mitigation tdb - Occurs when a session ends due to a threat detection
resource limit - Occurs when a session is set to drop due to a system resource limitation such as exceeding the number of out of order packets allowed per flow or the global out of order packet queue. Many other reasons will roll up to this reason.
host service - Traffic destined for firewall but service not allowed or enabled

4)TCP Session Timeout:
Maximum length of time that a TCP session remains open without a response, after a TCP session is in the Established state (after the handshake is complete and/or data transmission has started). Default is 3600 seconds; range is 1-1599999 seconds.

You can change the timeout value from Device > Setup > Session > Session Timeouts > TCP

5) Here TCP 3 way handshake was breaking down due to an invalid response from the server. The order of the handshake should be syn > syn-ack > ack but instead we saw syn > ack > rst.
We can try clearing the sessions to the server and see if this helps though if we receive the same thing it is likely an issue with the server and or the application. Since we will need to reset the sessions after you are out of normal production hours we will wait for your followup.

======================
APPLICATION REASON
======================
Incomplete means that either the three-way TCP handshake did not complete or the three-way TCP handshake did complete but there was no data after the handshake to identify the application. In other words that traffic being seen is not really an application. For example, if a client sends a server a syn and the Palo Alto Networks device creates a session for that syn, but the server never sends a SYN ACK back to the client, then that session is incomplete.


Insufficient data means not enough data to identify the application. So for example, if the three-way TCP handshake completed and there was one data packet after the handshake but that one data packet was not enough to match any of our signatures, then user will see insufficient data in the application field of the traffic log.


Unknown-tcp means the firewall captured the three-way TCP handshake, but the application was not identified. This may be due to the use of a custom application for which the firewall does not have signatures.


Unknown-udp consists of unknown udp traffic.
unknown-p2p
Unknown-p2p matches generic P2P heuristics.


Not-applicable means that the Palo Alto device has received data that will be discarded because the port or service that the traffic is coming in on is not allowed, or there is no rule or policy allowing that port or service.
For example, if there was only one rule on the Palo Alto device and that rule allowed the application of web-browsing only on port/service 80, and traffic (web-browsing or any other application) is sent to the Palo Alto device on any other port/service besides 80, then the traffic is discarded or dropped and you'll see sessions with "not-applicable" in the application field.



Action - Action indicates an allowed traffic.  Deny would indicate a block. 
if the final action is Allowed then please check below Session_end_Reason to confirm if the traffic is completely allowed or blocked.

Action
Final Action
reason
allow
Allowed
session was allowed by policy
deny
Blocked
session was denied by policy
drop
Blocked
session was dropped silently
drop ICMP
Blocked
session was silently dropped with an ICMP unreachable message to the host or application
reset-both
Blocked
session was terminated and a TCP reset is sent to both the sides of the connection
reset-client
Allowed
session was terminated and a TCP reset is sent to the client
reset-server
Allowed
session was terminated and a TCP reset is sent to the server




App- Firewall can identify applications based on various aspects of the traffic. 
You can find complete list of applications from HERE
If the application is not identified, then it can be because of following reasons

App
Final Action
reason
Incomplete
Allowed
The three-way TCP handshake did not complete Properly.
Insufficient data
Allowed
The three-way TCP handshake did complete but there was no data after the handshake to identify the application.
Unknown-tcp
Allowed
The three-way TCP handshake completed, but the application was not identified. This may be due to the use of a custom application or port numbers
Unknown-udp
Allowed
The UDP application was not identified. This may be due to the use of a custom application or port numbers
Not-applicable
Blocked
Blocked by Firewall, as there is no rule or policy allowing that port or service.


Session_end_Reason- This indicates why a session ended.  The reasons are below:
Session End Reason  
Final Action
Description  
threat
Blocked
The firewall detected a threat associated with a reset, drop, or block (IP address) action.
policy-deny
Blocked
The session matched a security rule with a deny or drop action.
tcp-rst-from-client
Allowed
The client sent a TCP reset to the server.
tcp-rst-from-server
Allowed
The server sent a TCP reset to the client.
tcp-fin
Allowed
One host or both hosts in the connection sent a TCP FIN message to close the session.
tcp-reuse
Allowed
A session is reused, and the firewall closes the previous session.
aged-out
Allowed
The session aged out.
resources-unavailable
Blocked
The session dropped because of a system resource limitation. For example, the session could have exceeded the number of out-of-order packets allowed per flow or the global out-of-order packet queue.
decrypt-error
Blocked
This occurs if we configure SSL Decryption and the Firewall blocks if it detects certificate expiry, unsupported cipher suites.
decrypt-cert-validation
Blocked
This occurs if we configure SSL Decryption, Firewall blocks if the server certificate produces a fatal error alert of type bad_certificate, unsupported_certificate, certificate_revoked, access_denied, or no_certificate_RESERVED
decrypt-unsupport-param
Blocked
This occurs if we configure SSL Decryption, , Firewall blocks if the session produces a fatal error alert of type unsupported_extension, unexpected_message, or handshake_failure.
decoder
Allowed

The decoder detects a new connection within the protocol (such as HTTP-Proxy) and ends the previous connection.
n/a
Allowed
This value applies when the traffic log type is not end

PaloAlto-HA-Theory

ACTIVE(FW1)------------------HA_LINK------------------------------------PASSIVE(FW2)
E1/1(10.10.10.100)---------------------------------------------------E1/1(10.10.10.100)
interfaces=GREEN--------------------------------------------------interfaces=RED


1)
interface-DOWN--ACTIVE(FW1)-----------------------------YOU BE ACTIVE------->PASSIVE(FW2)

PASSIVE(FW1)-------------------------------------------------------------------------->ACTIVE(FW2)
                                               SWITCH<----------MAC------------------------------GARP
PASSIVE(FW1)--------------------------------------------------------------------------->ACTIVE(FW2)


HA1 (control link), HA1 backup, Heartbeat backup
     Config synchronization
     Management plane runtime state synchronization
     FIB, user-group mappings, DHCP leases, DNS cache, etc.
     HA state communication
HA2 (data link) & HA2 backup
used to synchronize state, sessions, routing tables, IPSec security
associations, and ARP tables between devices in a HA cluster
     Session synchronization
     A/P – We do not sync ICMP sessions.
     A/A – We do not sync Multicast sessions.
     Data plane runtime state synchronization
     ARP table, Neighbor table, user-IP mappings, etc.
     You cannot ping the HA2 interface

HA3
     Packet forwarding link (Active/Active only)
     This link is used as packet forwarding link for session setup and asymmetric traffic handling.
------------------------------------------------------------------------------------------------------------------------------
NAT device binding options include the following:

     * Device 0 and Device 1—Translation is performed according to device-specific bindings only if the session owner and the device ID in the NAT rule match. evice-specific NAT rules are commonly used when the two firewalls use unique public IP addresses for translation
     * Both—This option allows either device to match new sessions to the NAT rule and is commonly used for destination NAT
     * Primary—This option allows only the active-primary device to match new sessions to the NAT rule. This setting is used mainly for inbound static NAT, where only one firewall should respond to ARP requests. Unlike device 0/1 bindings, a primary device binding can move between devices when the primary role is transferred

Session OWNER:
==========
------(PA1-act-prim)-------
------(PA2-act-sec)-------
First packet
First come first server :)
when packet rx to PA1 or PA2 then that Firewall will become session owner
Primary device
Only Active-Primary device will be the SESSION OWNER
++If PA2 rx any first packet then it sends to PA1  to OWN the SESSION

session SETUP:
=========
------(PA1-act-prim)-------
------(PA2-act-sec)-------

•IP modulo
Load sharing
For one packet PA1 will be-------SESSION SETUP
For Another packet PA2 will be---SESSION SETUP

Load sharing is done in round robin...based on source IP

•IP Hash
Load sharing
For one packet PA1 will be-------SESSION SETUP
For Another packet PA2 will be---SESSION SETUP

Hash of either source or combination source/destination IP address is used for Loadsharing

•Primary device
Only Active-Primary device will be the SESSION SETUP
++If PA2 rx any first packet then it sends to PA1  to SETUP the SESSION

COMPLETE ACTIVE/ACTIVE

     

Paloalto- HA(Active-Active)



HA1 (control link), HA1 backup, Heartbeat backup
     Config synchronization
     Management plane runtime state synchronization
     FIB, user-group mappings, DHCP leases, DNS cache, etc.
     HA state communication
HA2 (data link) & HA2 backup
used to synchronize state, sessions, routing tables, IPSec security
associations, and ARP tables between devices in a HA cluster
     Session synchronization
     A/P – We do not sync ICMP sessions.
     A/A – We do not sync Multicast sessions.
     Data plane runtime state synchronization
     ARP table, Neighbor table, user-IP mappings, etc.
     You cannot ping the HA2 interface

HA3
     Packet forwarding link (Active/Active only)
     This link is used as packet forwarding link for session setup and asymmetric traffic handling.
------------------------------------------------------------------------------------------------------------------------------
NAT device binding options include the following:-

 * Device 0 and Device 1—Translation is performed according to device-specific bindings only if the session owner and the device ID in the NAT rule match. evice-specific NAT rules are commonly used when the two firewalls use unique public IP addresses for translation
   * Both—This option allows either device to match new sessions to the NAT rule and is commonly used for destination NAT
   * Primary—This option allows only the active-primary device to match new sessions to the NAT rule. This setting is used mainly for inbound static NAT, where only one firewall should respond to ARP requests. Unlike device 0/1 bindings, a primary device binding can move between devices when the primary role is transferred

Session OWNER:
==========
------(PA1-act-prim)-------
------(PA2-act-sec)-------
First packet
First come first server :)
when packet rx to PA1 or PA2 then that Firewall will become session owner
Primary device
Only Active-Primary device will be the SESSION OWNER
++If PA2 rx any first packet then it sends to PA1  to OWN the SESSION

session SETUP:
=========
------(PA1-act-prim)-------
------(PA2-act-sec)-------

•IP modulo
Load sharing
For one packet PA1 will be-------SESSION SETUP
For Another packet PA2 will be---SESSION SETUP

Load sharing is done in round robin...based on source IP

•IP Hash
Load sharing
For one packet PA1 will be-------SESSION SETUP
For Another packet PA2 will be---SESSION SETUP

Hash of either source or combination source/destination IP address is used for Loadsharing

•Primary device
Only Active-Primary device will be the SESSION SETUP
++If PA2 rx any first packet then it sends to PA1  to SETUP the SESSION

====================================================================
ARP load sharing:-
SAME like HSRP - has one virtual ip
FLOATING IP:-
SAME like HSRP :- has TWO virtual IP

Floating ip + ARP loading sharing
--->ARP load sharing 
This can only be done where the hosts are on the same L2 network as the firewall (which means you'd only do it on your LAN side). 
--->Setting the session owner and the setup device to be the primary device is not recommended
--->recommended setting is to use “First Packet” for session owner and “IP modulo” for session setup.

Setting for First Packet and IP Modulo will ensure that both Active and Secondary device will both participate as a session owner and in session setup about equally. 
-->If we disable Packet Forwarding, session setup and session owner will be same, it will work for asymetric traffic also.
#set deviceconfig setting session tcp-reject-non-syn no 
#set deviceconfig setting tcp asymmetric-path bypass
#commit

The first command should be used in a scenario where firewall has never seen a SYN packet but see a SYN ACK passing through the firewall.

The second command is used in scenario where SYN packet goes through the Palo Alto Networks firewall, but SYN-ACK never goes through the firewall and the firewall receives an ACK.








USING FLOATING IP:
================












Configuration:
==========
>show high-availability virtual-address

+Router should learn arp for 172.17.1.2--172.17.1.3-172.17.1.4--172.17.1.5==>1.4 and 1.5 are virtual mac's








Please use translated address instead of interface address when you configure source NAT for floating ip in A/A environement. 





Powered by Blogger