An Open Letter to Firewall Manufacturers Looking to Enter the Home Integration Market

As home networks grow more connected and more exposed, WhyReboot’s Bjørn Jensen calls on manufacturers to simplify security for integrators.
Published: November 11, 2025

As home networks become an increasingly integral part of any custom install project, and firewalls become an essential point of protection for these networks, manufacturers and integrators need to provide not only a secure product, but also one that understands and is accommodating to the unique demands of the connected home.

Understanding the Problem: Rising Threats to Home Networks

The threats to networks in general are becoming more pervasive as new technologies emerge, especially with the rise of AI-driven bots.

Many tools claim to be the ultimate solution, but few are both effective and simple enough for integrators to use without specialized knowledge. They’re often prohibitively expensive, too.

Instead of chasing every new product, we should focus on understanding where threats come from — the attack vectors. By addressing these, we can mitigate most risks without relying solely on paid security services such as Intrusion Prevention, Intrusion Detection, or IoT detection.

Proper network segmentation and predefined access rules can handle most of the work.

Identifying Attack Vectors

An attack vector is any method a threat actor uses to gain access to a network. This could be as simple as leaving a port open on the internet or allowing ICMP echo requests (pings) to reach your public IP.

A quick search on shodan.io can reveal countless exposed devices. For example, on stage at an ESA (Electronic Security Association) conference, I demonstrated how easily one could access unsecured control systems or IP cameras exposed by poor port forwarding practices.

Whether it’s a well-known control system port or port 80 for a camera with default credentials, open ports are like leaving a door unlocked for a thief.

To be absolutely clear, neither of those were the fault of the control system company or the camera manufacturer, they are the fault of whoever opened the ports on the appliance and pointed them to those devices.

A Real-World Example: Compromised Cameras

Consider a camera system. Many cameras run lightweight Linux builds, and while good manufacturers issue frequent patches, many do not. Integrators must ensure regular firmware updates.

An unpatched, internet-exposed camera can easily be compromised, giving an attacker remote access to install hidden software. From there, the attacker has a foothold inside your network. Without VLAN segmentation or inter-VLAN restrictions, the attacker can explore the entire network — especially if it’s flat with no internal routing or firewalls.

Once inside, the attacker controls the camera through their Command and Control (C2) system and scans for more vulnerabilities: an unpatched PC, a misconfigured app opening a port, or a weak internal firewall.

They can exfiltrate data through an encrypted SSH tunnel, invisible to most systems, since home networks rarely block outbound traffic. While AI-driven monitoring or SOC services can detect such behavior, prevention is always better than detection.

Seeing How Vulnerable You Are

Want to see your own exposure? Visit ipchicken.com to find your public IP, then paste it into Shodan. If your network shows results, you’ve got open doors.

Unless you use a SASE (Secure Access Service Edge) or similar tunneling service, most sites still need VPN ports like TCP 443, UDP 500, and UDP 4500 for IPsec NAT traversal (ESP 50 for encryption).

Manufacturers are moving away from SSLVPNs due to recent compromises. While keeping appliances patched is critical, any open port remains a potential attack vector — one that SASE or similar cloud-managed security can help eliminate.

Today’s Mitigation Strategies: Segmentation and Stateful Firewalls

Before diving into specific strategies, it’s important to note that segmentation and firewalls are not the only methods of protection. They are, however, one of the primary means to defend a network.

A comprehensive approach should also include onboard security service subscriptions or, better yet, a SASE (Secure Access Service Edge) solution that tunnels all traffic through the SASE cloud for inspection and cleaning, along with reliable anti-malware services on endpoints.

To prevent lateral movement or data exfiltration, segmentation is key. Start with VLANs and use a stateful firewall to manage communication between them. For example:

  • Core Network – For switches, routers, controllers. Accessible by admin only; other VLANs cannot initiate connections here.
  • Homeowner Network – Contains computers and sensitive data. Can reach other VLANs only for defined services (specific IPs, ports, protocols).
  • Control System Network – For control system devices; should only be allowed to talk across VLANs to defined devices, e.g., cameras. (specific IPs, ports, protocols).
  • Camera System Network – For NVRs and cameras, generally doesn’t need to talk across VLANs so is isolated from other VLANs.
  • Guest Network – Internet access only, fully isolated from internal devices.

If you block all outbound traffic and then explicitly allow what’s needed — like TCP 80 and 443 for web browsing, UDP 53 for DNS — you can safely browse while preventing compromised devices from “phoning home.”

Stateful firewalls allow return traffic for legitimate sessions, meaning trusted devices can initiate connections while untrusted ones cannot. This is not limited to Internet access—it’s critical for inter-VLAN communication as well. For example, if a homeowner device on the Homeowner VLAN initiates a connection to a control processor or camera on another VLAN, the stateful firewall recognizes that session as established and allows the return traffic back to the initiating device.

Without stateful inspection, these cross-VLAN connections would fail or require complex reciprocal rules. Understanding this behavior helps integrators design networks where communication remains both functional and secure.

