Internal to Internal traffic and application\url blade

[DannyW]

Hi everybody. We've recently made what seemed to be an innocuous change to the environment, but now finding the unintended consequences.

5 locations - each running R77.30. Connected via an any-to-any MPLS network. Each location has direct internet access via the vendor provided MPLS circuit. Our MPLS vendor made a change to the way they're delivering the circuit, here's what changed:

Previously:
The vendor provided the circuit with two tagged vlans - one vlan for our internal "private" locations, and one vlan for our 0.0.0.0 route (internet). On our gateway, i had two vlan interfaces - for the internet vlan, spoof was set to external; for the private vlan, spoof was set to all internal address that could be found via that interface (all non-locally connected networks in our environment)

The change.....
No more vlans, one route: 0.0.0.0 to their hand-off gateway, which will route privately internally, or externally based on destination. I set that interface to external which i believe is the salient factor here. Now all traffic from a locally connected network to another private site hits the app\url blade after passing the fw policy - that never happened via the previous MPLS setup with two vlans. So...I guess i have two questions:

1) Is the spoof setting on the interface the arbiter on why this behavior is now occurring?

2) Is there a way to not make internal site <-> internal site hit the app\url\https blade(s)?

Kind regards.

Danny

[ShadowPeak.com]

So...I guess i have two questions:

1) Is the spoof setting on the interface the arbiter on why this behavior is now occurring?

Yes. If using object "Internet" as the destination in an APCL/URLF layer, it will match all traffic leaving on an interface that is not explicitly marked as Internal in the antispoofing settings. Notice I did not say "will match all traffic leaving on an interface marked as External". Big difference as that will cause missing interfaces in the firewall topology to be treated as External for purposes of matching the object "Internet".

If you are using object "Any" in the destination of any APCL/URLF rule you need to change that to avoid LAN-speed traffic from getting sucked in the Medium Path (PXL) for APCL/URLF inspection.

2) Is there a way to not make internal site <-> internal site hit the app\url\https blade(s)?

Yes, the traffic between the two internal networks needs to "fall off" the end of the APCL/URLF policy and not match any rule at all; this signals to SecureXL that the Medium Path will not be necessary and it can attempt to handle the traffic in the Accelerated Path (SXL). That includes making sure the internal traffic doesn't match the "Any Any Any_Recognized Accept" default rule at the bottom. You cannot define an explicit APCL/URLF rule matching that internal traffic and essentially say "don't do APCL/URLF".

[DannyW]

Yes. If using object "Internet" as the destination in an APCL/URLF layer, it will match all traffic leaving on an interface that is not explicitly marked as Internal in the antispoofing settings. Notice I did not say "will match all traffic leaving on an interface marked as External". Big difference as that will cause missing interfaces in the firewall topology to be treated as External for purposes of matching the object "Internet".

If you are using object "Any" in the destination of any APCL/URLF rule you need to change that to avoid LAN-speed traffic from getting sucked in the Medium Path (PXL) for APCL/URLF inspection.



Yes, the traffic between the two internal networks needs to "fall off" the end of the APCL/URLF policy and not match any rule at all; this signals to SecureXL that the Medium Path will not be necessary and it can attempt to handle the traffic in the Accelerated Path (SXL). That includes making sure the internal traffic doesn't match the "Any Any Any_Recognized Accept" default rule at the bottom. You cannot define an explicit APCL/URLF rule matching that internal traffic and essentially say "don't do APCL/URLF".

Thanks Tim, this sounded familiar, so i went back and re-read pages 184 - 191 of your book and it makes a bit more sense. I verified that "any" is not a destination in the APCL/URLF policy. If you could indulge a few follow-ups?

My AP/URL policy is pretty simple, only 15 rules - the 15th being any -> internet Block, and it has 134K hits (compared to 4M for an accept rule higher in the policy). In the fw policy, the browsing rule is pretty simple: locally_connected_networks -> "not-internal" http/https accept. And then in the APP/URL policy, i have a hierarchy of rules that use access roles, and categories, allows and blocks. My assumption for the drop rule having hits is it's people that don't belong to any browsing access role, trying to get out - and they shouldn't be able to. So, i assume if i remove the APP/URL cleanup rule 15, those users will still be blocked because they're not specifically allowed?

The browsing rules in the APP/URL policy obviously use "internet" as the destination - since internal sites now qualify as "internet" - should i change the destination on the APP/URL policy browsing rules to "not-internal".

Thanks again

[ShadowPeak.com]

Thanks Tim, this sounded familiar, so i went back and re-read pages 184 - 191 of your book and it makes a bit more sense. I verified that "any" is not a destination in the APCL/URLF policy. If you could indulge a few follow-ups?

My AP/URL policy is pretty simple, only 15 rules - the 15th being any -> internet Block, and it has 134K hits (compared to 4M for an accept rule higher in the policy). In the fw policy, the browsing rule is pretty simple: locally_connected_networks -> "not-internal" http/https accept. And then in the APP/URL policy, i have a hierarchy of rules that use access roles, and categories, allows and blocks. My assumption for the drop rule having hits is it's people that don't belong to any browsing access role, trying to get out - and they shouldn't be able to. So, i assume if i remove the APP/URL cleanup rule 15, those users will still be blocked because they're not specifically allowed?

The implicit cleanup rule for an APCL/URLF layer has an action of Accept and you are not allowed to change it on a R77.30 gateway; the default action is Accept because typically the APCL/URLF policy is a blacklist as opposed to the Firewall/Network policy which is a whitelist. Using R80+ management for an R80.10 gateway, you are allowed to change the action of the implied cleanup rule from Accept to Drop in a policy layer's properties. Without breaking the consolidated interface to your vendor back into two interfaces, I think you are stuck in your current situation with an R77.30 gateway.

The browsing rules in the APP/URL policy obviously use "internet" as the destination - since internal sites now qualify as "internet" - should i change the destination on the APP/URL policy browsing rules to "not-internal".

Thanks again

You can try that, but I'm pretty sure it won't matter since the only way internal to internal traffic can avoid the Medium Path is by falling off the end of the APCL/URLF policy and it sounds like you won't be able to do that since your R77.30 APCL/URLF layer is essentially a whitelist, and it was assumed in R77.30 that you'd be doing a blacklist in that layer. You need the flexibility of a R80.10+ gateway. In a Threat Prevention (TP) policy you can create a rule with what I call a "null" TP profile in my book to explicitly keep matching traffic from being pulled into the Medium Path by TP, but that is not possible with a APCL/URLF layer...