Policy Based Forwarding

by on ‎07-05-2012 05:18 PM (74,778 Views)

Policy Based Forwarding (PBF) use cases.

owner:wwarburton

Comments
by cryptochrome
on ‎05-24-2013 02:26 AM

Is there an updated version available for PanOS 5.0? I am especially looking for an in-depth explanation of the "enforce symmetric return" option (the admin guide is pretty weak on that).

by
on ‎05-24-2013 07:18 AM

We do not yet have an update for 5.0 or a timeline but we will add it to our list.

Regards,

Warby

by Sly_Cooper
on ‎06-13-2013 05:53 AM

If the traffic is routed from first packet/response, then does application based rules work? For e.g. if we redirect all tcp/80 to proxy, then all my rules on the firewall for http app like youtube, facebook etc. will be processed?

by
on ‎06-13-2013 09:14 AM

PBF does not bypass the security policy.  If you have a policy based forwarding rule to redirect TCP port 80, and you also have a security rule that for example allows youtube but not facebook, then both would apply so in this example, youtube would be allowed and forwarded per the PBF rule and facebook would be dropped.

by Sly_Cooper
on ‎06-21-2013 11:52 PM

Here is my scenario - currently I have PA sitting before ASA and proxy (vwire). ASA is configured with wccp for port 80 and 443 redirection. I want to get rid of ASA and have http & https redirection configured on PA using PBF. The doc says that it redirects the first packet and if you do service based redirection. I was wondering how the policy would be applicable.

by pk
on ‎06-24-2013 09:49 AM

You can setup the PBF rule to redirect the http (80) and https (443) services out to the destination (egress) interface and/or IP address.  The source can be ANY and the destination can be ANY.  What the document is trying to say is that PBF will analyze the tuple information of the first packet to try and determine the path.  Typically if you setup the PBF rule with a specific destination port number, it can redirect the traffic and flow on the first packet.

Where it get's more complicated is if the PBF policy is only setup using an application name.  In this case, if it's a TCP based session, the firewall would need to see the full 3-Way handshake and then one or more packets to determine the application accurately.  In these cases, the first session may flow through the firewall using the onboard route table and then subsequent sessions for the same tuple gets forwarded using the PBF policy. 

In these cases, we suggest setting up the URL filtering on the firewall to mirror the external security device.  That way, if the first session has to go through for the application to be recognized, it isn't going through unscanned.  But from what you're describing, if you setup a PBF policy with just the service ports for http and https, it should redirect based on the destination port - 80 and 443.

Hope this helps.

by Sly_Cooper
on ‎06-26-2013 04:17 AM

@pk - Thanks for the explanation. I plan on replacing wccp and get the proxy redirection configured on PA firewall. I currently do not have URL filtering license available for PA firewalls. Even if we do, I am a bit hesitant in using two different solutions (our existing web filtering and PA). Also you had mentioned about having PBF on external interface. Is it possible? I have only trust and untrust zone. So can I have PBF on untrust zone interface? That way all traffic will anyways will be filtered by PA first??? Not sure if I am interpreting it correctly.

by pk
on ‎06-26-2013 07:45 AM

Typically, you would redirect the traffic out of the Palo Alto firewall through another interface (a third one, not the ingress) that would go to the scanning device you're redirecting to. That interface can be in the Untrust Zone or another zone you create.  When the traffic is scanned, you can redirect it back to that zone and then let it route through the firewall into the Trust zone so it can be scanned.

The PBF policy can use the zone or the interface as the source.  If you're returning the scanned traffic to the same zone, you should use the inbound interface as the source for the PBF policy.

by Sly_Cooper
on ‎06-26-2013 08:12 AM

I did not follow you. In my current setup I have PA deployed inline for ASA and proxy connections. Here is my current setup. The proxy is deployed single legged and share the same VLAN as ASA trust interface. The plan is to remove ASA and make PA as L3 with PBF. Are suggesting creating separate zone for proxy? Like trust (internal connections), untrust (connected towards internet router side) and proxy (for proxy)? Traffic hits inside zone/interface -> PBF -> proxy -> untrust -> internet?

Diagram.jpg

by pk
on ‎06-26-2013 08:33 AM

Thanks for the visual.  You would set the PBF policy on the ingress interface coming from the internal switch.  Match on the service you're interested in redirecting to your security box (for example, your web-browsing applications with HTTP and HTTPs).  Forward that to the interface going to your Web Security Proxy.

When the return traffic comes back in, the security rules would then kick in between zones to apply the security policy.  It would make sense to create a separate zone in this case.  By default, the firewall will allow inter-zone communications, so if you had the proxy interface in with either of the other two zones, traffic will be allowed to pass between the interfaces.  A third zone will allow you to separate the traffic and apply FW rules in a more granular fashion.

If you need help, you can call our support line.

Cheers

by Sly_Cooper
on ‎06-26-2013 09:35 AM

So if i have a third zone, traffic from trust -> proxy zone (PBF) will be scanned too? and then again it will be scanned from proxy -> untrust?

Yes I am planning to open up a case with support.

by jcrider
on ‎07-19-2013 02:51 PM

Did you ever get this working the way you want?

I too have a requirement that matches your task and am looking to see if you used the new zone for your proxy/filter?

by Sly_Cooper
on ‎07-19-2013 10:26 PM

- No  I have not tried it yet. It is still on my radar.

by msullivan
on ‎08-29-2013 11:22 AM

Sly,

