- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-19-2017 11:59 PM
For the first time I configured a Palo Alto firewall.
I have created three zones each connected with a specific interface:
INTERN
EXTERN
DMZ
For each zone I created a virtuel router each configured with static routes :
Intern:
DMZ -> Interface DMZ
Dmz:
EXTERN -> Interface EXTERN
INTERN -> Interface INTERN
Extern
0.0.0.0 0.0.0.0 -> IP ISP Router
DMZ -> Interface DMZ
I connected PC's on each interface with the correct IP settings. Each PC can ping its own default gateway on the firewall but they can't ping each other. In the policy settings I created a rule that everuthing is allowed between the zones.
What can be the problem?
11-20-2017 08:41 AM
there are a few scenarios: you can use multiple VR if you need to segregate interfaces from eachother: they will not be able to reach eachother unless you add a route to specifically allow it (all interfaces on the same vr can automatically 'route' to eachother)
PBF can be used to make a preferred route on top of normal routing eg. if you have 2 ISP, one leased line and one DSL, you could create a PBF to route non-important web-browsing over the DSL line. If the ISP were to fail, routing would fall back to your static routes and web-browsing would go over the leased line
PBF and multiple VR's don't necessarily need to go hand in hand, the dual ISP solution does not require 2 VRs, but this scenario does:
if you need to set up redundant VPN tunnels, you will need to have 2 static route (eg default gateways) working at the same time so the tunnels can remain 'up'. PBF can then be used to direct traffic to one VR or the other depending on your preferred conditions
hope this makes sense (did you check out the PBF article i provided above ?
11-20-2017 01:29 AM
The routing seems to work better after creating some policies.
But the clients still doesn't respond. In the traffic monitor I always get Session End Reason: aged out.
11-20-2017 02:07 AM
I need to create a PBF rule that does not PBR the traffic between INTERN and DMZ but I don't understand why.
11-20-2017 03:44 AM
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.
11-20-2017 05:23 AM
I agree with @pulukas: your configuration would be much simpler if you set all interfaces in the same virtual router, then you'd only need security policies and NAT to make everyhting work
please take a look at this article which may help you on your way: Getting Started: Layer 3, NAT, and DHCP
and this one on PBF: Getting Started: Policy Based Forwarding
11-20-2017 05:23 AM
I'm just going to second what @pulukas has already stated. From what you've described, there isn't really any reason to have multiple VRs. TO keep your configuration looking a bit more standard I would simply combine all of the zones into one virtual router, if you continue to keep everything the way you are doing you'll run into configuration issues. To add to that a little bit, almost every guide that you read going forward is centered around one Virtual Router configuration, not multiple. Guides may not work for you as you intend, support may not be as able to help you do to your configuration, and most of the Live community is going to just assume you have one VR.
11-20-2017 07:01 AM
After some searching I got everything to work with my configuration.
But when and why you would use multiple virtual routers and PBR?
As mentioned here it is only necessary if you use multiple ISP.
11-20-2017 08:41 AM
there are a few scenarios: you can use multiple VR if you need to segregate interfaces from eachother: they will not be able to reach eachother unless you add a route to specifically allow it (all interfaces on the same vr can automatically 'route' to eachother)
PBF can be used to make a preferred route on top of normal routing eg. if you have 2 ISP, one leased line and one DSL, you could create a PBF to route non-important web-browsing over the DSL line. If the ISP were to fail, routing would fall back to your static routes and web-browsing would go over the leased line
PBF and multiple VR's don't necessarily need to go hand in hand, the dual ISP solution does not require 2 VRs, but this scenario does:
if you need to set up redundant VPN tunnels, you will need to have 2 static route (eg default gateways) working at the same time so the tunnels can remain 'up'. PBF can then be used to direct traffic to one VR or the other depending on your preferred conditions
hope this makes sense (did you check out the PBF article i provided above ?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!