Network segmentation on-prem and in the cloud: VLANs, firewalls, security groups and best practices

Network segmentation is one of the most effective measures to reduce attack surface, limit the spread of incidents and cleanly separate operational domains. The word Network segmentation denotes the deliberate construction of logical or physical zones within the network in which devices, services and users are only allowed to communicate with each other in a controlled manner. In enterprises this typically means a combination of VLANs (Virtual LANs), router/Layer-3 zones, firewalls as well as cloud-specific mechanisms such as Security Groups or Network ACLs. This article explains in practical terms how to design, implement, test and operate segmentation on-prem and in the cloud.

Key terms — concise

Before configuration and rollout, briefly define the most important terms in a single paragraph:

• VLAN (Virtual Local Area Network): Logical separation at Layer-2 (data link). VLANs isolate broadcast domains on switch ports and require routing (Layer-3) for inter-VLAN communication.
• Firewall: Device or software that allows or denies traffic according to rules. Can be stateful (connection-oriented) or stateless.
• Security Group: Cloud construct (e.g. AWS/Azure) for grouping rules; usually stateful and bound to instances.
• Network ACL: Cloud or on-prem rule set that typically operates stateless and applies at subnet/network level.
• Microsegmentation: Fine-grained control of connections down to process or host level (e.g. via host firewall, iptables/nftables or eBPF policies).

Network segmentation: fundamental principles and objectives

Good segmentation follows clear operational objectives: limit attack propagation, isolate sensitive data, improve distribution of network load, and separate operational responsibilities. The principles are:

• Least privilege: Permit only the minimum required connections.
• Trust zoning: Structure network areas by trust level (e.g. DMZ, App-Tier, DB-Tier).
• Logging and Monitoring: All zone boundaries should be logged and traceable.
• Automation: Policies as code (IaC), review pipelines and test automation prevent drift and misconfiguration.

On-Prem: Practically designing and operating VLANs

VLANs are the classic method for on-prem segmentation. A VLAN groups ports together and forms its own broadcast domain; routing between VLANs is performed by a router or L3 switch (inter-VLAN routing).

Prerequisites and planning

Important prerequisites: trunk-capable switches (IEEE 802.1Q) for VLAN pass-through, a consistent IP addressing plan, documented VLAN IDs and naming conventions, and routing policy on the L3 gateway. Without a clean IP plan you quickly encounter overlap, misplaced gateways or broadcast storms.

Example: Create a VLAN on a switch (Cisco IOS)

Configuration of a trunk port and an access port:

configure terminal
vlan 10
 name VLAN-APP
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 10
end
write memory

Why this works: A trunk carries multiple VLANs between switches; access ports are members of exactly one VLAN. When it fails: missing trunk configuration on the peer, mismatched native VLANs or MTU issues (consider voice/VLAN tagging).

Linux‑Host as router / VLAN interface

For small sites or test environments, a Linux gateway can handle VLAN interfaces directly:

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev eth0.10
ip link set eth0.10 up
sysctl -w net.ipv4.ip_forward=1

Risk: performance limits and lack of hardware offload support on commodity hosts. For production workloads, use L3 switches or dedicated routers/firewalls.

Cloud‑Konzepte: Security Groups, NACLs und Routing

In public clouds like AWS, Azure or Google Cloud there are different primitive building blocks. Security Groups (SG) are typical instance‑bound, usually stateful rules. Network ACLs (NACL) operate at the subnet level and are often stateless, i.e. they require separate rules for in/out.

Stateful vs. stateless, briefly explained

Stateful means the firewall keeps track of connections (e.g. an allowed TCP connection then permits return traffic). Stateless treats each direction independently and therefore requires more detailed rules. In AWS, SGs are stateful; NACLs are stateless. In Azure, NSGs (Network Security Groups) are stateful.

Example: Create a Security Group (AWS CLI)

aws ec2 create-security-group --group-name zammad-app-sg --description "Zammad App SG" --vpc-id vpc-123abc
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 5432 --source-group sg-0dbonly

The last rule shows an important pattern: allow the DB port (5432) only from the application SG. This prevents direct Internet access to databases.

Using firewalls strategically: zones, rules, logging

Segmentation works best with clear zones: perimeter/DMZ, app tier, database tier, management. Firewalls enforce policy at zone boundaries. Key points:

• Rules by function, not by IP: group services, not individual hosts.
• Default‑deny: perimeter rule set should be denying by default; only explicitly allowed flows are permitted.
• Protocol and port restriction: open only required protocols (e.g. HTTPS instead of HTTP, application proxies, mTLS).
• Logging and retention: collect firewall logs centrally (SIEM) to detect anomalies.

Example: minimal nftables input chain (host firewall)

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0 ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input tcp dport 22 ct state new limit rate 10/second accept
nft add rule inet filter input drop

Why this works: simple default‑deny strategy with permission for established connections and necessary services. When it fails: missing logging rules, leaving the console (SSH) too open, or placing rules in the wrong order.

Best‑Practices: Design, Automatisierung und Betrieb

Concrete guidelines that repeatedly make the difference in projects:

1. Tagging‑ und Namenskonventionen: Use consistent tags in the cloud (e.g. environment, role, owner) and a VLAN naming structure on‑prem (e.g. VLAN-APP-10).
2. Policy as Code: Manage firewalls and Security Groups via IaC (Terraform, ARM, CloudFormation), including code review and testing.
3. Change‑Control: Every policy change goes through automated tests (Connectivity‑Smoke, Regression) and includes a rollback option.
4. Least‑Privilege und explizite Regeln: No open 0.0.0.0/0 rules except when truly necessary.
5. Monitoring & Alerts: Anomalies such as sudden peaks in East‑West‑Traffic or unusual port scans raise alerts.
6. Dokumentation: Keep IP plan, VLAN map, firewall matrix (Who may reach whom?) up to date.

