Port 8080, open to Meta and no one else
A client's new WhatsApp integration needs port 8080 open to the internet. When they opened that port last year for something else, malware attacks took their production server down. Because they already run an IOPSTOR HCI server, the fix needs no new hardware. The firewall runs as one more virtual machine on that server, and it lets port 8080 in from Meta's servers only.
Closed once, needed again
The client runs its production on an IOPSTOR Hyper Converged Media server: one box holding all of its virtual machines (VMs).
Last year the client opened port 8080 on their internet router themselves, for a different purpose, and forwarded it straight to the production server with no limit on who could connect. The server received a large number of malware attacks through it and went down. That use was not important enough to be worth the risk, so they closed the port permanently.
Now they need port 8080 for a new reason. Their WhatsApp integration runs on the same server and only works on that port. WhatsApp delivers incoming messages, read receipts and delivery updates by having Meta's servers connect in to the application. These calls are called webhooks, and they need port 8080 reachable from the internet. Without them the application can send messages but never hears anything back.
So they asked us to open port 8080 again, this time without the attacks and without any risk to production.
What it had to do
- Port 8080 exactly. The application cannot use any other port.
- Proper safety measures. No repeat of the attacks, and no risk to the production server.
- Cheap and future-proof, on the hardware the client already has.
A firewall inside the server they already own
Until now, the ISP's router did the routing and address translation, and nothing stood between the internet and the production VMs. We add a firewall as one more VM on the IOPSTOR HCI server.
The ISP switches its router to bridge mode, so it passes the line straight through and the firewall holds the static public IP itself. The firewall becomes the single gateway for every VM on the server, not only the WhatsApp application. That means one device to manage, and no double address translation, where two routers both rewrite addresses and every port forward has to be set up twice.
The firewall VM has two virtual network cards: one on the internet side and one on the side of the production VMs. Each sits on its own virtual network, so no traffic can slip past the firewall, and we test that from outside before go-live.
WHY ALREADY OWNING IOPSTOR HCI PAID OFF
- No new hardware to buy. The firewall is one more VM on the server the client already runs, using capacity it already had.
- No licence fee for the firewall software.
- Room to grow. Rules for other services can be added to the same firewall later without changing the design.
Who gets in?
- Port 8080, from Meta only. Connections on port 8080 are accepted only from Meta's published address ranges, and they go to the WhatsApp VM and nowhere else.
- Everything else is blocked and logged. To the rest of the internet, port 8080 looks closed, and every attempt is recorded.
- Outbound stays open. The VMs can reach whatever they need, so no application breaks. This can be tightened later without touching the inbound rules.
| The firewall | Checks who is connecting and where to. The source must be one of Meta's addresses, and the destination must be port 8080 on the WhatsApp VM. It does not read the messages. |
|---|---|
| The application | Checks what is being sent. Every webhook carries a verification token that the application confirms before it acts on the request. |
Keeping Meta's list current
Meta does not publish a list of addresses for WhatsApp alone. Its WhatsApp documentation points to every address range Meta's network announces, which covers Facebook, Instagram and WhatsApp together. On 23 September 2026 that came to 433 IPv4 routes, which combine into 23 address blocks.
Meta says it changes these addresses from time to time, and an out-of-date list would quietly break the integration. So the firewall reloads the list on a schedule from a file we regenerate, and we watch the block log for refused connections from new Meta addresses.
Why not keep the port closed?
We could block every incoming connection. It is the simplest possible rule set, and nothing from the internet could reach production. But incoming messages, read receipts and delivery updates would never arrive, and the integration needs them. Letting Meta in, and only Meta, keeps the integration whole.
Need a port open for one service, without opening it to the whole internet?
Talk to the IOPSTOR team.