Every VMware blog right now is talking about VCF 9.1. Fair enough, it’s a big release. But there’s a tool that’s been quietly sitting in Broadcom’s repo for over a year that almost nobody covers, and it deserves a lot more attention: VMFlowgen.
It’s free. It’s official (built by VMware/Broadcom engineering). And it solves a real problem: how do you actually test whether your NSX security policies work, without building a fake “attack” environment from scratch every time?
I’m splitting this into two posts. This one is the introduction: what VMFlowgen is, how it’s built, and how to get it running. The next one will be a full demo: a realistic small-business topology, an attack, and how NSX (DFW, IDS/IPS, distributed Malware Prevention) stops it, step by step, in a way anyone can reproduce.
Why this tool matters#
If you’ve ever tried to demo or test NSX security features (Distributed Firewall, IDS/IPS, distributed Malware Prevention, Security Intelligence), you know the problem: you need traffic. Real traffic, with real application behavior, real malware-like payloads, and a repeatable way to trigger events on demand.
VMware does provide official demo environments for this. They work, but they’re built for large-scale enterprise showcases. Heavy, complex, and not something you can spin up on a laptop to check “does my rule actually block this?” in five minutes.
VMFlowgen is the opposite. It’s a lightweight appliance that generates realistic network flows between virtual machines (HTTP, TLS, DNS, SMB, LDAP, and 1000+ IDS-triggering payloads) without needing any actual malicious code or a full enterprise lab. And because it’s free and self-contained, you can validate your own NSX configuration on your own homelab or test environment, instead of just trusting a vendor slide.
What VMFlowgen actually is#
At its core, VMFlowgen has two parts:
- A controller, the central management and control plane (deployed as an OVA appliance)
- A fabric of lightweight VMs, deployed via vSphere Instant Clone, generating flows between each other
The clever part is how it deploys those VMs. For each vSphere cluster, VMFlowgen deploys one VM, freezes it (makes memory and disk read-only), and then uses Instant Clone to spin up all the other VMs from that frozen source. This means:
- Memory pages are shared across clones, so RAM usage drops dramatically
- Storage uses delta disks, so disk usage drops dramatically too
- Deployment is fast, a 100-VM fabric can come up in seconds
The controller talks to VMs exclusively through the vCenter Guest Operations API, not directly. That means there is zero control-plane traffic on the network itself, so the VM network can be fully isolated. This matters a lot when you’re intentionally testing malware-like payloads: the “attack” traffic is real network traffic between VMs, but the orchestration never touches that network.
What kind of traffic it can generate#
VMFlowgen ships with a library of ready-made payloads, organized into categories:
- AppID payloads: lightweight traffic for 12 common protocols (DNS, HTTP, Kerberos, LDAP, MySQL, NTP, RDP, SMB, SSH v2, TELNET, TLS 1.2, TLS 1.3). Useful for showing NSX’s Layer-7 Deep Packet Inspection in action.
- IDS payloads: over 1,000 payloads reverse-engineered from real IDS signatures, designed to trigger IDPS detection events.
- Malware payloads: simulated malware downloads over HTTP/HTTPS. The public release only ships the EICAR test file (the industry-standard harmless “this is a virus” test string), not real malware.
- NTA payloads: dynamically generated traffic patterns for Network Traffic Analysis, things like DGA-style DNS lookups, port sweeps, upload/download anomalies, and protocol-on-wrong-port mismatches.
Every flow is bidirectional and verified. VMFlowgen checks that what was sent is what arrives at the other end. If NSX blocks or alters a payload, say an IDS rule drops a malicious request, or Malware Prevention refuses to write a downloaded file to disk, VMFlowgen marks that flow as FAILED. This is what makes it genuinely useful for testing, not just for pretty diagrams: you get a pass/fail result for every single flow.
Core building blocks#
A few concepts to understand before setting it up:
Topologies. Since v0.7, VMFlowgen supports multiple independent topologies. Think of each one as a saved lab scenario you can switch between.
VMs and Flows. You create VMs (Linux, based on a bundled Ubuntu 22.04 OVA, or Windows using your own frozen VM), then draw flows between them: source, destination, protocol, port, and optionally a specific payload from the library.
Campaigns. A campaign is an ordered sequence of on-demand flows. Each flow only runs if the previous one succeeded, which is exactly how you demonstrate that NSX stopped the attack at step 3, so steps 4 and 5 never happened.
Tags and NSX API calls. VMFlowgen can push VM tags directly into NSX and even fire custom NSX API calls before or after deployment, handy for auto-creating the security groups and policies your demo needs.
Certificates and TLS. You can generate custom certificates and encrypt flows with TLS, useful for showing how Malware Prevention and Security Intelligence behave against encrypted channels, not just plaintext.
Why it’s underrated#
VMFlowgen solves a problem that a huge number of VMware admins actually have: “I configured NSX Distributed Firewall, IDS/IPS and Malware Prevention, but how do I know it’s actually working, without waiting for a real incident?”
Instead of trusting a vendor demo video, you generate your own traffic, against your own policies, on your own infrastructure, and get an objective pass/fail result per flow. It’s free, it’s self-contained, and unlike most enterprise security tooling, it doesn’t require a six-figure lab to try out.
What’s next#
Next up: setting up VMFlowgen and building a small, realistic test environment to actually run an attack and see NSX defend against it.