Device based policy performance?

[Kenundrum]

Does anyone know if device policies incur a performance penalty?

For example, if you have a policy with one source address, is there any reason not to also include the MAC address by including it in the source device type in the policy? Using the device identification and adding an alias to a detected device will allow you to select that specific MAC address as a device type and effectively create a rule where the source IP and source MAC must match in order to pass. Conceivably, since it is already scanning the header, comparing the mac address should be trivial. If someone is going to come out and say that it drops performance by 50%, then i may not decide to enable it on a bunch of policies 

The annoying thing is the mac address detection doesn't work consistently when the traffic has traversed a router, so it is only really viable for traffic originating on the same L3 subnet as the source interfaces.

[MikePruett]

On a properly sized FortiGate there should be no issue handling this. I have not had any negative performance impacts when performing device based policy in my environments.

[emnoc]

The annoying thing is the mac address detection doesn't work consistently when the traffic has traversed a router, so it is only really viable for traffic originating on the same L3 subnet as the source interfaces.

that's because layer3 devices swaps the  ether_addr of the host for that of the forwarding. That's why it's not beneficial to  use mac_address for detection IMHO and has many risks and expsoures

e.g

dynamic_mac ( i.e VMware )

changing hardware

etc...

[MikePruett]

emnoc wrote:

The annoying thing is the mac address detection doesn't work consistently when the traffic has traversed a router, so it is only really viable for traffic originating on the same L3 subnet as the source interfaces.

that's because layer3 devices swaps the  ether_addr of the host for that of the forwarding. That's why it's not beneficial to  use mac_address for detection IMHO and has many risks and expsoures

e.g

dynamic_mac ( i.e VMware )

changing hardware

etc...

Didn't even think of that when I originally read this thread. Spot on EMNOC!

[Kenundrum]

All of the devices i manage are internal segmentation firewalls talking between servers with explicit rule definitions for everything- no any rules. We have control of both the less and more secure sides of the network. So i would use both source IP and source MAC on the most of the important rules that don't traverse a router on the way to me. The theory is this makes it more idiot-proof. Mainly, if something causes a change to the mac address, that is a change we need to be aware of, so it makes sense to block traffic until that is corrected.

One example i'm told all the time is when you take a server out and then assign a different system the same IP address but forget to do a firewall rule cleanup. Now that new server has all the same access as the old server even if it's not supposed to. But the mac address would have changed so this would likely prevent that. It also would make spoofing a little harder to do.