options to segregate host on a LAN

[journeyman]

We have a /24 LAN configured on a vlan interface. It has been requested to segregate one host on the LAN so it can only reach other LAN hosts via defined policies.

Is it possible to do this without changing the host IP address, subnet and default gateway?

For instance, is there any way that can two VLANs be treated as one interface in terms of their subnet but control traffic between them using policies?

We have a lot of flexibility with VLAN configuration. We do not currently use zones but I do not believe this would help.

The managed switches support private VLAN, but this is not an option since we have multiple switches on the LAN (the privacy setting is restricted to the local switch only).

From what I can see this is not possible, but it is certainly worth asking.

If there are no other options we'll just assign a new IP range to the host and proceed with a regular layer 3 solution. But it would be very nice to do this somehow "in the background". And it would be very useful elsewhere - Oh, all those stray devices I could isolate!

[Kenundrum · Accepted solution]

I have this kind of setup on one of my boxes. I believe this is refered to as a VLAN translation setup. Here is a quick simplified overview...

You have your "normal" unsecured, everything else VLAN. You then also have one or more "secured" vlans depending on your segregation needs. You have a fortigate operating in transparent mode connected to a switch. On that switch, you have devices plugged into ports that are ONLY allowed to use one vlan. So your users and upstream routers are connected to vlan 1, a web server on vlan 2, and database on vlan 3 (for example). The web server switch port is only allowed vlan2, the database port is only allowed vlan3, and all other ports are only allowed vlan1. You then have your fortigate plugged into the switch on a trunk port that is allowed vlan 1, 2, and 3. You create rules that state users can connect from vlan1 to vlan2 to the web server on appropriate ports. The web server can connect to the backend database from vlan2 to vlan3 on appropriate ports, but users on vlan1 cannot talk to the database due to an implicit deny.

What happens is that in transparent mode- the firewall will advertise mac addresses across all interfaces. So your web server on vlan2 cannot see any other devices because only it and the firewall sit on vlan2. The firewall advertises that it has routes to all other mac addresses on the local network and therefore traffic can flow. The same holds true in reverse for users to get to the web server as long as appropriate firewall policies are in place.

Doing it this way allows you to scale your setup as you can just add more ports to the secured vlan and protect more servers behind the firewall without every changing any ip settings. The caveat is that the machines on the same vlan have unrestricted access to each other and you will eventually need aggregated interfaces to make sure you have enough throughput. You can also do this in a cheap fashion by directly connecting the devices to the physical interfaces on the firewall and forgetting about vlans- but it doesn't scale.

if you already have a NAT mode fortigate- you need to enable VDOMs and create a new transparent vdom which will add some complexities. You could also just build a transparent mode configuration from the ground up if that is the device's only function.

[ede_pfau]

IMHO you can only police / manage this host's traffic on the FGT if it traverses the FGT. This implies routing at least, so you will have to change the host's address or net mask. It just won't use the FGT if addressing other hosts in the same subnet.

On the FGT you then have the device dependent policies to do whatever you like.

[journeyman]

By asking here I was hoping to discover an sufficiently advanced technology of which I was ignorant :)

I know it is necessary to force the traffic to traverse the FGT; it is easy to do that by applying a new subnet but was hoping the FGT could somehow magically have one subnet on two interfaces and force the traversal that way, or something.

And if this magic existed, it would then be possible to isolate any device on our networks at will, and oh how powerful that would be.

[Iescudero]

Hi there!

The only way to achieve this is if the traffic goes through the firewall, we're all agree with that, but that doesn't mean that you have to create a new subnet or vlan to do that.

You can do this putting your fortigate in transparent mode:

"...A FortiGate in Transparent mode is installed between the internal network and the router. In this mode, the FortiGate does not make any changes to IP addresses and only applies security scanning to traffic. When a FortiGate is added to a network in Transparent mode, no network changes are required, except to provide the FortiGate with a management IP address. Transparent mode is used primarily when there is a need to increase network protection but changing the configuration of the network itself is impractical..."

Hope it helps!!

[dmcquade]

I don't believe transparent mode will help. In this mode, the FGT is typically placed inline to the next hop / router. If devices are on the same subnet and connected into the same switch, the FGT will never inspect the traffic.

What I would recommend is to segment the network into multiple VLANs. You could then make a physical connection between your FGT and the switch as a trunk connection. Define VLAN interfaces on the FGT to match the VLANs on the switch. Then you can create policies using the VLAN interfaces for the source and destination interfaces in your policies. You would also have to make sure you have inter-VLAN routing disabled for the VLANs that you want to pass through the firewall. The firewall's VLAN interface IP address should be the default gateway for the hosts on that VLAN. If you use DHCP, you will need to setup a separate DHCP scope for each VLAN.

Hope that helps.

Don

[emnoc]

Your using a wrong  device for this . If you want layer2 restictions between 2 or more hosts &  in a common subnet , than  you need  one or combination of ;

layer2  PVLAN enabled switches

