A blog series on the “Future of the Firewall”; that’s optimistic, as it implies that the firewall has a future.

For the record, I think that it does, I just hope we use firewalls more wisely in the future. I see both challenges and opportunities for the present and the future of the firewall; and, as is often the case in life, the challenges and opportunities are two sides of a single coin.

Modern firewalls have become much more than packet filters, and are much more powerful – if used correctly. The great advantages in versatility of NGFW, UTM, or whatever you use, do carry a burden of complexity.


A common challenge remains proper configuration; this is a challenge we have faced for years, and I do not see it disappearing any time soon. Not that early firewalls were exactly “user-friendly”, but with limited feature sets came a smaller range of things to get wrong.

I think that, in general, modern firewalls are easier to deploy and configure properly, but added features do add complexity. The race to add features and functionality to firewalls (or any technology) is also a race with usability and user experience, a race we don’t always win.

IPv6 presents a related threat to the effectiveness of firewalls. I know I’m not alone in having seen firewalls misconfigured down to being very expensive NAT devices. As worrying as that is with IPv4, at least most organizations rely on RFC 1918 addresses internally and thus have some protection with NAT.

The growing numbers of IPv6 deployments threaten to expose millions of devices directly to the Internet as enormous blocks of publicly routable IPv6 addresses are assigned to internal devices.

If we make the same “Any-Any-Any-Allow” type errors in our IPv6 rule sets as we have in NAT IPv4 environments it will not be pretty, as the only remaining “defense” will be hiding in the enormous IPv6 address space, and as soon as we’re on the Internet that is lost to anyone tracking Internet activity.

One of the often-overlooked features of the firewall, whether hardware, software, or virtual, is its value as an inspection point. When trying to see what is really happening on our networks there are few better places to capture and analyze traffic than on firewall interfaces.

Properly sized and configured firewalls should no longer be network “choke points”, but they should be analysis windows. Well-designed traffic analysis should help validate that our rules are working as intended (software has an ugly tendency to do what we tell it to do, not necessarily what we want it to do), and much more.

The firewall’s value as a source of data is not limited to the external traffic capture and analysis; all of the added features of modern firewalls can provide a great deal of insight into your environment when logs are fed to a well-tuned log analysis or SIEM platform. Add traffic analysis, packet filter logs, and other firewall-related data sources and you have a great deal of data with context to add to your analysis capabilities.

This use of firewalls as enhanced data sources is not as common as I think it should be, probably because of the different teams involved, but I believe it is one of the most overlooked values offered by modern firewalls – and one of the easiest to leverage.

Join The Conversation

We encourage you to share your thoughts, and we look forward to reading your comments. We invite you to subscribe to our blog to keep up with the latest posts of our new series.