Remember, technically we have denied all traffic from something like the control system or camera VLAN back to the homeowner VLAN, but because the homeowner initiated the session, they’re allowed to talk back for that session and that session only.

The Challenge for Integrators

Following the explanation of stateful firewall behavior, it’s important to connect theory to practice.

Tools such as FortiSessions or FortiView allow integrators to observe real-time session data, identify what’s being blocked or allowed, and fine-tune access rules based on source IP, protocol, and port information. This visibility bridges the gap between understanding how sessions work and applying that knowledge to build precise, secure network rules.

Creating and maintaining these granular rules is tedious, however. Each VLAN, service, or device might need multiple specific rules. Even cloud services like Microsoft 365, Teams, Xbox, or even something like Kaleidescape may require unique ports. Some firewalls simplify this through application categories or DNS-based filtering, but in the AV and automation industry, many devices are niche and not recognized by standard databases.

At WhyReboot, we use tools like Fortinet’s FortiView within FortiGate firewalls to visualize live sessions.

Wow, that’s a lot of “Forti!” Still, the process requires manual rule creation and constant testing.  Here’s an example of the FortiView Sessions window where I can see exactly what is currently trying to traverse to the internet (some identifiable data is blacked out):

For all of the above to function correctly, you’d need to ensure all of those ports are allowed, to the specific websites they’re allowed, over the exact protocol they need to use (Note: this is just one window; there are MANY sessions you don’t see here as this is only showing the most recent ones it captures this very millisecond).

On top of that, if something is not actively being used it won’t even show you the session.  So, to testing the functionality of a device is imperative, and then you can filter by its IP address to drill down to exactly what it is using at that time.

A Call to Firewall Manufacturers

Here is the part where I have a request for the firewall manufacturers. We need a simple way to do this. These are the features I’d request if I could build something to easily segment the network and lock it down as much as possible, without the need for additional security services (though that’s another layer of protection you should be using). Remember, this is only one part of protecting your network, but it’s one of the biggest and most effective ways of keeping your network secure.

We need a way to view all active sessions with ports that are being blocked, showing source IP, destination IP, ports, and protocols. We need the ability to easily click on each one and add it to a whitelist that generates an access rule automatically. Ideally, you could even look at a log collected for each source IP to see what it’s attempted to use in the past and then click on that to create the access rule. The log version would be preferable to active sessions because you’d want to ensure you capture all of the device’s needs over time, not just during that short time window you’re looking.

The first network you deploy will most likely be one of the hardest as you’ll need to create a lot of rules. However, if the appliance allows you to copy your settings as a template to future appliances then the next one will have most of the rules already in there. As long as you could constantly update your database, and then be able to sync that database across individual devices or groups of devices, you can constantly make improvements. After deploying dozens of appliances, all with different requirements and different connected products, you would eventually have a tailored access control list that would make your job much easier and is ready for most of the devices you will deploy in the future while disallowing anything else automatically.

In order to essentially hide the network from the internet you also need a way to initiate a VPN connection to the box without open ports. This would require SASE service usually, but it would be helpful if that’s not available or is too expensive to just allow the firewall to dial home to a proxy, or a PoP (Point of Presence) that would then initiate the connection between the home network and your remote device you’re trying to access the home with. The firewall would be in communication with the PoP and when the remote device tries to VPN into the home it requests this access from the PoP which would then essentially marry the two connections together, making the firewall initiate the connection from the inside, thus giving a tunnel for the remote device to talk back with.

Some Final Asks, Unrelated to Security

A few more asks on top of these would be a way to generate reporting that can be automated to send to either the integrator as well as the homeowner on a bi-weekly or monthly basis.  Preferably with the ability for the integrator to upload their logo so that it’s branded.  Reports are important because it gives the homeowner satisfaction in knowing they’re getting what they’re paying for because otherwise network devices are silent, in the background, and easily forgotten.

Some sort of monitoring service would be a nice inclusion, for example Domotz.  If that could be included in the box at a subscription level it has obvious benefits to anyone trying to be proactive with their networks, and the optimal place for this is inside of the router.

One final ask would be to have the ability to use RS232 and/or USB connectivity to remotely open a terminal emulator for consoling into devices remotely.  This would save the need to have a technician onsite with the cables or adapters necessary to do this in order to access devices at the terminal level.  Yeah I know, this is a longshot but I figured seeing as I have a wishlist, this would be of huge benefit to anyone remotely managing a network.

Conclusion

With these features, we can both hide networks from external scans and minimize internal attack surfaces. Even if a device is compromised, lateral spread becomes nearly impossible. Implemented properly, this approach makes robust security achievable for most integrators.

Bjørn Jensen is the President of WhyReboot with over 24 years of experience in networking in a variety of roles. Bjørn has also served as a subject matter expert for CEDIA as well as a contributor for CE Pro on the topics of networking and media centers.

Strategy & Planning Series
Strategy & Planning Series
Strategy & Planning Series
Strategy & Planning Series
Strategy & Planning Series
Strategy & Planning Series
Strategy & Planning Series