In previous articles, we have explained the benefits of internal network firewalls, also known as internal segmentation firewalls. The primary purpose is to secure internal network traffic, particularly between sites, functional areas or departments. Another common use is to provide an additional level of protection for sensitive areas of your network (i.e. databases, R&D) or high-risk areas (i.e. development environments, staging areas).
These developed in popularity so we offered an internal network firewall service to our customers. You can read why below.
When deploying an internal firewall, you need to consider the best way of doing so without compromising performance, availability and reliability. This is particularly important if your business has invested in a highly resilient switch-stack, redundant uplinks etc – and then you jeopardise that by introducing a single point of failure.
We outline some methods of deploying an internal firewall, without impacting performance or reliability.
Network Before ISFW
Typically, the following characteristics exist in an enterprise network with traditional switches and a basic configuration
- High-speed routing between networks
- Fault tolerant (if using a switch stack)
- Limited / Non-Existent access control and policy enforcement
- Limited / Non-Existent Visibility
- Limited / Non-Existent containment capabilities
Network After ISFW
Following the introduction of an internal segmentation firewall, the following goals will be achieved:
- High-speed routing between networks
- Fault tolerant (if using a switch stack and HA cluster)
- Highly secure and granular access control policy between networks, by-user, device, application, time-of-day
- Deep insight and network visibility. Report on users, applications, cloud platforms
- Identify malware, ransomware, potential indications of compromise
- Lock-down and contain incidents in a managed manner. Stop propagation of threats.
Configuration Options
Many questions surround how someone introduces an ISFW solution into a business. We outline a simple example below.
VLAN Scenario (with VLAN interfaces)
Your business may operate multiple VLANs/subnets, this is quite common for organisations running voice-over-IP or where they segment specific departments. An example is below:
- VLAN 1 – Data – 192.168.100.0/24
- VLAN 20 – Voice – 192.168.101.0/24
- VLAN 30 – Accounts – 192.168.102.0/24
- Port 24 – WAN Provider (this connects to remote sites over MPLS)
Assuming the customer has a stack of enterprise switches (i.e. Cisco, Juniper, Huawei) we would typically expect them to use L3 VLAN interfaces, also known as SVIs or IRBs. In effect, the default gateway for each client on the LAN would be the VLAN Interface on the switch.
The switch would handle traffic travelling from VLAN 1 to VLAN 20, using the native routing functionality of the switch.
In many cases – we rarely see clients who enforce access-lists that control the traffic and data that can pass between these VLANs. Additionally, Port 24 may connect to a third party WAN provider to link other offices or an MPLS mesh.
How do I deploy the internal network firewall?
This is perhaps the most common scenario we come across when reviewing enterprise networks. The use of VLANs and subnets makes it easy for a firewall such as Fortinet to be slotted into the network environment. Broadly speaking, the steps required are as follows:
Trunk Mode
This is used where the aggregate traffic levels between VLANs (i.e. 1, 20, 30) are such that they don’t exceed the port speed on the trunk port. i.e. If you only pass 100Mbps of traffic between VLANs, then a 1GE trunk port is fine. However, if you regularly pass multiple Gbps of traffic, you will need a 10GE port or use interface-mode.
- Firewall configured with a trunk interface, to include VLAN 1/20/30, subnets and relevant security policies
- Firewall configured with an additional interface for the WAN provider
- Firewall attached the switch stack on a 1GE or 10GE interface
- Switchport configured as a trunk, but port disabled
- VLAN interfaces (i.e. SVI, IRB) disabled/removed from the switch
- Switchport to Firewall enabled
- WAN provider plugged into Firewall
Interface mode
- Multiple firewall interfaces configured to include subnets and security policies
- Firewall configured with an additional interface for the WAN provider
- Multiple access ports configured on the switch stack with respective VLAns
- VLAN interfaces (i.e. SVI, IRB) disabled/removed from the switch
- Switchports to Firewall enabled
- WAN provider plugged into Firewall
VLAN Segmentation Best Practice
It is not uncommon for business networks to deploy multiple VLANs. Perhaps the most common is a VLAN for data and a VLAN for voice traffic (called the voice-vlan). The primary justification for having a separate VLAN for voice and data is really down to the quality of service. With modern switches, you can assign a higher priority (802.1p) to the voice VLAN meaning that in times of high traffic, the switch prioritises the voice traffic – meaning there is no loss in quality.
The thing with having this basic setup is it does not really enhance your security…
My recommended strategy for VLAN segmentation would be to consider:
- Separate VLANs for high-risk or sensitive user groups/departments. For example, your Development, Accounts or Legal teams.
- Consider creating separate VLANs and subnets for these groups.
- Importantly – if you are going to do this – consider the ACL or firewall policy that controls access between these subnets. For example, Accounts can access your server VLAN, but should not be able to access the Development VLAN.
It is only when you start implementing policies do you realise the value in an internal segmentation firewall. As the policies become more complex, writing the ACLs on a switch can quickly become a pain in the ass. At least with a firewall, you benefit from a web interface or CLI that is more akin to developing firewall policies.
Simply deploying VLANs without a security policy does achieve something (separate broadcast domains) but it does not really enhance your security. Unless you are doing it for morale, or basic network segmentation.
What about HA?
This is a relatively easy addition. To do so, once a Fortigate firewall cluster is present, you simply need to double up on the switch ports and for best practice, spread the switch ports across different stack members. Using the HA cluster feature, the firewalls can monitor the liveness of the switches and the firewalls to failover in the event of an outage.
Summary
Introducing an internal segmentation firewall into your network environment is easier than you think. The benefits, protection and visibility the firewall provides will deliver a real business benefit.
If you would like to learn about how MTG can help secure your internal network and protect against emerging threats, please give us a call or e-mail.
We provide a managed firewall service where we can design, supply, install and support your internal network firewall (or we can just help)
For more information view our other blog posts:
