What are recommended ways to grant XCP-ng and XO access to the internet?
-
Hello, I'm new to these forums. I understand that the best answer here might be "you shouldn't give these access to the internet." That's actually what I'm doing right now.
I have a homelab and everything hypervisor or otherwise infrastructure-related is on a VLAN for Management. I use a pfSense firewall to block the entire Management network from accessing the internet. I have a few other VLANs setup as well. XCP-ng is configured with networks for all of these VLANs via trunk ports, although it only has its own IP on the Management VLAN today. These networks are:
- WAN
- Production (this is where most devices operate)
- DMZ (shared resources like pihole DNS and untrusted devices like IoT live here)
- Development (I can tinker and not worry about impacting the other networks)
I am testing XCP-ng and XO (built from source) and I'm running into challenges here and there doing everything on the Management network, completely offline from the internet.
- It doesn't seem straightforward to get XO Lite setup on the XCP-ng instance.
- Certain things in XO don't work. Like if I create a new VM, there are no Template options available.
- Future updates will be a headache to download and install.
I was wondering how others deal with this challenge. Do you poke holes in your firewall so the Management network can resolve DNS requests and reach the IP addresses where Vates hosts XCP-ng repos? Do I put XO on the Production network? Keep everything offline and import templates, manually install updates?
This is a homelab, but also "production" for me. So I don't want to accidentally break anything, but at the same time this isn't a business that needs perfect security strategies. I can be flexible.
-
@waveguide said in What are recommended ways to grant XCP-ng and XO access to the internet?:
Do you poke holes in your firewall so the Management network can resolve DNS requests and reach the IP addresses
Outgoing communication from management and xcp-ng hosts to Internet is not very dangerous, because hosts are the initiators. Generally I don't block it. You can monitor these connections or restrict to certain addresses.
-
You shouldn't have any issue to create VMs offline with XO and all other features (backup and such). If you need to have a full air gap environment, we provide solutions at Vates.
If it's for a home lab, you could build XO online and put the files on an USB stick. Same for XCP-ng updates. Or alternatively, use a strictly configured proxy (only authorizing some URLs).
Finally, the best practice is to never expose the mgmt network outside, but you can have your XO inside the network and only expose XO outside. If you have multiple locations, you could rely on XO proxies.
-
It's not uncommon for management appliances to need to access the internet, so in general I do allow web access on my management networks, including the one for XO and XCP-ng so they can install updates etc....
As long as you just allowing outbound connections, it's not super risky, the appliance itself would already have to be at least partially compromised for it to reach out to something malicious. Of course this isn't 100% definitive since it's never impossible for say an update server to get compromised first, but the reality is you have to keep things up to date.
Now what I do deploy, and this isn't just for management, is things like DNS filtering, IP filtering, GeoIP blocking, etc... to help prevent anything malicious from being reached out to.
-
@olivierlambert when suggesting to give XO access, do you mean permitting the instance of XO on the Management network to reach the internet (firewall adjustment for this host)? Or adding another IP for XO on the Production network so it has access to the Internet that way?
@planedrop Is there a list of IP addresses I can restrict to for updating XCP-ng and XO? Alternatively, I can temporarily open all outgoing connections up and monitor the targets...
-
@waveguide I think @olivierlambert was actually talking about accessing XO remotely, as in exposing it to the web so you can use it's management features.
I don't have a list of IP addresses for updating XO, monitoring is probably the best way, but I personally allow everything that isn't on my blocklists, rather than whitelisting.
Do you have an NGFW sitting in front of these? Most of them make it pretty easy to setup blocklists and security filtering, I'm using pfSense with pfBlocker and just block malware lists and all GeoIP addresses outside my country.
-
@planedrop I'm using pfSense as the firewall and router for all the networks and have been using pihole instead of pfBlocker. I could provide the management network or just XO access to pihole DNS and configure pfSense to allow outbound access from the management network to the Internet.
-
@waveguide My personal setup is pretty similar, I allow outbound traffic to inverse-matched RFC1918, but have pfBlocker configured to block malicious IPs and domains (and then the aforementioned GeoIP blocking).
I prefer having it all in one place which is why I go this route instead of PiHole, and then I can filter IPs too which is great.
-
@olivierlambert Maybe my issue with the VM templates isn't a network problem like I thought. Here's what I'm running into.
I built XO from source following guides from Lawrence Systems. If I navigate to Home \ VMs, select the "+New VM" button and then select my pool, I get the screen for adding a new VM.
When I go to select a Template, at least initially there were no templates on the list, it was empty. No choices. Without a template, I couldn't successfully add a network interface, couldn't add a disk, and I could not fill out the criteria that would enable the "Create" button. So I could not create new VMs.
I ended up building a VM on ESXi, importing that VM using XO, and then I converted that VM into a template. Now I have a single template that I can use to create new VMs.
I assumed that the templates list being empty was because I didn't provide XO internet access. Maybe that's not the case? Is that a limitation of building XO from source as opposed to using the XOA?
-
-
@olivierlambert That worked! I now have templates available.
@planedrop and @karlisi what I ended up doing was enabling outbound access from the Management network to two things:
- Port 53 on my pihole DNS
- A set of IP addresses on the Internet that are where XCP-ng, Fedora, Ubuntu, and others host their repositories.
So long as these resources stay secure, I can now run updates against them. No other outbound access is enabled, and inbound continues to be completely blocked.
-
@waveguide This is a good solution, glad it's working.