I think you'll need to take into account that PBF is not a drop in replacement for WCCP.  This diagram (stolen from Here) nicely illustrates the traffic flow for WCCP.  WCCP is nice because it is transparent to the client and scales nicely.  GRE allows the proxy to live where it makes sense and  the client 'thinks' the reply came from the Internet.  I'd like to see PA adopt WCCP, it's nice to have a web proxy that isn't inline with the clients.

Figure 4: WCCP traffic flows

by Sly_Cooper
on ‎09-26-2013 02:13 AM

msullivan - We are getting rid of our existing proxy and moving to PA firewalls so no more worrying about wccp redirection:smileyhappy:. Thanks for the wccp explanation.

by dmcgee_Arke
on ‎12-03-2013 01:17 PM

I am trying to determine if through use of PBF, NAT or some combination of the two, i can replace our aging TMG reverse Proxy with the PA exclusively. Sly_Cooper What do you think?

We have several internal Web servers, but only one external IP address.

I tried NAT'ing traffic based on FQDN, but only the first policy in the list would work (did not seem to respect the FQDN, and instead did NAT based on IP)

I'e tried doing the same with PBF, but couldnt seem to see how i would configure it properly.

So, currently we have PA routing all traffic to our External IP to our TMG which then parses the web address and forwards it on to the proper internal web server.

I would like the PA to be able to do this parsing and eliminate the TMG completely if possible.

PA allows rules based on FQDN, but then doesn't seem to respect the FQDN in those rules, and so this has caused a bit of frustration to me not being able to understand this limitation.

by pk
on ‎12-03-2013 02:57 PM

dmcgee.

Are the FQDNs resolving to different addresses?  If you only have one external address and the DNS server the firewall is using is resolving them to the same IP address, then you'll run into a condition where the PBF rules would "shadow" each other - as the match criteria would be the same.

On the Destination NAT issue, you would have to use an IP address with Port Translation to make this work.  But that probably won't suit your need as you're using the same port for HTTP most likely.

by dmcgee_Arke
on ‎12-04-2013 05:26 AM

Yes, We have 50+ websites on around 10 internal web servers. what we are trying to accomplish is having one external IP, have PA look at the FQDN of the request to that IP, and route it to the proper internal server based on that FQDN. The issue comes that the first server in the list takes all the traffic, regardless of FQDN. Example:


website1.company.com and website2.company.com are on webserver1 at internal ip 192.168.1.24

website3.company.com and website4.company.com are on webserver2 at internal ip 192.168.1.25

we have 4 NAT  rules translating destination address (FQDN) to internal destination.

Whichever server is first takes all the traffic, and in this case, website1 and website2 would work, and website3 and website4 would return IIS or error pages.

I understand that they all resolve to the same external IP address, and that the PA is seeing that address and routing to the first rule in the list that matches, but what I don't understand is why the NAT rules allow you to use FQDN as a condition, and then seemingly  completely ignores that FQDN. That is one question I have yet to have answered. If it doesn't respect the FQDN, what is the point in even allowing the rules to be created with FQDN as a condition?

by pk
on ‎12-04-2013 07:42 AM

The firewall will resolve the FQDN to an IP address (in this case, your external address) and then cache that value for a specific amount of time. From the sounds of it, if the FQDNs are resolving to the same external IP address, there isn't a way to differentiate.  The FQDNs should be resolving to different IP addresses for this to work.

Do you see any warning messages regarding your PBF policies being "shadowed" when you commit the changes? 

by msullivan
on ‎12-20-2013 10:58 AM

@dmcgee_Arke

, I think you need a load balancer, have you looked at F5 LTM?  It's a great solution if you can swing it.

Mike

by ttanzi
on ‎05-19-2014 12:03 PM

Hi All,

I have another question regarding PBF.  I am working with a customer that has a HQ location in NJ and a remote office in Mexico. We have the VPN up and running.  We have routes in the Mexico firewall to route traffic to a specific subnet over the VPN tunnel.  This customer would also like to be able to ping the untrusted interface of this firewall from the same subnet that the VPN traffic is returning on. We have the policy to allow this from specific subnets and the same for the interface management profile. What I believe is happening is that when they try and ping the untrusted interface in Mexico from a subnet that is part of the VPN in NJ, I see the traffic coming in outside-outside, I believe the return traffic is being sent over the VPN tunnel instead of back out the outside interface because we have a static route for this subnet to go over the VPN tunnel and this needs to stay as they also have servers on that subnet. So in essence they want to be able to manage the remote firewall via its untrusted interface coming from a subnet whos return is routed over a VPN tunnel. 

I was looking at possible using PBF to try and return this traffic out the outside interface but since I cannot select ping as an application and the fact that this is a response and not being sources by the outside interface, it won't work.

Am i correct in my thinking?

thanks in advance

by George_Squire
on ‎10-17-2015 08:26 AM

I know this threat is quite old however I would like to add to the discussion.

You can use FQDN objects in sNAT but not in dNAT.

There is a feature request raised for this to be added in a future relase if it gets enough votes.

Took a while to find this out but had it confirmed by a PAN engineer. 

 

Hope this helps someone.

by max.strzelecki
‎01-20-2017 08:49 AM - edited ‎01-20-2017 08:51 AM

I'm getting the "shadow" message when committing. I have dual internet connections to 2 ports on the PA. The idea is the PBF rule forwards all outbound traffic, using ping to disable itself if the connection goes down, so the next rule can get processed (the secondary internet connection).

 

No idea why it's saying it's shadowed, since each internet link has a different interface and next-hop IP. 

Ask Questions Get Answers Join the Live Community
Contributors