Letting tripwires report across VLANs
If the honeypot lives on its own VLAN — which is the right place for it — then machines on your other VLANs can't reach it. That's the isolation working. But it silently breaks one thing:
A tripwire file opened on a PC in another VLAN cannot call home, so you get no alert. The bait looks planted and is actually inert.
This is the worst kind of failure: nothing errors, you simply never hear about an intrusion. Fix it with one narrow hole, not by joining the networks.
The rule, in words
Allow: other VLANs → HONEYPOT_IP → TCP 8000 only
Deny (keep denying): everything else in that direction, and everything in
the reverse direction.
Direction is the whole point. Letting a PC reach the beacon does not let the honeypot reach the PC — a stateful firewall permits the reply to an established connection without opening a path the other way. The honeypot must never be able to initiate into your real network; that rule stays untouched.
Only port 8000 (the beacon) is exposed. The decoy traps (SMB/RDP/FTP) stay sealed inside the honeypot VLAN, which is correct: an intruder should have to be on that segment to find them.
UniFi (UDM / UDM Pro / Dream Machine)
Settings → Security → Firewall Rules → Create New Rule
| Field | Value |
|---|---|
| Type | LAN In |
| Name | Allow tripwire beacon to honeypot |
| Action | Accept |
| Protocol | TCP |
| Source | Network(s) where your PCs live — e.g. 10.3.1.0/24, 10.3.10.0/24 |
| Destination | Port/IP Group → address 10.3.20.29, port 8000 |
| Rule index | Above any existing inter-VLAN block rule |
Rule order matters: UniFi evaluates top-down and stops at the first match. If your "block inter-VLAN" rule sits above this one, this never fires.
Leave the existing block rule in place — this sits above it as a single exception.
pfSense / OPNsense
On the interface for the VLAN your PCs are on (e.g. LAN), add a pass rule
above the inter-VLAN block:
Action: Pass
Interface: LAN (the source VLAN, not the honeypot one)
Protocol: TCP
Source: LAN net
Destination: 10.3.20.29
Dest port: 8000
Description: Tripwire beacon to honeypot
Plain nftables (if the honeypot host is the boundary)
# allow only the beacon inbound from other VLANs
add rule inet filter input ip saddr { 10.3.1.0/24, 10.3.10.0/24 } \
tcp dport 8000 ct state new,established accept
# the reverse direction stays denied — the honeypot must never initiate out
add rule inet filter output ip daddr { 10.3.1.0/24, 10.3.10.0/24 } \
ct state new drop
Verify it — both halves
From a PC on the other VLAN, the beacon must answer:
curl -s -o /dev/null -w "%{http_code}\n" http://10.3.20.29:8000/health # expect 200
And the traps must still be unreachable from there:
nc -z -w2 10.3.20.29 445 && echo "SMB reachable — RULE TOO WIDE" || echo "SMB sealed (correct)"
nc -z -w2 10.3.20.29 3389 && echo "RDP reachable — RULE TOO WIDE" || echo "RDP sealed (correct)"
Then the real test: plant a tripwire on that PC, open it, and confirm the alert arrives. A rule that looks right but doesn't alert is worth nothing.
Alternative: skip the firewall entirely
If every machine that will hold tripwires is on your admin VPN (Tailscale), set the beacon to the tailnet name instead and change no firewall at all:
TRIPWIRE_BASE_URL=https://<host>.<tailnet>.ts.net
Cleaner, and it works off-site too. It only covers machines on the VPN — a random family PC won't be, which is exactly where the firewall rule earns its place.
Don't do this
- Don't allow all ports to the honeypot from other VLANs. The traps are meant to be found only from inside the honeypot segment; exposing SMB/RDP network-wide turns a controlled decoy into an actual attack surface.
- Don't allow the honeypot outbound into your VLANs to "make it work". That is the exact path a compromised decoy would use, and it's the one thing the whole design exists to prevent.
- Don't put the honeypot on the main LAN to avoid the rule. Then a compromised decoy is already inside.