# DRACARYS
DRACARYS is an awesome [pentest training challenge](https://docs.ludus.cloud/docs/environment-guides/goad-dracarys/).

## Add the Windows 2025 and Ubuntu 24.04 template to Ludus
The install instructions walk you through this, but if you don't do this step, your DRACARYS install will fail:

```
ludus source add ludus-source-bsl --templates win2025-server-x64-tpm-template,ubuntu-24.04-x64-server-template
```

## Install
For the basic install you can follow our [GOAD install guide](/software/goad) to get the nuts and bolts of the lab installed, just use `set_lab DRACARYS` instead of setting the lab to GOAD before install.

## Snapshot the environment (optional)
I like to create a snapshot called `level0` before I actually start hackin' stuff, so I use a command like this:

```
ludus --user XXX snapshots create <snapshot-name>
```

However, what I found with DRACARYS is that the snapshotting of the DC and app server failed.  This is due to the TPM config on these VMs.  So I did this:

```
qm stop 108 && qm stop 109
sleep 10
qm set 108 --delete tpmstate0
qm set 109 --delete tpmstate0
```

This allowed me to take a full snapshot of the range.

## Advanced networking

By default, nothing in a Ludus range can see your real network. If you need a lab VM to pull a
DHCP lease from your actual LAN — a Kali box that needs to reach a physical target, or a VM you
want to hit from your laptop without going through a router VM — you can bridge the host's physical
NIC into Proxmox and attach VMs to it directly.

This is a manual Proxmox change. Bridging a physical NIC into a range isn't a Ludus feature yet
([open request](https://gitlab.com/badsectorlabs/ludus/-/work_items/35)).

> **Do this from IPMI/iDRAC or a physical console, not over SSH.** If the NIC you're converting is
> your only wired uplink, a typo will lock you out of the box.

The examples below use placeholder values — swap in your own:

| Value used here | What it is |
| --- | --- |
| `eno1` | The host's physical uplink NIC (`ip a` to find yours) |
| `192.168.1.0/24` | Your physical LAN subnet |
| `192.168.1.1` | Your LAN gateway / DHCP server |
| `192.168.1.20` | The Proxmox host's management IP |

### Why the stock Ludus bridges won't work

- `vmbr1000` — the Ludus NAT bridge (`192.0.2.254/24`). MASQUERADEs lab traffic out to the internet.
- `vmbr1001`, `vmbr1002`, ... — per-user bridges, routed through each user's router VM (`192.0.2.10X`).

None of these share an L2 segment with your physical LAN, so VMs on them will never see your LAN's
DHCP server. You need a new bridge that has the physical NIC as a member port.

### Create vmbr0 with the physical NIC as a bridge port

Back up the current config first:

```
cp /etc/network/interfaces /etc/network/interfaces.gold
```

Then edit `/etc/network/interfaces`. The NIC goes from holding the IP directly to being a bridge
port, and the host IP moves onto the new bridge:

```
auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.20/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
```

Put this **above** the `# LUDUS MANAGED` markers so Ludus doesn't clobber it on the next config run.

Apply it with `ifreload -a` (ifupdown2 — no reboot needed). The host stays reachable at the same IP,
since the address just moved onto the bridge.

If your switch port is a VLAN trunk rather than an access port, add `bridge-vlan-aware yes` and
`bridge-vids` to the `vmbr0` stanza and tag the VM NICs instead.

### Gotcha #1: the lab loses internet after the bridge change

The Ludus NAT rule is pinned to whatever interface was doing the routing when Ludus was installed:

```
-A POSTROUTING -s 192.0.2.0/24 -o eno1 -j MASQUERADE
```

Once `eno1` is a bridge port, internet-bound traffic egresses via `vmbr0` instead, the rule stops
matching, and lab VMs leave un-masqueraded and go dark.

Point the MASQUERADE at the bridge. Both lines in the `vmbr1000` stanza:

```
post-up   iptables -t nat -A POSTROUTING -s '192.0.2.254/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.0.2.254/24' -o vmbr0 -j MASQUERADE
```

### Gotcha #2: duplicate MASQUERADE rules

That `post-up` appends a rule on every `ifup` / `ifreload`, so a few rounds of testing will leave
you with stacked duplicates pointing at the old interface. If POSTROUTING contains nothing else,
flush and re-add:

```
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o vmbr0 -j MASQUERADE
```

Make sure the on-disk config matches so it survives a reboot:

```
sed -i 's/-o eno1 -j MASQUERADE/-o vmbr0 -j MASQUERADE/g' /etc/network/interfaces
grep MASQUERADE /etc/network/interfaces   # both lines should say -o vmbr0
```

### Verify

```
ip a                              # host IP on vmbr0; the NIC shows "master vmbr0" and no IP
ip r                              # default route via your gateway, dev vmbr0
iptables -t nat -S POSTROUTING    # exactly ONE MASQUERADE rule, -o vmbr0
```

Then from any lab guest, `ping 1.1.1.1` to confirm routing and NAT, followed by `ping google.com`
to confirm DNS.

### Attaching a VM to the LAN

- **Plain Proxmox VM:** Hardware → Network Device → Bridge = `vmbr0`, VLAN Tag empty. It'll DHCP
  from your LAN gateway.
- **Ludus range VM:** add the `vmbr0` NIC by hand in the Proxmox UI after the range deploys. It will
  **not** survive a range destroy/redeploy — treat it as a per-deploy manual step.

### Rollback

```
cp /etc/network/interfaces.gold /etc/network/interfaces && ifreload -a
```

### Security note

This is an offensive lab, and the Ludus NAT is doing real work keeping that traffic off your
production network. Hanging a single throwaway VM off `vmbr0` because it needs a real lease is one
thing. Putting the whole range on it is another — don't.