How to Create an IPSec Tunnel to AWS (Amazon Web Services) From a Palo Alto Firewall with Static Routing

How to Create an IPSec Tunnel to AWS (Amazon Web Services) From a Palo Alto Firewall with Static Routing



1. How to Import and Export Address and Address Objects (CLI) (Creating objects from a file of IPs)
2. How to Create an IPSec Tunnel to AWS (Amazon Web Services) From a Palo Alto Firewall with Static Routing
3. Revert Firewall Configuration Changes (Revert to the current running configuration)
4. Best Practices for PAN-OS Upgrade (Palo Alto Upgrade)
5. How to Unblock Addresses after Block-IP Action is Triggered by Threat Protection
6.0 What is IPSec?
6.1 Palo Alto (8.0) Site to Site VPNs
6.2 IPSec VPN Setup (Site to Site VPN Config)
6.3 IPSec Site to Site tunnel: Palo Alto to Cisco

Syslog on ASA

Syslog Packet:

The syslog packet size is limited to 1024 bytes and carries the following information:







Syslog Port numbers:

When sending messages using UDP the destination port is usually 514

When sending messages using TCP the destination port is usually 1468

Syslog Message Format:


This is the text of the syslog message, along with some additional information about the process that generated the message. The syslog messages generated by Cisco IOS devices begin with a percent sign (%) and use the following format:



Following is a description of each field:


FACILITY— Refers to the source of the message, such as a hardware device, a protocol, or a module of the system software. Note that this FACILITY is Cisco specific and is only relevant within the message string. It is different from the facility defined in RFC 3164 for the syslog protocol.

SEVERITY— This is similar to the severity defined in Table 4-2.

MNEMONIC— This is a device-specific code that uniquely identifies the message.

Message-text— This is a text string that describes the message and can contain details such as port numbers and network addresses.

Following is a sample syslog message generated by a Cisco IOS device:


*Mar  6 22:48:34.452 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,

changed state to up

Note that the message begins with a special character (*) and that the timestamp includes the time-zone information. The message was generated by the LINEPROTO facility at severity 5 (Notice). The MNEMONIC UPDOWN along with the message-text describe the event.


The facility allow administrators to logically separate messages (e.g. write them to separate files, forward them to different destinations, etc.)

Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to 191 and is made up of a Facility value and a Level value.


Syslog messages are broadly categorized on the basis of the sources that generate them. These sources can be the operating system, the process, or an application. These categories, called facility, are represented by integers, as shown in Table 4-1. The local use facilities are not reserved and are available for general use. Hence, the processes and applications that do not have pre-assigned facility values can choose any of the eight local use facilities. As such, Cisco devices use one of the local use facilities for sending syslog messages.

The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of Unix processes and Daemons.

The priority value is calculated using the following formula:

Priority = Facility * 8 + Level


Table 4-1. Facility Values

Facility 0

Kernel messages 1

User-level messages 2

Mail system 3

System daemons 4

Security/authorization messages 5

Messages generated internally by Syslogd 6

Line printer subsystem 7

Network news subsystem 8

UUCP subsystem 9

Clock daemon 10

Security/authorization messages 11

FTP daemon 12

NTP subsystem 13

Log audit 14

Log alert 15

Clock daemon 16

Local use 0 (local0) 17

Local use 1 (local1) 18

Local use 2 (local2) 19

Local use 3 (local3) 20

Local use 4 (local4) 21

Local use 5 (local5) 22

Local use 6 (local6) 23

Local use 7 (local7) 24

Severity Level:

The source or facility that generates the syslog message also specifies the severity of the message using a single-digit integer, as shown in Table 4-2.

The higher severity numbers “include” the lower severity numbers.

Table 4-2: The list of severity Levels:

0       Emergency: system is unusable

1       Alert: action must be taken immediately

2       Critical: critical conditions

3       Error: error conditions

4       Warning: warning conditions

5       Notice: normal but significant condition

6       Informational: informational messages

7       Debug: debug-level messages

Recommended practice is to use the Notice or Informational level for normal messages.


A detailed explanation of the severity Levels:

DEBUG: Info useful to developers for debugging the app, not useful during operations

INFORMATIONAL: Normal operational messages – may be harvested for reporting, measuring throughput, etc – no action required

NOTICE: Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required

WARNING: Warning messages – not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time

ERROR: Non-urgent failures – these should be relayed to developers or admins; each item must be resolved within a given time

ALERT: Should be corrected immediately – notify staff who can fix the problem – example is loss of backup ISP connection

CRITICAL: Should be corrected immediately, but indicates failure in a primary system – fix CRITICAL problems before ALERT – example is loss of primary ISP connection

EMERGENCY: A “panic” condition – notify all tech staff on call? (earthquake? tornado?) – affects multiple apps/servers/sites…

Syslog IDs:

Event(All event classes) Lists:

Event List can be used to filter syslogs IDs (syslog ID or a range) sent to a logging destination.

Logging Filters:

Logging filters are used for logging destinations e.g. Syslog Servers, Email, ASDM, Internal buffers, Console, SSH, SNMP trap and attach the Event List to is as well.

Message/Event Class:

Use the message class in order to send all messages associated with a class to the specified output location e.g. auth, config, ha, snmp, vpn, ssl etc.

Syslog servers:

Simply define the destination IPs to send the logs (usual port number udp/514).