Nice video, but I feel you should have spent a minute or two explaining "security policy" piece in the VPN config. I feel it's one of the most important if not the most important part.
We'll certainly add this to the todo list, but please take a look at this article in the meanwhile: live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-IPSec-VPN-connectivity-issues/ta-p/59187
It was great until you got to the security policies phase where you didn't configure it live (or even scroll across the screen) so we could see how to do it.
Hi, Security policy for VPN traffic is configured as Source Zone from Trust-L3 to Untrust-L3. It should be from Untrust-L3 to Untrust-L3, right.. And configuring only VPN zones as source and destination should work right..
Hi, yes and no: the VPN tunnel itself will function from Untrust-L3 to Untriust-L3, and if you created a catch-all drop rule you will need to create this policy also (by default this traffic is allowed). The security policies demonstrated in the video are to allow traffic inside the tunnel, which will from from Trust-L3 to VPN and from VPN to Trust-L3 (so the destination untrust needs to be trust)
I have a deny all policy. What needs to be allowed for the IPSec site to site vpn? Just the IPSec Application? (ike and IPSec-esp-udp)? I believe this would also be Untrust-Untrust Zone.
An allow policy for untrust to untrust (or the zone that, based on routing, is closest to the VPN peer) with the 'ipsec' application and services set to application-default should do the trick. Make sure to have logging enabled at least during troubleshooting on the deny-all policy so in case the peer is using some sort of tunnel-monitor-outside-of-the-tunnel (ping to the peer ip,...) you can add this application/protocol to the VPN policy on a need-to basis
6:35 So..... under What Circumstance is it recommended to give/assign your *tunnel interface* an *ip address?* You didnt do it in this example; nor did you specify a *next-hop* ip-address inside your Virtual-Router (VR). (at 8:30 mark) So is this just a 'trick' that works because the IPsec Tunnel was between *two Palo Altos?* thanks
To route traffic between the sites, a tunnel interface does not require an IP address. An IP address is only required if you want to enable tunnel monitoring or if you are using a dynamic routing protocol to route traffic across the tunnel. With dynamic routing, the tunnel IP address serves as the next hop IP address for routing traffic to the VPN tunnel: docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/vpns/set-up-site-to-site-vpn/set-up-an-ipsec-tunnel.html#id8d470269-98d5-4a45-9841-f855cda24b96
