However, if we have a deny rule on top of the intrazone-default rule, or if we have overridden the intrazone-default rule action to deny instead of allow, then we need to create a couple of rules to allow the IKE negotiation traffic and the encryption domains traffic between the Palo Alto and ASA firewalls. The zones on both firewalls are already configured in my lab they are called vpn-s2s. In order to use the most secure crypto algorithms, I configured both phases with AES-256, SHA-1, and Diffie-Hellman group 5 (PFS). This means that if we are leveraging the default rule intrazone-default which by default will allow the traffic traversing within the same zone, then we don't have to add any security policy to make our VPN tunnel functional. The SSG 5 runs with firmware version 6.3.0r14.0 while the Palo Alto PA-200 has PAN-OS 5.0.8 installed. Similar for the traffic between the encryption domains, in our case both the local encryption domains interface and remote encryption domains interfaces ( tunnel.1) belong to the same security zone, trust. The IKE negotiation traffic between the Palo Alto and the ASA will be traversing within the same zone, in our case, it will be sourcing from untrust destined to untrust. The interzone-default rule instead is used for the traffic traversing between the zones, for example, between trust and untrust, and this rule is set to Deny action by default. The intrazone-default rule is used for the traffic traversing within the same zone, and it is set to Allow action by default. Palo Alto firewalls have a couple of default rules, one is the intrazone-default and another is the interzone-default. The security policies configuration for the VPN tunnel depends on our existing security policies.

Palo alto networks vpn stale phase 1