When you’re troubleshooting under pressure, especially from console-only access, the quality of your questions matters more than the speed of your answers. This post shows a structured reverse‑prompting method:

1. Interview first to reconstruct the best prompt
2. Execute a deterministic troubleshooting plan
3. Capture a reusable prompt you can paste next time

 Why This Matters (and Who This is For) 

If you’ve ever been dropped into a production issue with console‑only access, partial information, and someone asking, “Why isn’t this working?” this post is for you. 

This isn’t a theory piece about prompt engineering. It’s a field-tested troubleshooting accelerator designed for: 

• Infrastructure and backup engineers supporting Veeam across VPNs 

• MSPs troubleshooting customer environments they don’t fully control 

• On‑call admins under time pressure with limited visibility 

• Anyone who’s tired of jumping straight to fixes without first knowing where the failure is actually located 

The core problem this blog addresses isn’t lack of knowledge, it’s lack of signal. 

Reverse prompting forces you to slow down just enough to: 

• Eliminate guesswork 

• Ask only the questions that change outcomes 

• Produce a repeatable troubleshooting path you can reuse under pressure

The result: fewer rabbit holes, cleaner escalation notes, and faster root‑cause isolation.  

Scenario (sanitized)  

An Ubuntu-based Veeam proxy at a DR site (192.168.1.x) cannot reach the primary site’s Veeam Backup & Replication server (192.168.101.x). A site-to-site VPN exists and ICMP (ping) is expected to work, but neither ping nor TCP connectivity succeeds. Ubuntu host firewall appears open (UFW inactive; iptables policies accept).  

Copilot vs Engineer: Key Moments  

ENGINEER: You are my ‘Reverse‑Prompt Architect + Doer.’ Mission: troubleshoot connectivity from an Ubuntu Veeam proxy at a DR site back to the main Veeam server. Interview first, then execute, then produce a GOLD PROMPT.  

COPILOT: I’ll ask high-impact questions first and won’t jump to solutions until required context is collected.  

ENGINEER: We are connecting from an Ubuntu Veeam proxy at a DR site to the main Veeam server. It does not ping or connect. 192.168.1.x to 192.168.101.x. Console-only access; can’t paste full outputs. Proxy can reach the internet.  

COPILOT: Because both endpoints are private RFC1918 subnets, ‘internet works’ doesn’t prove the VPN route exists. Confirm routing, Phase-2 selectors, NAT exemption, and firewall policy across the tunnel.   

What Reverse Prompting Actually Changes in Practice 

Most troubleshooting fails before the first command is run at the question‑asking stage. 

Reverse prompting flips the usual flow: 

Instead of: 

“Here’s the error, what’s wrong?” 

You get: 

“What must be true for this to work, and which of those things haven’t been proven yet?” 

In this example: 

• “Internet access works” is treated as a non‑signal 

• “ICMP failure” is framed as a routing or policy problem, not a host firewall issue 

• Copilot is explicitly prevented from jumping to fixes until routing, tunnel selectors, and port reachability are all validated 

This makes the method reliable under stress: constrain the problem space instead of expanding it.

Decision Tree (minimal typing, maximum signal)  

Step 1 — Prove Linux routing  

ip -br a  

ip r  

ip r get 192.168.101.10  

Step 2 — Identify where packets die  

ping -c 4 192.168.101.10  

traceroute -n 192.168.101.10 2>/dev/null || tracepath 192.168.101.10  

Step 3 — Prove required TCP ports  

VBR=192.168.101.10  

nc -vz $VBR 6162  

nc -vz $VBR 2500  

nc -vz $VBR 443  

nc -vz $VBR 10006 

How This Helps You Next Time (Not Just This Time) 

The real win isn’t that this specific VPN issue gets solved. The win is that you walk away with: 

• A copy‑paste decision tree that works for any private‑to‑private connectivity issue 

• A validated port checklist for Veeam components (not assumptions) 

• A GOLD PROMPT you can reuse for:  

• • New environments 

• • Different vendors 

• • Junior engineer handoffs 

• • Escalations where clarity matters more than speed 

Next time someone says “the backup repo can’t connect,” you don’t start from zero, you already have a structure in place. 

Appendix A — FULL PROMPT (verbatim, no shortening)  

Here’s the complete reusable prompt template, intentionally unabridged so you can copy/paste as-is:  

You are my “Reverse-Prompt Architect + Doer.”  

Mission: troubleshoot connectivity on an Ubuntu server to offsite Veeam server.  

1. Interview me to reconstruct the best possible prompt (reverse prompting)  
2. Then, execute it to produce the final deliverable  
3. Finally, output the reusable “GOLD PROMPT” I can copy next time 

Operating Rules (follow in order):  

First, ask me up to 8 high-impact questions that would materially change the answer. Do not provide output until all are done.

• If my request includes a desired example output, analyze it first and ask fewer questions. 
• If something is missing but can be inferred safely, infer it, then clearly mark it as an assumption. 

Next, propose 2–3 candidate prompt drafts (short, medium, strict) and explain what each optimizes 

Choose the best draft, then run it and deliver the final output. 

Provide a “Quality Check” section: 

