OPNsense for Medical Practices: What German KBV Requirements Demand

In the IT-security context, medical practices are a special industry: they process particularly sensitive personal data (health data under Article 9 GDPR), are connected via the German Telematikinfrastruktur (TI) to the national health network, and are subject to the KBV requirements for IT security in the practice. Anyone serving practices as an IT provider knows the tension between “we want it simple” and “it must be compliant”.

OPNsense is a pragmatic choice in this environment: open source, good documentation, all the necessary features (VLAN separation, stateful firewall with logging, IDS/IPS) — without the licence cost of a Sophos/Fortinet/SonicWall solution. What OPNsense does not replace: the TI connector hardware or the TI connector itself. OPNsense complements TI security — it is not part of the gematik certification.

Note for international readers: TI (“Telematikinfrastruktur”) is Germany’s federally regulated health information exchange — a closed, certified network for medical practices, hospitals, and pharmacies. KBV is the National Association of Statutory Health Insurance Physicians, which sets IT-security baseline requirements for outpatient practices. The principles described here apply to comparable regulated medical networks elsewhere (HIPAA technical safeguards, NHS DSP toolkit etc.) with adjusted terminology.

This article describes what KBV requirements demand of practice networks, how OPNsense implements them, and where the line runs between OPNsense responsibility and TI responsibility.

What the KBV Prescribes — Briefly

The KBV IT Security Guideline (under § 75b German Social Security Code Book V) has been binding since 2021. It lists requirements in stages — depending on practice size — and contains several concrete points on the network side. At the core:

• Separation between practice LAN, TI connectivity, and guest Wi-Fi
• Firewall with logging of connections
• Encryption of sensitive data transmissions (mail, practice management system updates etc.)
• Secure patch management of devices in the practice network
• Defined TI connections — only necessary connections allowed

Important: the guideline is technology-neutral. It does not say “you need OPNsense”, it says “you need a firewall with the following properties”. OPNsense fulfils these properties fully.

Typical Practice Topology

For a standard medical practice we recommend a four-zone architecture:

Zone	VLAN	Devices	Internet	Other zones
TI network	VLAN 10	TI connector, card readers	Only to TI aggregator	Only via connector
Practice LAN	VLAN 20	PMS server, doctor PCs, printers	Defined (PMS updates, gematik CMS, KBV portals)	To connector
Diagnostic VLAN	VLAN 30	X-ray, ultrasound, ECG	Only manufacturer updates	To PMS server (read)
Guest Wi-Fi	VLAN 99	Patient waiting-room Wi-Fi	Open	None

TI components must be in their own network. This is not a matter of taste — gematik requires it, and KBV underlines it.

Implementation in OPNsense: VLAN Configuration

OPNsense treats VLANs like ordinary interfaces. On a managed switch the VLANs are tagged, OPNsense receives them as logical interfaces:

Interface: igb0 (physical)
  - VLAN 10 (TI)
  - VLAN 20 (practice LAN)
  - VLAN 30 (diagnostic)
  - VLAN 99 (guest Wi-Fi)

Each VLAN interface is assigned its own subnet — e.g.:

• TI: 192.168.10.0/24
• Practice: 192.168.20.0/24
• Diagnostic: 192.168.30.0/24
• Guest: 192.168.99.0/24

DHCP per subnet with its own lease ranges. The TI connector typically gets a static IP — that simplifies firewall-rule maintenance later.

Firewall Rules We Recommend

The KBV guideline requires explicitly logged connections. In OPNsense that means every explicit rule activates “Log packets that are handled by this rule”.

Practice LAN rule set

# Out from practice LAN
ALLOW practice -> TI connector: connector ports (gematik spec)
ALLOW practice -> internet: PMS update servers (documented by PMS vendor)
ALLOW practice -> internet: HTTPS to KBV portals, Microsoft Update, AV update
DENY  practice -> diagnostic VLAN: (all)
DENY  practice -> guest Wi-Fi: (all)
DENY  practice -> internet: (default)

TI network rule set

# Out from TI
ALLOW TI -> internet: only gematik aggregator addresses (documented by TI connector vendor)
DENY  TI -> practice LAN: (all except inbound from the connector)
DENY  TI -> diagnostic VLAN: (all)
DENY  TI -> guest Wi-Fi: (all)

Guest Wi-Fi rule set

ALLOW guest -> internet: HTTPS, HTTP, DNS (to OPNsense or external DNS)
DENY  guest -> everything else
# Optional: captive portal with daily password

Every DENY rule with logging. With this you have demonstrably logged in case of an incident which connections were attempted — a prerequisite for forensics and for KBV / data protection audits.

IDS/IPS With Suricata

OPNsense ships with Suricata as IDS/IPS. On the practice LAN and diagnostic VLAN interfaces it is worth deploying:

