Skip to main content
obrienw
obrienw
New Member
February 20, 2015
Solved

FortiGate 90D blocking broadcast address on internal subnet.

  • February 20, 2015
  • 4 replies
  • 15935 views

FG 90D, v5.0,build3608 (GA Patch 7)

 

Small branch office.  Internal interface subnet is 10.5.0.1/24.  The FG internal interface address is 10.5.0.1.  All users are on that subnet and I'm using the FG switch ports and PoE for hubs, APs, etc.

 

I noticed from the logs that a lot of traffic from the internal users to 10.5.0.255 is being denied (137-8, udp).  The logs show that the destination interface is "root" and policy 0 is applied.  There is no "root" interface listed, and I have no internal -> internal policies or a policy 0.

 

Any idea why it's doing that and how I stop it?

 

I never defined a static route for 10.5.0.0/24 since the routing monitor showed it as connected already -- I don't know if that's the problem?

Best answer by ShrewLWD

Hi Obrienw,

 

Unless you are looking to have that traffic explicitly forwarded on to another subnet, all you really want to do is ignore.  Remember, a broadcast is exactly that...a broadcast to multiple devices.  Every device on the subnet already heard it, what you are reading is the Fortinet's decision on what to do with the packet it received: in this case, it's saying I'm not going to respond or forward this on.  The Fortinet cannot control who else sees the packet on the same interface, it can only control what it does with the packet it received.

 

if you *do* want that packet forwarded on, then use the 'set broadcast-forward enable' setting on that particular interface.

4 replies

Rewanta_FTNT
Staff
Rewanta_FTNT
Staff
February 20, 2015

hi,

broadcast traffic are not allowed by default so it blocked by implicit deny rule 0. 

 

thanks,

rewanta

 

obrienw
obrienwAuthor
New Member
February 23, 2015

Thanks.  How do I stop from blocking?  Just an internal-to-internal policy that accepts all?  Should NAT be enabled on that.

ShrewLWD
ShrewLWDAnswer
New Member
February 23, 2015

Hi Obrienw,

 

Unless you are looking to have that traffic explicitly forwarded on to another subnet, all you really want to do is ignore.  Remember, a broadcast is exactly that...a broadcast to multiple devices.  Every device on the subnet already heard it, what you are reading is the Fortinet's decision on what to do with the packet it received: in this case, it's saying I'm not going to respond or forward this on.  The Fortinet cannot control who else sees the packet on the same interface, it can only control what it does with the packet it received.

 

if you *do* want that packet forwarded on, then use the 'set broadcast-forward enable' setting on that particular interface.

obrienw
obrienwAuthor
New Member
March 2, 2015

I contacted support because I was getting confused, and they confirmed that ShrewLWD has the correct answer. 

 

For those with weak networking skills like myself that are still confused, here's another way of looking at it (NOTE - this probably isn't technically correct, but it makes sense in head, at least):

All devices on the subnet also have the broadcast address "assigned" to them just by virtue of being on the subnet.  The logs in question aren't describing an event where data has gone from a source, to the FortiGate, and then is supposed to exit to somewhere else, but is being blocked.  What they're describing is the FortiGate's reaction to receiving broadcast traffic for its own assignment of the broadcast address, not any other device.  Since, by default, the FG doesn't respond and it doesn't forward, it logs a "deny" event.  (IMO "deny" is a little misleading, it's more like "ignoring," but that would create more logging complications.)

emnoc
emnoc
New Member
February 24, 2015

If this is a routed-nated vdom, than I have to respectively disagree. Broadcast are local to that L3-subnet and the set broadcast forward command is use for l2-transparent mode. And finally the TTL will most likely be 1 , so it would never get forward to begin with.

 

 

 

ShrewLWD
ShrewLWD
New Member
February 26, 2015

What emnoc said!

I use transparent mode so often (with bcf enabled) I forget its not useful in a NAT'd VDOM.  There is nothing really you can do about what you are seeing except ignore.  I believe there was, at one time, an option to explicitly not log those kinds of packets, but memory is failing me atm.

 

 

EDIT:  From another post:

 

config log setting      set local-in-deny disable end

 

 

Terms & ConditionsAccessibility statement