• What you assumed 
• What you could not know from my inputs 
• What evidence/sources you used (and what you did not use) 
• How confident you are and why 

Provide the final reusable GOLD PROMPT (the one you used) with placeholders. 

Prompt Blueprint (use this structure in your final GOLD PROMPT):  

• Goal: What to produce (exact deliverable) 
• Context: Why / who / constraints / background 
• Source(s): What data to use (i.e. files, emails, meetings, chats, transcripts, web, or “only my pasted text”) 
• Expectations: Format, depth, tone, length, and acceptance criteria 

My Request: (what I want you to reverse-engineer and complete)  

Describe the task in 1-3 sentences.

Desired Output (reverse anchor — optional but powerful):  

• Audience
• Tone
• Length
• Format (bullets/table/steps/code/etc.)
• MUST include
• MUST avoid
• Example of what “good” looks like (paste sample output if available)

Paste sample or leave blank.

Scope & Sources:  

• Time frame if relevant
• Preferred sources (choose any)
  • My pasted text only 
  • My org files/docs 
  • Emails 
  • Teams chats/messages 
  • Meetings + transcripts 
  • Web sources (cite links)  

• If you don’t have access to a source, tell me exactly what to paste or provide. 

Constraints & Preferences:  

• Depth (choose one):
  • executive summary 
  • detailed 
  • exhaustive  
• Output style (choose one):
  • concise bullets 
  • narrative 
  • SOP 
  • checklist 
  • decision memo  
• If code/scripts are involved: 
  •  Provide a full working script output, don’t use partial snippets. Then run debugging, Quality Assurance, and review prior to presenting final working script. Be sure to include revision number, but run tests in python to validate first.
  •  Include validation steps and “debug view” reasoning  
  •  Assume PowerShell must run in PS7/ISE and may not be runnable due to security policy  
  •  Include safety notes and rollback guidance  

Now, you’re ready to ask the highest-impact questions first.  

Step A: Ask 8 high impact questions (answer these first; then draft prompts + execute).

1. What exact Veeam workflow are we troubleshooting? 

• • Pick one (or describe):  
  •  Veeam Backup & Replication (Windows) connecting to a Linux Hardened Repo (Ubuntu)  
  •  Veeam Agent for Linux on Ubuntu backing up to a Veeam server/repo offsite  
  •  Veeam Cloud Connect (Service Provider / tenant) from your site to offsite Cloud Connect Gateway  
  •  Something else (describe in one sentence)

2. Where does it fail and what is the exact error text? 
   • Paste the exact error from Veeam (job/session log) and/or from Ubuntu (terminal output). 
   • If you have multiple, paste the most recent failure first.  

3. What are the endpoints (sanitized is fine) and network path? 

• •  Ubuntu server IP/subnet + default gateway (or just “10.x/24 via 10.x.1.1”)  
  •  Offsite Veeam side IP/FQDN (and whether it’s public IP, behind NAT, or reachable only via VPN)  
  •  Is there site to site VPN, MPLS, SD WAN, or just Internet?  

4. Which protocol/ports should be working for this connection? (If you don’t know, tell me what repo type you configured.) 

• • Examples: SSH/22, SMB/445, NFS/2049, Veeam Data Mover ports, Cloud Connect ports, etc.  
  • If you configured a Linux Repository in VBR, tell me whether it’s single use credentials / hardened and if you enabled “use sudo” (yes/no).    

5. What changed right before it broke? 

• • Choose all that apply and add detail: firewall change, ISP/public IP change, DNS change, Veeam upgrade, Ubuntu updates, certificate/MFA changes, routing/VPN change, NAT rule change

6. Run these 6 commands on Ubuntu and paste outputs (redact public IPs if needed):

• • ip a  
  • ip r  
  • resolvectl status 2>/dev/null || cat /etc/resolv.conf  
  • timedatectl  
  • sudo ufw status verbose 2>/dev/null || sudo iptables -S  
  • sudo ss -tulpn | head -n 50  
  • (If you can’t run sudo, say so)  

8. Connectivity proof from Ubuntu to offsite target (paste outputs): 
   • Replace TARGET with the offsite Veeam hostname/IP and run what applies:  
   • ping -c 4 TARGET  
   • traceroute -n TARGET 2>/dev/null || tracepath TARGET  
   • nc -vz TARGET 22  
   • nc -vz TARGET 443  
   • nc -vz TARGET 2500  
   • If your environment blocks ping/traceroute, tell me what’s blocked. 

9. Enter desired deliverable + constraints: 

• • Depth: detailed or exhaustive? 
  • Output style: SOP/checklist/decision tree
  •  Do you want copy/paste scripts (bash + optional PowerShell for Veeam server checks)
  • Any “must avoid” actions (e.g., cannot reboot, cannot change firewall, cannot disable UFW)

Reply with answers, even partial answers are helpful.

Once A is answered, move to:  

Step B: 2 to 3 prompt drafts

Step C: Execute the best one to produce a complete troubleshooting runbook to give commands, interpretation, and next actions.

Now you can give your final  difficulty and effort quality check and you have your GOLD PROMPT.  

Reverse prompting transforms AI from a search tool into a troubleshooting framework, helping IT professionals solve complex infrastructure and networking challenges faster and more effectively.