Inter-VLAN Traffic un-controlled

[mohamed_sabbah]

Hi All,

Met a strange behavior from FG-200D 5.4 software, where I created multiple VLAN sub-interfaces on the LAN physcial interface, while setting all to Role: LAN. I created policies to control inter-VLAN traffic, but while testing I noticed that the Inter-VLAN traffic goes un-controlled (no logged traffic detected hitting the policies), however, when I changed the Role to "Undefined", the expected behavior took place. What is this Role setting under the VLAN interface configuration? Is it like assigning the VLAN sub-interface to a "LAN" Zone while allowing intra-zone traffic?

[tanr]

Hello,

I'm not sure I have any answers for you, but a few questions to help clarify this:

[ol]

Is all your vlan traffic to the FGT (from your switch) tagged?  If not I don't think this will work.

When you say you have multiple vlan sub-interfaces on the LAN physical interface, does this mean that all your vlan sub-interfaces are on a single physical port, or are they are on separate physical LAN ports?

Are any of the involved physical or vlan interfaces members of a zone?  If so, is "Block Intra-Zone Traffic" checked?

Do your policies controlling inter-VLAN traffic have NAT enabled?

When you don't have the vlan's roles set to LAN is some other policy is getting hit?  Depending on your setup you could just check this by watching which policies increase the count of their bytes going through.  If some other policy is getting hit in that case, perhaps you could (carefully) move the inter-VLAN policies higher in the list.[/ol]

[mohamed_sabbah]

I think I found the issue to be the ISP router configuration and enforced routing bahvior on the fortigate by policy routing. Besides the public ip address, the isp router also had a secondary private ip address from the native vlan range with a cable connection direct to the core switch. Also, I have configured policy routing to route any destination through that wan interface connecting the isp router. So looks like the policy routing was preferred to the "connected" routes, and the traffic which must be blocked found a route back to the native vlan through the isp router. As this is a demo setup, we could not change configuration on isp router, so I created a policy route that stops policy routing for inter-VLAN traffic at same time changed the Role to undefined, then issue was resolved. So I believe the issue is not from the Role settings but rather from policy routing overriding the connected routes and isp router routing that traffic back to native vlan.

[mohamed_sabbah]

Question: Is this the normal expected behavior, that the Policy Routes overrides the Connected Routes? I was trying to find a reference for this in Fortinet Documentation with no luck

[ede_pfau]

@mohamed.sabbah:

Yes, policy routes are inspected and followed before the routing table is checked. Unfortunately, there is no visual representation of policy routes so this can become tricky at times.

From the FortiOS Handbook for v5.2, pg. 248 "Policy routing" in "Advanced routing":

If no policy route matches the packet, the FortiGate unit routes the packet using the routing table.

[mohamed_sabbah]

I agree with you about the lack of Highlighted presentation of Policy Routes when inspecting/diagnosing routing issues. Once we look at the Routing Table we expect to see a repository of all IP routing information in that table, and it does not click that policy routes might play a role in changing the Routing Table behavior. It would be great at least to have in the cli list of policy routes on top of the routing table once we "get router info routing-table all" to remind us about the higher priority of those policy routes superseding the routing table. Maybe to preserve the info "routing-table" technical meaning, they could have introduced a new parameter to the command "prouting-table" standing for Policy and Routing-Table information. Or maybe adding a switch to the command to allow including policy-routes ahead of the other routes: get router info routing-table addpolicy all.

[ede_pfau]

I totally agree.

There is one more caveat with Policy routes: if the configured interface is down, the policy route is not removed like with a regular route. Traffic will be sent into Nirvana in this case. Accordingly, there is no DPD/ping server for policy routes.

I wonder if this is ever going to change, and have been for the past 10 years.