> For the complete documentation index, see [llms.txt](https://truck-2-tech-security.gitbook.io/writeups-and-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://truck-2-tech-security.gitbook.io/writeups-and-labs/security-research/home-labs/t2t.local/part-1.md). # Part 1 ## What this is….and isn’t. First off, I’d like to go into a little bit more about why I even decided to do this lab. While there are plenty of pre-made labs available (GOAD variations, ranges on HackSmarter, HTB, etc), I wanted the satisfaction of creating a full mini-enterprise lab myself. I’ve done the setup of Active Directory before, but it’s always been a quick spin up of a DC and a workstation (or two). Now that I have a rig with 64GB of RAM available to me (48GB that I can allocate to VMs and almost all of that will go towards this lab. You have been warned.) I have the capability of having several VMs running at once. ### What it is: A complete diary of my setup to create a miniature version of the type of networks I work with as a technician at an MSP. It shows all of the headaches in the setup (especially the IPSec tunnel) of firewalls, network connectivity, security and administration of the domain. ### What it isn’t: Something that you should attempt to do yourself, unless you’d like to spend your time second guessing yourself several times, and/or have hardware of capable of running such a massive lab. This will not hold your hand, nor will it answer all of your questions. It’s not intended to; I learned and struggled through the process, and you will too (should you choose to continue…) *If you’re still interested, hey, that’s cool. If not, I don’t blame you - I’ll see you at the next “follow the bouncing ball” walkthrough…* ### Network Design: There are a lot of lab-building guides that will start with downloading Kali, or a Windows Server and immediately start the installation. Maybe some of them give you a pretty network diagram (this will attempt to also do that). I’ve found that diving headfirst into installing a larger VM lab without planning the network first leads to retrofitting connections after the fact. This is a tedius task, and it teaches bad habits (in my opinion). In a real environment, NOTHING happens without some prior planning. Servers don’t drop before the network engineering team has signed off on the plan. This lab will reflect that type of discipline. Because I know what a virtual machine is, and how to install VMware I’m not bothering to cover it. It’s boring and pointless to mention it further. #### The Virtual Network Editor I familiarized myself with the default VMnet’s: * VMnet0: Bridges to your NIC and passes traffic directly through to your home network. It gets DHCP from your router and appears as a device on the LAN. * VMnet1: The host-only option that lets VMs talk to each other and to the host, but not to the internet. * VMnet8: This is the NAT option. It allows VMs to access the internet through your host, and appears as your host IP address in the LAN. For this lab, I’m going to create custom VMnets. The network is segmented into distinct areas and the routing will be handled by OPNsense firewall VMs. If you’re like me and like pretty pictures to help understand something, here you go: ![t2t.local network overview](/files/RKluoHf7zbymo5qQ91iu) The lab idea is that you have a main location that has the Domain Controller, a workstation, and the Kali VM (that will be used for security testing). There is a satellite location with a server running as a File Server and an additional workstation. There is a simulated WAN connection between the two locations. I’m simulating a straight VPN connection between the two of them (I know there are options in the real world that are much better and faster then a VPN connection, so don’t start). Here’s the written out plan: * WAN / Inter-Firewall Link * 192.168.100.0/24 * This is the point to point network between the two firewalls: FW1 and FW2 * The intent is to simulate a WAN connection between the two locations * Site-A LAN * 10.10.1.0/24 * This is the primary internal network * Will have the DC01 (Domain Controller), WS01 (Workstation), and Kali * Site-B LAN * 10.10.2.0/24 * Secondary internal network * Will have the FS01 (File Server) and WS02 (Workstation) * DMZ * 10.10.3.0/24 * Exposed services network * Home to the Ubuntu Web server * Reachable from the WAN with restrictions * Isolated from internal LAN by firewall policy * Guest Network * 10.10.4.0/24 * Isolated client simulation network with a capture portal (through OPNsense FW01) * No access to internal segments * Security Onion Monitoring * A dedicated interface that spans internal traffic for out-of-band detection * No IP needed on the monitoring interface itself #### Creating the Virtual Network Switches I created five custom VMnets: * VMnet2 - WAN * VMnet3 - LAN1 * VMnet4 - LAN2 * VMnet5 - DMZ * VMnet6 - GUEST Each of these is set to Host-Only and DHCP disabled. Here is a screenshot of the final product: ![My five VMnets](/files/zY6r1RRTWJqX7lNpqE8n) Next up is Part 2, where I'll start the setup of the Domain Controller. I originally used Server 2016, but I'll be using Server 2025 this time around.