A representative AI-generated pfSense NAT config of the kind pasted in for "quick help." The port forward works perfectly — and it also exposes RDP to the entire internet, because the autogenerated firewall rule did exactly what it was told. The line-by-line teardown and the config that should have shipped instead.
# "how do I RDP into the new jump box from home?" → an AI → pasted into pfSense NAT ▸ Port Forward Interface: WAN Source: any ← the entire internet Destination: WAN address : 3389 Redirect to: 192.168.10.10 : 3389 (RDP) Filter rule: Add associated rule → WAN any → 192.168.10.10:3389 PASS ────────────────────────────────────────────────────────────── verdict: it "works" · and it's a ransomware on-ramp · 2 high · 2 med
Ask an AI “how do I RDP into my jump box from home?” and it will give you a pfSense port forward that does precisely that. It will also, by default, open Remote Desktop to all four billion IPv4 addresses on the internet — because you asked it to forward the port, and “from home” was context it had no way to enforce. The config is not wrong in the sense of “broken.” It works on the first try. It’s wrong in the sense of “this is how the ransomware gets in,” and the model will never say so unless you make it.
This is AI Configs Reviewed #02. The config below is a representative composite of the pfSense NAT setups that get pasted around for quick help — assembled to reproduce the real exposure pattern, not lifted from anyone’s post.
The ask was modest: let one admin RDP to an internal jump box, 192.168.10.10, from home. The AI returned a single pfSense Port Forward:
NAT ▸ Port Forward ▸ Edit
Interface: WAN
Address Family: IPv4
Protocol: TCP
Source: any ← left at the default
Destination: WAN address
Destination port range: 3389 (MS RDP)
Redirect target IP: 192.168.10.10
Redirect target port: 3389
Filter rule association: Add associated filter ruleIt works immediately. The admin RDPs in from home and closes the ticket. So does everyone else on the internet who finds it — which, for an exposed 3389, takes minutes.
| # | Severity | Finding |
|---|---|---|
| 1 | 🔴 High | Source: any — RDP/3389 is open to the entire internet |
| 2 | 🔴 High | RDP is exposed directly at all; it belongs behind a VPN |
| 3 | 🟠 Med | No logging on the rule — the brute-force attempts are invisible |
| 4 | 🟠 Med | No description — nobody will know why this rule exists in six months |
Source: any is the whole incidentThe Port Forward’s source was left at its default, any. That single field is the difference between “my admin can reach RDP” and “every scanner on the internet can reach RDP.” Exposed 3389 is one of the most reliably exploited entry points there is — automated brute-force and credential-stuffing find it within minutes of exposure, and it has a history of wormable pre-auth vulnerabilities (BlueKeep being the famous one). The associated filter rule pfSense auto-created reads WAN: any → 192.168.10.10:3389 PASS, faithfully encoding the exposure into the firewall.
(Note the pfSense quirk, same as in the ASA migration: that auto-rule’s destination is the internal 192.168.10.10, not the WAN address — correct, just inside-out from what people expect.)
Even scoped to one IP, publishing RDP straight to the internet is the wrong shape. Home IPs change, allowlists rot, and a single exposed Remote Desktop endpoint is a single credential away from full interactive access to an internal host. Remote access wants a layer in front of it.
The associated rule has logging off. So when the internet starts hammering 3389, there’s no record of it — no failed-login spike, no source-IP pattern, nothing until something succeeds. You can’t alert on what you don’t log.
The rule has no description. Like the stale hosts entry from Failure #02, an undocumented “temporary” exposure becomes a permanent one — nobody remembers why it’s there, so nobody dares remove it.
Run the proposed NAT change through this before it’s applied. Keep it in your pack:
Audit this pfSense NAT port forward and its associated firewall rule for
security exposure. Here it is: [paste the port forward + the auto-created
rule]. The goal is: let ONE admin reach an internal host's RDP from home.
Check specifically for:
1. Is the Source restricted, or is it "any" (exposed to the whole internet)?
2. Is a high-risk service (RDP/3389, SMB/445, SSH, database ports, the
pfSense WebGUI) being published directly to WAN?
3. Is there a safer pattern (VPN) that meets the same goal?
4. Is logging enabled so attacks are visible?
For each issue: severity, the exact setting, and the fix.The line “is a high-risk service being published directly to WAN” is what flips the model from order-taker to reviewer. Asked to make the port forward, it makes it. Asked to audit it against a threat model, Claude flags the any source and recommends the VPN — the judgment the first prompt never invited.
The right answer isn’t a tighter port forward. It’s no port forward — put remote access behind a VPN and never expose RDP at all:
VPN ▸ WireGuard; OpenVPN is the equally valid alternative).192.168.10.10 only over the tunnel. The jump box is never reachable from the public internet; the admin connects to the VPN first, then RDPs across it.If — against this advice — a port forward is truly unavoidable, the minimum hardening is: set Source to an alias of known admin IPs (never any), enable logging on the rule, and add a description with the ticket number and owner. But the VPN is the answer, and it’s less work than the incident.
A port forward with Source: any to RDP isn’t a config — it’s an incident with a countdown. AI does exactly what you literally ask and supplies no threat model; put remote access behind a VPN and never publish 3389 to the internet.
ACR #03 — an AI-written Python script meant to add a firewall rule that, on its error path, disables the rule above it instead. It runs clean and reports success. We trace what it actually did.
— Subscribe to Packet Drop (newsletter form below) to get the next teardown when it ships.
— Want the audit prompts that catch these before they ship? Get the Prompt Pack — 60 production prompts for network admins, $29, lifetime updates.
Q: Is it safe to port forward RDP (port 3389) on pfSense?
A: No. Publishing RDP/3389 directly to the WAN exposes it to internet-wide scanning and automated brute-force, and it has a history of wormable pre-auth vulnerabilities. A port forward with Source set to "any" is the highest-risk version. The safe pattern is to put remote access behind a VPN (WireGuard or OpenVPN) and reach RDP only over the tunnel, so the jump box is never reachable from the public internet.
Q: How should I allow remote RDP access securely?
A: Run a VPN on the firewall (WireGuard or OpenVPN), expose only the VPN port on the WAN, and RDP to the internal host across the tunnel. Delete any direct 3389 port forward. If a port forward is genuinely unavoidable, restrict the Source to an alias of known admin IP addresses, enable logging on the rule, and document it — but a VPN is less work than the incident an exposed RDP invites.
Q: Why is exposing port 3389 to the internet dangerous?
A: Port 3389 (Microsoft RDP) is one of the most heavily scanned and exploited ports on the internet. An exposed endpoint faces continuous credential brute-force and stuffing, and RDP has had wormable pre-authentication vulnerabilities such as BlueKeep. A single weak or reused password on an exposed jump box can hand an attacker interactive access to an internal host — which is why RDP exposure is a leading ransomware entry vector.