layer2  multiple-VLANs and use a layer3 filter ( ACLs or stateful firewalls )

layer2  VACLs  supported switch ( vlan acls )

host_based_firewall-services applied on that host directly

etc....

A layer3 router firewall or transparent mode is NOT going to  help

[Kenundrum · Accepted solution]

I have this kind of setup on one of my boxes. I believe this is refered to as a VLAN translation setup. Here is a quick simplified overview...

You have your "normal" unsecured, everything else VLAN. You then also have one or more "secured" vlans depending on your segregation needs. You have a fortigate operating in transparent mode connected to a switch. On that switch, you have devices plugged into ports that are ONLY allowed to use one vlan. So your users and upstream routers are connected to vlan 1, a web server on vlan 2, and database on vlan 3 (for example). The web server switch port is only allowed vlan2, the database port is only allowed vlan3, and all other ports are only allowed vlan1. You then have your fortigate plugged into the switch on a trunk port that is allowed vlan 1, 2, and 3. You create rules that state users can connect from vlan1 to vlan2 to the web server on appropriate ports. The web server can connect to the backend database from vlan2 to vlan3 on appropriate ports, but users on vlan1 cannot talk to the database due to an implicit deny.

What happens is that in transparent mode- the firewall will advertise mac addresses across all interfaces. So your web server on vlan2 cannot see any other devices because only it and the firewall sit on vlan2. The firewall advertises that it has routes to all other mac addresses on the local network and therefore traffic can flow. The same holds true in reverse for users to get to the web server as long as appropriate firewall policies are in place.

Doing it this way allows you to scale your setup as you can just add more ports to the secured vlan and protect more servers behind the firewall without every changing any ip settings. The caveat is that the machines on the same vlan have unrestricted access to each other and you will eventually need aggregated interfaces to make sure you have enough throughput. You can also do this in a cheap fashion by directly connecting the devices to the physical interfaces on the firewall and forgetting about vlans- but it doesn't scale.

if you already have a NAT mode fortigate- you need to enable VDOMs and create a new transparent vdom which will add some complexities. You could also just build a transparent mode configuration from the ground up if that is the device's only function.

[journeyman]

Kenundrum's solution sounds great and I will investigate this further. Others respondents above have said a transparent firewall won't work, any comments on the solution as described?

We already have our Fortigate in NAT mode and would hence be looking at a transparent VDOM. But it might be worth the effort to implement due to the stuff we find on our networks. We have not used FGT VDOMs before, I guess I'll be doing a lot of reading in the near future. Can we leave the bulk of the configuration in the root vdom and "add on" the transparent vdom? Any tips on VDOMs, traps for beginners?

@emnoc - Thanks, VACLs are new to me. They would be ideal but unfortunately the functionality is not available on our hardware. We already investigated PVLAN but on our hardware it's limited to the local switch; because we have multiple switches looped together the functionality fails. I don't believe that PVLAN would actually solve our problem of controlling access to other hosts on the same VLAN; it would only block it completely.

If a transparent VDOM gets too hard, VLANS and layer 3 rules will have to do. But I am hopeful. Thanks all for your comments.

Edit: Existing FGT is an A-P HA cluster running in interface mode with OSPF on one interface.

[oheigl]

If you activate VDOMs on your device everything will be moved to the root VDOM, so nothing really changes on your existing setup. Then just create a new VDOM and put the interfaces in this new VDOM you would like to configure.

Regarding Kenundrum's solution I have a question: I understand how it should work, but why should the FortiGate forward these packets between the different VLANs?

I did some research, and it seems that it really is enabled by default (taken from the Layer 2 solutions guide on the KB): Note: Broadcast packets will be flooded to all ports even if the VLAN ID is different. This is a common cause of broadcast storms and/or packet of death spirals in L2 deployments. 

I guess this will really work, but I hope you are not running into some serious issues with loops and storms etc. I would advise you to configure a separate network for this host, it's much cleaner and safer this way.

[Kenundrum]

So there are a few caveats to the setup. In general a layer 2 setup is a stopgap. After 3 years of running layer 2, we are making arrangements to migrate to layer 3 and change a bunch of ip ranges for servers and end up segregating a lot more devices. You end up with a bunch of questions like "hey is that thing behind the firewall" because the ip addresses are scattered all over the place. it's a lot easier to simply know that all the servers with 192.168.20.x are web servers on vlan20 and 192.168.21.x are databases on vlan21. 

You can also only do one subnet per transparent vdom, so all of them need to be in the same ip range. I don't have a problem with the broadcast packets because i have very strict firewall rules. I did have a problem with port flapping in fortios 5.2.x. On the trunked ports, the fortinet was advertising mac addresses on both the vlan tagged and untagged interfaces- so the switch was seeing mac addresses on multiple vlans and was shutting down the ports to prevent broadcast storms. I had to set the default untagged vlan id for the trunk ports to go to a blackhole on the switch to stop that. In hindsight, changing the forward-domain for the untagged interface on the firewall probably would also work.