Firewall & VPN: secure separation, stable operation
A firewall is rarely “just a device on the edge.” In modern environments with cloud components, branch offices, SaaS integrations, and remote work, network security is determined by clear zones, clean data paths, and reproducible rules—not by the number of activated features. At the same time, expectations are rising: in many industries, security programs are becoming more focused on standards and verifiability (e.g., NIS2-oriented measures, BSI-related procedures, or ISO/IEC 2700x as a reference framework), while operations must remain fast.
This is precisely where “somewhat secure” differs from an architecture that remains stable even in the face of changes, team changes, and disruptions. Those who think of firewall and VPN structures as part of the operating model—including ownership, update discipline, logging, and tested failover routines—reduce friction, lower risk, and gain transparency without drowning everyday life in complexity.
Why firewall design is more than perimeter protection today
Companies are currently feeling the effects of two forces simultaneously: a faster pace of change (new services, locations, cloud connections) and a more realistic threat situation due to ransomware playbooks, lateral movement in the network, and compromised identities. In this reality, the firewall is not a “stop sign” but rather the central tool for separating systems and responsibilities from one another: What is allowed where—and why?
Good firewall design has a direct impact on operations and costs. Clear segmentation reduces blast radius, simplifies troubleshooting, and makes changes less risky. Clean VPN concepts minimize shadow IT (uncontrolled tunnels, private admin access) and increase availability because access does not remain “person-dependent.” And: When audits or internal reviews increase, comprehensible rule and zone logic is often the difference between “documentable” and “laboriously reconstructable.”
Operating model & ownership
Who is responsible – throughout? A viable model separates roles (network, platform, application, security), defines change processes, and prevents firewall rules from becoming a “collection point” for unresolved architecture decisions. Proven in practice: a zone and naming standard that remains understandable even when new teams take over.
Update & Security Capability
Patchability is a core discipline today – not only because of CVEs, but also because many stacks consist of multiple components (firewall OS, plugins, IDS/IPS rules, VPN clients, certificates).
The decisive factor is whether updates can be planned to fit into operations: maintenance windows, rollback options, config drift control, and a clear rule for when a “hotfix” is really necessary.
Integration, Data & Lifecycle
Firewall design is always also integration design: identity (LDAP/Kerberos/SSO), logging (SIEM/SOC), address and object management, cloud routing, and the lifecycle of services. Especially for provider and product lifecycles (support windows, LTS policy, discontinuations), it pays to have a setup that makes configuration versionable and keeps dependencies transparent.
Trainings
Specific trainings and current topics can be found in the Comelio GmbH course catalog.
Whether in-house at your company, as a webinar, or as an open event – the formats are flexibly tailored to different requirements.
Typical misunderstandings that make projects unnecessarily difficult
“Default deny is enough – the rest is detail”
“Default deny” is a good guideline, but without a zone model, naming concept, object maintenance, and lifecycle rules, a set of rules quickly emerges that may seem strict but is circumvented in everyday use. In practice, we often see that a lack of structure leads to “temporary” approvals that never disappear.
“VPN is VPN”
Remote access, site-to-site, and machine-to-machine tunnels have different requirements for identity, MTU/transport, routing, and operation. Added to this is the reality of providers: today, remote stations are often cloud gateways, SD-WAN, partner networks, or managed devices—one reason why interoperability and troubleshooting capabilities are becoming more important than “the fastest tunnel.”
“Turn on IDS/IPS and you’re done”
An IDS/IPS is not a switch, but a process. Without tuning, feed selection, baselines, and clear escalation paths, it either generates noise or a false sense of security. Especially with increasing encryption and east-west traffic, the question of where sensor technology makes sense and how results remain usable in operation is becoming more important.
“High availability is solved with two boxes”
HA is not just hardware redundancy, but state sync, clean health checks, tested failover/failback runbooks, and a realistic view of multi-WAN. Those who do not practice this regularly often experience switches as a “surprise” when they should actually be routine – a classic in environments with tight patch and change windows.
Initial consultation / project initiation
If a conversion, consolidation, or HA/multi-WAN design is already pending, it is worth having a structured initial consultation to sort out the target vision, risks, and approach.
Frequently asked questions about firewalls and VPNs
In this FAQ, you will find the topics that come up most frequently in consulting and training sessions. Each answer is kept short and refers to further content if necessary. Can’t find your question? We are happy to help you personally.
WireGuard, IPsec, or OpenVPN – when to use which?
WireGuard is strong when a lean, easily maintainable tunnel with little overhead is required. IPsec often scores points for interoperability with heterogeneous remote stations (hardware, cloud gateways) and established standards. OpenVPN remains relevant in legacy or client-specific ecosystems. The decisive factors are remote stations, operating costs, MTU/routing, and the question of how well error patterns can be diagnosed by the team.
How do you build HA & Multi-WAN without sessions constantly breaking?
State synchronization, clean health checks, and a routing/NAT concept that takes failover into account are important. In addition, test scenarios (failover and failback) and runbooks are needed that are not only documented in the wiki but also practiced. Multi-WAN becomes stable when policy routing, sticky connections, and dependencies (DNS, VPN, SaaS) are explicitly addressed.
IDS/IPS without a flood of false positives – is that realistic?
Yes, if you plan it as an iterative process: first visibility (IDS), then tuning (feeds, exceptions, baselines), and only then inline drops. It must also be clear how alerts are processed (correlation in the log/SIEM, responsibilities, response paths). Without this operational integration, IDS/IPS remains either noisy or ineffective.
How do I pragmatically secure admin access without blocking operations?
With standards: zone model, name/object concept, owner per service, regular review windows, and a clear “expiration date” for temporary approvals. In addition, versioning/automation helps to avoid drift and make changes traceable – especially with frequent patches and platform updates.