Migrations- und Rollout‑Plan: Schritt für Schritt

When migrating from flat networks to segmented environments, a guaranteed rollback path is recommended. An exemplary sequence:

1. Analysis: Capture current flows with NetFlow/sFlow, tcpdump and record service dependencies.
2. Design: Create a zones and services map, document ports and endpoints.
3. Automated rollout: Generate IaC templates, dry‑run, review and staging deploy.
4. Canary: Apply segmentation to a small subset and observe.
5. Production rollout: Phased cutover with monitoring and emergency rollback.

Wichtige Testbefehle

Use these commands systematically to validate connectivity and rules:

# Verbindungstest TCP (Netcat)
nc -vz 192.168.10.5 5432

# Paketmitschnitt (z. B. DB‑Traffic)
tcpdump -i eth0 -n 'host 192.168.10.5 and port 5432'

# Firewall‑Rules anzeigen
nft list ruleset

# Route/Next‑Hop prüfen
ip route show

# Traceroute für Pfaddiagnose
traceroute -n 10.0.0.5

# HTTP‑Check
curl -v --connect-timeout 5 https://app.example.local/health

Monitoring, Logging und Drift‑Detection

Segmentation is only as good as its monitoring. Key requirements:

• Flow‑Logging: Enable NetFlow/sFlow on switches and VPC Flow Logs in clouds to analyze East‑West‑Traffic.
• Firewall Logs: Send structured logs (JSON) to a SIEM to enable correlations.
• Drift Detection: Continuously compare current configs with IaC state (e.g. Terraform plan in CI). Cloud tools like AWS Config or Azure Policy can report unmanaged changes.

Example: Enable VPC Flow Logs and a simple CloudWatch Logs Insights query for unusual source IPs:

# VPC Flow Logs (Kurzbefehls-Beispiel - CLI)
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-123abc --traffic-type ALL --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::123456:role/flowlogs-role

# CloudWatch Logs Insights Beispielabfrage
fields @timestamp, srcAddr, dstAddr, action | filter action = 'REJECT' | stats count() by srcAddr | sort @timestamp desc

Performance, MTU und Latenz beachten

Segmentation can have side effects on latency and MTU. Tagged frames increase packet size; with VPNs or overlay networks (e.g. VXLAN) headers add up. Check MTU settings along the path and measure latency/throughput before and after changes.

Measurement tools and example commands:

# MTU prüfen
ip link show dev eth0

# Latenz und Durchsatz messen (iperf3)
iperf3 -c 10.0.0.5 -p 5201 --parallel 4 --time 30

Microsegmentierung, Host‑Firewall und eBPF

If Layer‑2/3 are not sufficient or multi‑tenant operation is required, microsegmentation helps: host‑based via nftables/iptables, agent‑based (e.g. area‑specific agents) or modern approaches with eBPF, which brings high‑performance packet filtering into the kernel. Advantage: very fine‑grained control; disadvantage: higher complexity and operational overhead.

Zammad‑specific operational and troubleshooting additions

For Zammad installations, refine your segmentation based on the following points:

• List of minimum ports: Web (80/443), Postgres (5432), Elasticsearch (9200), Redis (6379).
• Securing admin paths: SSH/management only in the management zone, 2FA for web admin accounts and IP restrictions for admin panels.
• Health checks and playbooks: simple health endpoints check web, DB connections, index health of Elasticsearch.

Troubleshooting sequence for reachability issues:

1. Check firewalls/security groups (logs for ACCEPT/REJECT).
2. Test network path (traceroute, tcpdump on the app host).
3. Check application logs (Zammad Rails Logs, Postgres Logs, Elasticsearch Logs).
4. Rollback to the previous Security‑Group/Firewall version if connectivity was demonstrably caused by a policy.

Example: Terraform‑snippet for Security Group (Cloud‑Policy as Code)

resource "aws_security_group" "zammad_app" {
  name        = "zammad_app_sg"
  description = "App SG für Zammad"
  vpc_id      = var.vpc_id

  ingress {
    description = "Web"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description     = "DB Access aus App SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.zammad_db.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "zammad_app_sg"
  }
}

Important: Set up versioning, CI checks (terraform plan) and automated approvals to ensure drift‑free deployments.

Operational runbook and rollback strategy

A precise runbook reduces stress during an incident. Key points:

• Quick test commands (connectivity, logs, health checks).
• Snapshot/backup IDs and timestamps documented.
• Rollback command or IaC revert playbook, including contacts and escalation chain.
• Communication plan: status updates to affected teams and maintenance windows.

Checklist before go‑live

• IP plan and VLAN map finalized and distributed to the team.
• IaC templates created, review completed, automated tests green.
• Backup/snapshot created before rollout.
• Monitoring (flows, firewall logs) active and alert thresholds configured.
• Rollback playbook documented and tested.
• Documentation of rules and responsibilities in place.

Conclusion

Network segmentation is an ongoing, not a one-time, project. The best approach combines solid design principles (Least‑Privilege, Trust Zoning), automation (Policy as Code) and a clear test and rollback procedure. On‑prem‑VLANs and Cloud‑Security‑Groups often complement each other and must be understood in practice as a single, coherent policy set. For process-oriented digital enterprise solutions like Zammad, clean segmentation pays off: reduced attack surface, clear responsibilities and reproducible rollouts. Start small (Canary), measure flows and automate policy distribution — this is how segmentation projects become manageable and sustainable.