• ET Open Rules (Proofpoint Emerging Threats) as base rule set
• PT Research for medical specifics (PMS attacks are documented)
• Initially in IDS mode (alert only, no blocking) — otherwise false-positives risk practice downtime
• After one or two months of tuning, transition to IPS mode for selected high-confidence rules

Logs go to an external log server (e.g., Wazuh, Graylog, or the DATAZONE Control platform), not just locally on OPNsense — in an incident, logs must live outside the compromised host.

DNS Filtering as an Additional Layer

On OPNsense, Unbound DNS can be configured with a DNS blocklist plugin (e.g., via dnsbl_unbound). With this you can:

• Block malware domains (blocklists like OISD, StevenBlack, NextDNS)
• Filter phishing domains
• Reduce advertising networks on practice workstations (waiting-time effect)

Important: DNS filtering does not replace endpoint antivirus or EDR — it reduces the probability that a phishing URL ever reaches the browser.

VPN Access for Practice Owners

Doctors in private practice often also work from home — and access the practice management system. For this we recommend:

• WireGuard as VPN solution (integrated in OPNsense since 24.x)
• MFA via TOTP with built-in OPNsense module or external authenticator
• VPN endpoint in the practice LAN VLAN with restricted targets (PMS server, yes; diagnostic VLAN, no)
• VPN user certificates instead of username/password — easier to revoke on a compromised device

The KBV guideline requires “appropriate authentication” for remote access — MFA WireGuard fulfils this with comfortable margin.

Where OPNsense Ends: The TI Boundary

Here is the key clarification: The security of the TI connection itself is gematik-certified and not a firewall matter. The TI connector (hardware box or future “TI connector as a service”) encrypts and authenticates the connection to the German health network. OPNsense routes the connector packets — it cannot inspect, decrypt, or certificate-verify the TI connection.

What OPNsense contributes to TI security:

• Isolation of the TI network from the practice LAN — prevents lateral movement from a compromised practice PC to the connector
• Firewall rules at the TI boundary — only the connector-vendor-documented ports to the TI aggregator platform
• Logging of all connections to and from the connector — important for audit trails
• Anomaly detection via Suricata — unusual volumes or protocols on the TI link

What OPNsense does not deliver:

• No certificate verification of TI communication (that’s the connector’s job)
• No authentication of medical professional cards (SMC-B / HBA domain)
• No substitute for the gematik authorisation of the connector

Looking for an “all in one” box? It doesn’t exist in the TI environment. The TI connector is mandatory and must be approved; OPNsense sits in front of and around the connector.

Hardware Recommendation

For a standard medical practice with 5–20 staff, the following is usually sufficient:

• Small hardware appliance (e.g., Deciso DEC600 or similar) with 4–6 physical ports
• Managed switch (e.g., Mikrotik CRS, Netgear M4250, Ubiquiti USW-Pro) for VLAN tagging
• Wi-Fi access points with multi-SSID support (e.g., Ubiquiti, TP-Link Omada, Aruba Instant)

For higher performance (e.g., larger practices with multiple sites), pick a larger Deciso appliance or build on Intel hardware with OPNsense itself. At DATAZONE we plan this per practice during consultation — also because switch and Wi-Fi choices depend on the physical layout.

What We Recommend at DATAZONE

For a typical private practice this is the setup package:

1. OPNsense appliance with four-zone VLAN separation
2. Switch with VLAN tagging and PoE for Wi-Fi APs
3. Multi-SSID Wi-Fi: one SSID for practice devices (in practice VLAN), one for guests (in guest VLAN)
4. Suricata in IDS mode, monthly report to practice management
5. Unbound DNS with malware / phishing blocklist
6. WireGuard VPN with MFA for owner remote access
7. External logging (Wazuh, Graylog, or DATAZONE Control) — logs not only locally
8. Procedural documentation for KBV conformity — evidence document for data-protection / supervisory audits

Related DATAZONE articles:

• OPNsense vs. pfSense: comparison
• OPNsense WireGuard VPN setup
• Ransomware 2026: protection measures
• Sophos / Fortinet to OPNsense migration

Conclusion

OPNsense is a mature firewall platform with which medical practices can fulfil the KBV IT security guideline on the network side — without high-priced licensing and with all modern features (VLAN separation, Suricata, WireGuard, DNS filter). It is not a replacement for the TI connector and takes on no gematik-certified duties — but it closes the gap where an otherwise compromised practice LAN could reach directly through to TI.

Anyone running a practice network today on a simple DSL router typically has no VLAN separation, no logging, and no concrete way to pass an audit with evidence. That is exactly what OPNsense changes — and exactly what the KBV guideline demands.

Sources

• KBV: IT security guideline under § 75b SGB V
• gematik: TI connector documentation
• OPNsense: official documentation
• Suricata: open-source IDS documentation
• German BSI: cybersecurity in the medical practice