Policy based forwarding for traffic filtering

[nwallette]

I'm trying to set up a PBF rule to take all my inside traffic, filter it through a security appliance, and then continue out to the Internet.

Without the rule applied, traffic works fine.  I can hit the Internet and all is well.  With the rule enabled, all packets are sent to the security appliance, which then sends it back to the PAN, which then sends it back to the security appliance, and so on until the TTL expires.  A packet capture from the security appliance shows packets originating from the client PC's IP and going to the real destination IP, as expected.

Here's the relevent portion of my device setup:

eth1/1 - [Outside Internet connection]  (Zone: Outside)

eth1/2 - [DMZ]  (Zone: DMZ)

eth1/3 - 10.2.42.1/24  (Zone:  Inside)

eth1/7 - 10.2.43.1/24  (Zone:  Inside)

All my inside clients are on a switch off of eth1/3 in the 10.2.42.0/24 network.

The security appliance is at 10.2.43.20/24, hanging off of eth1/7.

The PBF rule takes any traffic from interface 1/3 and forwards it to 10.2.43.20 through interface 1/7.

The security appliance's default gateway is 10.2.43.1.

Traffic is looping from 10.2.43.1 -> 10.2.43.20 -> 10.2.43.1 -> 10.2.43.20 -> 10.2.43.1....

The only static route is for 0.0.0.0/0 to the outside router.

So, why is the PAN forwarding packets back to the security appliance?

[kbrazil]

Hi there,

Can we get a screen capture of your PBF policy?  If the policy is correct, it might be a bug and I imagine you could work around it by putting e1/7 into a new zone and using the source zone in the policy instead of source interface.  Alternatively you could exempt PBF forwarding for traffic sourced from 10.2.43.20 with another PBF rule above the existing rule.

Cheers,

Kelly

[nwallette]

Sent an email -- but for completeness, here's the rule:

Source Zone / I.f.:  ethernet 1/3

Source Address:  any

Source User:  any

Destination Address:  any

Application:  any

Service:  any

Action:  Forward

Forwarding Egress I/F:  ethernet 1/7

Forwarding Next Hop:  10.2.43.20

Monitoring Profile:  Failover until Restored

Monitoring Target:  10.2.43.20

Disable if Unreachable:  Yes

Schedule:  None

FYI, this is PanOS release 3.1.8 on a single (non-HA) PAN 500.

Edit:  P.S., out of curiosity, why is there no "Destination Zone / I.F." field?  Ideally, we would only filter traffic from inside clients going to the Internet.  Or at some of our sites, we would use the external appliance to do deduplication for traffic traversing site-to-site VPNs (Inside to Tunnel.)  But in this setup, we're forced to filter traffic going to/from the Inside interface to anywhere, even if it's just another subnet.

[kbrazil · Accepted solution]

The policy looks good.  I think this may be working as designed - when the first packet hits the device a flow is created.  I think packets returning from the security device are matched against the original flow since the source and destination zones match.

I imagine if you do a "show session id <xxx>" for the session you will see the PBF enabled which probably applies no matter what interface the packet ingresses after the first match.  Another way to look at it is the packet is seen as the same packet that matched the PBF policy the first time the firewall saw it, so it keeps applying the PBF policy to it, even though the packet is now ingressing on another interface.

I think one way to get out of this may be to change the zone names for both internal interfaces and re-do some of your PBF and Security policy.

I think the alternative option I provided in my post above may not work since the rule will never match (since the packet is already applied to an existing flow).

Hope that helps.

Cheers,

Kelly

[kbrazil]

I believe you cannot do PBF by destination interface or zone because the device only knows the egress interface after consulting the routing table, but PBF is performed before routing.  You can configure PBF by destination address, however.

Cheers,

Kelly

[nwallette]

So basically, this can't be used as an in-line filter, because the packet (approved by our appliance) is going to match the PBF rule for the life of its session?  I assume the intended use is to dispatch packets to alternate gateways depending on some characteristic, not as a "catch all" with selective processing like we're trying to do..

That's unfortunate for my case, but I see the thought process behind it.

Also, thanks for the reply on the destination routing.  That makes sense.  Again, I think we're applying this feature in a way that was never intended.

[kbrazil]

I think using different zones for interfaces 1/3 and 1/7 might make this work.  This way the firewall will see the packet coming from a different zone and will not match the original PBF flow.

Just be careful about the return traffic, though.  You may need some creative security policies to make this work.

You might even consider having the external device not send the traffic back through the firewall, if possible.

Cheers,

Kelly

[blacksan]

Need to create a rule above the PBF for the Security Appliance to avoid the loop.

Source Zone / I.f.:  ethernet 1/3

Source Address:  10.2.43.20

Source User:  any

Destination Address:  any

Application:  any

Service:  any

Action:  no-PBF

[nwallette]

Well, just for completeness, I tried setting up the security appliance on its own zone.  That did not help.  I also put the explicit "no-pbf" rule above the PBF rule.  It no longer gets stuck in a routing loop, but instead I get this:

10.2.42.100 (my laptop IP)

no reply (eth 1/3, my gateway)

10.2.43.1  (eth 1/7 gateway)

10.2.43.20  (security appliance)

10.2.43.1  (eth 1/7 again)

no reply

no reply

no reply

.

.

.

So it looks like it's just getting dropped at the PAN interface despite the fact that traffic originating on the 10.2.43.0 subnet can hit the Internet.

It looks like we'll just have to apply our filtering policies either by hanging the S.A. off our Juniper Layer 3 switches instead, or between the Juniper and PAN.

Thanks for the (FAST) suggestions, everyone.