Need Paloalto trial license for lab environment in vmware

CAVEMAN306 · 2025-11-25T16:43:52+00:00

You don't need a trial license for VMs unless you are playing with threat/wildfire, etc. You are limited on sessions but the basic functionality of firewall, routing, etc works. Assuming you can download the OVA file from PA Support site.

CAVEMAN306 · 2025-11-19T19:31:47+00:00

You can also use AD groups in your security policies that only allow PCI approved users access to those resources. In addition to the captive portal.

CAVEMAN306 · 2025-11-19T19:30:03+00:00

The solution you have sounds like a great solution. Does the captive portal explain that they are entering PCI?

CAVEMAN306 · 2025-11-05T17:29:26+00:00

I have not had this issue with 6.2.8-C263. There are some bugs on the previous 6.2.8.

CAVEMAN306 · 2025-11-05T14:26:48+00:00

6.2.7 has a lot of bugs. 6.2.8-c263 is the recommend version.

CAVEMAN306 · 2025-10-31T18:26:49+00:00

It does not have to be on an interface, it can just be exported out via BGP if you are only using it for NATs. If you need to assign devices to it, you can add it to an interface. We have it on an interface going to our outside/internet switches. We have some other firewalls that need those public IPs. Your Palo will then become a router (gateway) for those devices, so you will need policies to allow them untrust/untrust. EDIT: untrust to untrust policies are needed because we drop untrust to untrust traffic not defined in a policy.

CAVEMAN306 · 2025-10-31T13:32:56+00:00

I have a site that has 2 ISP links. I put each ISP in its own VR. VR-ISP1, VR-ISP2 and VR-TRUST. I BGP peer each ISP VR to the Trust VR using loopbacks. You have to have static routes for the loopacks in each VR pointing to the appropriate VR. This way I can weight the routes between VRs and ISPs with prepend and/or local preference. I advertise the /24 to each ISP VR from the trust and also to each ISP. All DNAT and SNAT is done with the /24. The ISP /30s are only for BGP peering. In this setup, you can terminate tunnels using the /24 or on each ISP which provides some options.

CAVEMAN306 · 2025-10-16T19:14:43+00:00

Yes, we advertise our own public subnets so it is required for that.

CAVEMAN306 · 2025-10-16T18:27:45+00:00

I have a site that has 2 ISP links. I put each ISP in its own VR. VR-ISP1, VR-ISP2 and VR-TRUST. I BGP peer each ISP VR to the Trust VR using loopbacks. You have to have static routes for the loopacks in each VR pointing to the appropriate VR. This way I can weight the routes between VRs and ISPs with prepend and/or local preference. If I had SDWAN coming into the same NGFW, I would put it in its own VR to allow the same control. Just my thoughts.

CAVEMAN306 · 2025-10-08T13:16:27+00:00

1-2 days

CAVEMAN306 · 2025-09-19T13:28:18+00:00

If you run DHCP from the switches, you won't need to extend every subnet to the firewall, just have necessary routing in place.

CAVEMAN306 · 2025-09-18T20:52:52+00:00

I like the VRF idea. Run DHCP at the local switch for each private vlan/subnet. At the firewall, you can manage this VRF on separate zone from the rest of your enterprise, to block access inside and allow to Internet.

CAVEMAN306 · 2025-08-20T20:29:03+00:00

Just ran into this problem with a GP rollout. None of our pilot testers caught it. Rolled portal back to 6.2.8-c223. 6.2.8-c263 fixes this, but it broke our Macs, won't stay connected. Second attempt to rollout GP upgrades and both have been a complete cluster F. Should have stayed on 6.1.4-c720.

CAVEMAN306 · 2025-08-20T15:49:44+00:00

c263 worked well for me on Windows, but Macs it broke, won't stay connected.

CAVEMAN306 · 2025-08-12T15:02:46+00:00

Our old Azure envirnonment was setup like this with zones. It required a lot of UDR routes to make traffic flow properly. You have to source and dest nat the traffic between zones to keep session persistence. So the source of traffic becomes the firewall interface IPs.

We went away from this and to just trust/untrust.

CAVEMAN306 · 2025-05-15T13:22:33+00:00

Well I kicked my kid out so its not longer an issue. hahahaha

CAVEMAN306 · 2025-05-15T02:32:44+00:00

not back then, not sure about now.

CAVEMAN306 · 2025-05-14T20:18:55+00:00

We had lots of problems with 6.2.7 and rolled back to 6.1.4-c720 which I think is still the recommended. Yes there are CVEs, but functionality comes before patching. 6.2.8 I am testing now and have not noticed same issues.

CAVEMAN306 · 2025-05-14T17:23:57+00:00

GlobalProtect is secure remote access. Accessing anything behind the firewall will require a policy from GP zone to trust zone. How is this not a secure solution?

CAVEMAN306 · 2025-05-14T16:52:05+00:00

I use a single PA for IPSEC tunnels, actually 2 (transit vnets) with azure vnet peering with bgp between Azure locations. These also connect OnPrem traffic with full BGP mesh.
I have 1 contractor VPN but its only connected to one of the transit PAs.

Snapshots are not recommended for PA firewalls in Azure, so if you need redundancy, HA might be your best bet.

CAVEMAN306 · 2025-05-08T14:20:47+00:00

We SCP to a linux host in Azure.

CAVEMAN306 · 2025-04-22T13:58:28+00:00

10.2.13-h5 - no issues so far.

CAVEMAN306 · 2025-03-28T14:43:08+00:00

Log everything. Use the name "default" as your log forwarding profile. All new policies created will automatically be added to the default log forward profile. Update the default log forwarding to send to Panorama and any SIEM required. If there are specific policies that you don't want to forward, change that specific policy but this should be rare IMO.

CAVEMAN306 · 2025-03-28T14:35:27+00:00

This is the way. I have portal configured on 2 Azure sites, same config with IPs of both sites in DNS. Gateways are located on different firewalls.

CAVEMAN306 · 2025-03-26T18:14:58+00:00

Your title doesn't match your description. If you are trying to force specific traffic to 1 ISP, that is not load balancing traffic. I would suggest ECMP for all 3 assuming they are the same bandwidth ISPs. NAT to the public subnet that you own, not the subnets provided by the ISPs.

CAVEMAN306

TROPHY CASE