About pulukas

I have run Active/Active with the ISP upstream links run directly to the two PA devices.  This is an option.   Obviously if there is a PA hardware failure that particular ISP is then no longer available.  But in some DC scenarios it makes more sense to lose this ISP then add the complications of the additional devices in line with the service.   ... View more

For this type of setup, I would remove the static route on the VPN tunnel.  And setup OSPF on the tunnel interfaces between the remote site and the cluster.   You can then have two VPN active at all times and use OSPF cost on the back link to make sure it is less preferred.   If you are not running OSPF currently on the HA PA, you can import these remote side routes into your BGP setup.   On the remote side set the LAN interfaces there to passive OSPF so that their subnets get advertised up both tunnel neighbors.    ... View more

You could use AD to install domain certificates on your own assets.  Then use the presence of the valid certificate as a second factor in the Global protect authorization.     https://www.paloaltonetworks.com/documentation/71/globalprotect/globalprotect-admin-guide/set-up-the-globalprotect-infrastructure/set-up-globalprotect-user-authentication/set-up-two-factor-authentication/enable-two-factor-authentication-using-certificate-and-authentication-profiles ... View more

You pretty much have to have these two interfaces in the same zone.  As you note, there is only one default route on the switch so all the traffic out will use that interface to the PA regardless of which subnet the computers are in.   You can then create two nat rules if you want the two subnets to nat to different addresses and that can easily be in the same zone.   I guess I am not understanding which configuration you are having problems making specific that cannot be done with the two subnets and interfaces in the same zone.  Can you post an example?   ... View more

Correct, the ipsec stream itself should not have these profiles applied as they will not be effective and simply use resources.   ... View more

With the virtual routers you will need a route in each of the virtual routers to the other VR subnets that need to be reached.  so the internal VR needs a default route to external vr for internet access.  And a route to the dmz vr for that subnet.   The external vr needs a route to internal subnet via internal vr and to dmz subnet for the dmz vr.   the DMZ vr needs a default route to the external vr for internet access and to the internal subnet via the internal vr.   No PBF is needed just the routes.   Now the traffic you want to allow require security policies to permit the traffic from zone to zone based on who initiates the tcp session.   Finally, you need to create NAT policies also from zone to zone based on tcp initiation for the source nat for internet access and for any inbound DMZ destination nat traffic.   Why are you puting every zone in a virtual router? None of that routing configuration is needed if all the interfaces are just in the same router to begin with.  Generally the only reason to separate virtual routers is if you have dual ISP and need to have two active default routes at the same time so we need two routing tables to accomplish this.  Your setup seems pretty standard and would be much simpler in just a single base router setup.     ... View more

The default intrazone policy is to permit so if that has not been overridden it should work.  You can confirm the deployed rule.   https://live.paloaltonetworks.com/t5/Management-Articles/What-are-Universal-Intrazone-and-Interzone-Rules/ta-p/57491   Or just create an explict one for this traffic so you can see session init logs confirming the traffic arrives on the PA.   If the logs don't help we can try packet captures to confirm what is happening. ... View more

It sounds like you need a security policy to permit the dhcp reply on the PA.  This would be from the zone of the tunnel interface to the zone where the client is connected to the network.   ... View more

Right, EIGRP is a Cisco proprietary protocol that they partially released in an RFC to pretend it is a general standard.  So you won't find it on anyone elses gear.   I've used OSPF on similar VPN mesh networks, the largest having about 90 nodes with 5 regional meshes and a central data center to all sites.  This can be very simple to configure and with careful path counting you can choose link costs that prevent major asymmetry.  And if you keep all the tunnel interfaces in the same zone on the device, even if the traffic is asymmetrical it can still match the session on arrival.   The key is to layout the map then mentally down links and count each possible alternate path for the affected traffic adding up the costs.  then make adjustments as you need to that prevent strange routing patterns.   Using eBGP on large site connections is extremely flexible.  You then have a private AS for each site as a unique source for routes.  Your policies can finely control the routing preferences per peer or even per prefix.  This is more complex to setup but can be more predictable in how the routes move around the system.  You can prevent certain paths from even becoming available via policy thus avoiding the odd long loops.   ... View more

Yes, this is a general weakness of "fast path" for existing sessions.  Since the traffic matches an existing session the route lookups and full session evaluation are not performed but in this case were needed.   The generic way to avoid this particular type of issue is to have your static routes marked as "permanent" meaning they do not withdraw even if the next hop or interface is not reachable.  Unfortunately I don't see this option in the PA interface for static routes.   Another approach is to create a discard route for this prefix at a less preferred metric than the active route.  Then when the active route is not available the traffic hits the discard instead of your default route.  And thus no other session will be setup.  This feature is availalbe on the PA.   ... View more

Configure all your snmp trap receivers under: Device > Server Profiles > SNMP Traps   Use this in your log forwarding profile Objects > Log Forwarding   Assign the log forwarding profile to all the objects you want to trap as part of your policies.     ... View more

Panorama disaster recovery is from the snapshots as outlined here.   https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Back-up-Panorama/ta-p/58973 ... View more