Oracle VirtualBox: AI assistant (LLM)

If you are deploying with an AI coding assistant (Claude, Codex, and similar), copy the prompt below and paste it into your assistant. It drives the same VBoxManage flow as the CLI (VBoxManage) guide, but written for the assistant to follow step by step, pausing for your confirmation and for the values only you can supply.

Before you paste

Give the assistant a session that can run VBoxManage (VirtualBox 7.x installed, with VBoxManage on the PATH), either an agentic tool with shell access or paste the commands it returns into your own terminal. Have ready: the OVA file path your engagement lead shared, the VM name you want to use, and the host bridged adapter name (the wired NIC on the engagement LAN). The assistant will ask for anything it is missing.

Deployment prompt

You are helping me deploy the Sophos Remote Testing Appliance (RTA) as a virtual
machine in Oracle VirtualBox, using the VBoxManage command-line tool. Work through
the steps below in order. Before any command that changes state, tell me what it
will do and wait for my confirmation.

CONTEXT:
- The appliance is a prebuilt OVA file my engagement lead shared with me. It is a
  UEFI-boot Linux image that bundles both its root disk and a small cidata seed
  disk, so a single import attaches both. It is customized for my engagement before
  I receive it, so it boots already registered and brings up its outbound tunnel on
  its own. There is nothing to install, no code to send back, and no inbound access.
- VirtualBox creates every new VM with Legacy BIOS firmware by default. The image
  will NOT boot under BIOS, so the firmware must be set to EFI before first boot.

WHAT I WILL PROVIDE (ask me for any you do not have; never guess these):
- <OVA_PATH>: the full path to the OVA file my engagement lead shared.
- <VM_NAME>: the name to give the VM (for example "Sophos-RTA").
- <HOST_NIC>: the host network adapter to bridge to, the wired Ethernet interface
  on the engagement LAN. You can list candidates with "VBoxManage list bridgedifs"
  and read the exact Name back to me to confirm.

STEPS:
1. Confirm VirtualBox is installed and VBoxManage is on the PATH:
   VBoxManage --version
   Expect a 7.x version string. If the command is not found, stop and tell me.

2. Optional: preview what the OVA will create before committing to the import:
   VBoxManage import <OVA_PATH> --dry-run

3. Import the OVA. A single import attaches both the root disk and the cidata seed
   disk. Use at least 2 vCPU / 4096 MB; 4 vCPU / 8192 MB is recommended:
   VBoxManage import <OVA_PATH> --vsys 0 --cpus 4 --memory 8192 --vmname "<VM_NAME>"
   The import moves ~40 GB, so it can take a few minutes.

4. Set the firmware to EFI. This is mandatory: the image uses a GPT disk with an EFI
   System Partition and will not boot under BIOS. Do NOT enable Secure Boot (it is
   off by default; the bootloader is unsigned and Secure Boot would block boot):
   VBoxManage modifyvm "<VM_NAME>" --firmware efi

5. Find the host NIC to bridge to:
   VBoxManage list bridgedifs
   Read back the Name field of the interface connected to the engagement LAN
   (typically the wired Ethernet adapter, for example en0, eth0, or Ethernet). That
   value is <HOST_NIC>.

6. Attach Adapter 1 as a bridged adapter on that NIC:
   VBoxManage modifyvm "<VM_NAME>" --nic1 bridged --bridge-adapter1 "<HOST_NIC>"
   Bridged is required so the appliance has Layer-2 reach to targets. NAT is only
   acceptable for an isolated lab with no real LAN targets; do not use it otherwise.

7. Start the VM with a console window so I can watch first boot:
   VBoxManage startvm "<VM_NAME>" --type gui

VERIFY:
8. Confirm the VM is running and configured correctly:
   VBoxManage list runningvms
   VBoxManage showvminfo "<VM_NAME>" | grep -E "Firmware|NIC 1"
   Expect Firmware EFI and NIC 1 attached as a Bridged Interface on <HOST_NIC>.

9. Watch the VM console window. The appliance boots already registered and shows a
   live status and troubleshooting dashboard (network interface, VPN tunnel, and
   connectivity health). There is no code to read or send back; the outbound tunnel
   comes up on its own, and there is nothing to log in to or configure inside it. If
   the console stays blank, the firmware is almost certainly still BIOS: stop and
   tell me so we can recheck step 4.

RULES YOU MUST FOLLOW:
- These steps are authoritative. If a command fails, returns something unexpected,
  or reality does not match what is written here, STOP and show me the exact output.
  Do not improvise, invent flags, or try alternative commands on your own.
- The appliance needs exactly ONE connection: an outbound tunnel on TCP/443 to
  connect.remotetesting.secureworks.com. Never open, forward, or allow any INBOUND
  port to it. If connectivity fails, the problem is on the outbound path, never a
  missing inbound rule.
- Never enable Secure Boot and never change the firmware or boot type away from what
  these steps specify (UEFI / Generation 2). The appliance will not boot otherwise.
- Do not SSH into, log in to, or reconfigure the appliance. Once it boots it
  provisions itself; there is nothing to set up inside it.
- Every value in angle brackets (<LIKE_THIS>) must come from me. Never guess, invent,
  or reuse one. Ask me for any you do not have before running the step that needs it.
- Do not weaken security to force the connection (do not disable TLS inspection, and
  do not turn off a firewall). If something is blocked, tell me what and let me decide.
- Do only what these steps describe: deploy this one appliance. Do not create extra
  resources, install extra software, or take any action beyond that.

Network access

The appliance makes one connection to do its job: an outbound tunnel to the Sophos headend. Nothing inbound is ever required: you never open or forward any ports to the appliance.

Allow this outbound destination

Destination	connect.remotetesting.secureworks.com
IP addresses	3.33.194.251 and 15.197.255.2 (static; these do not change)
Port / protocol	TCP 443, carrying OpenVPN (not HTTPS)
Direction	Outbound only

Allow egress on TCP/443 to that destination from the appliance's network. On a next-generation firewall or NAC-controlled network, an L3 "allow 443" rule is often not enough: Layer-7 application control, TLS/SSL decryption, or NAC can still drop the tunnel even when the port is open. See Connectivity troubleshooting for the exact firewall and NAC exceptions to request.

Troubleshooting

Deployed but something isn't right?

See this platform's troubleshooting guide for the most common issues here and how to fix them.