It’s in their docs. https://docs.nextcloud.com/server/latest/admin_manual/installation/index.html

Follow the pages one by one, (ie install php modules etc, edit settings, install apache2, edit settings, etc etc). Follow the recommendations (eg. PHP8.2, don’t try to use bleeding edge).

You’ll be running in no time, and have a properly updatable system using apt, and the nextcloud ./occ command.

I would recommend using Debian 12 over Ubuntu variants. There are other guides, like this: https://www.digitalocean.com/community/tutorial-collections/how-to-install-and-configure-nextcloud But you may have to “convert” some of the Ubuntu specific stuff to Debian, but actually there is probably no difference (php module naming convention maybe? Is that still a problem today?)

Heimdall

https://youtu.be/GXnnMAxPzMc

Thats not how it works.

You have a LAN and hopefully you have a firewall that shields your LAN from WAN. Your fw is probably handing out DHCP lease IP (like 192.168.x.y)

When you “bridge” your VM looks like an independant device on you LAN. Nothing at this point has allowed it to the public. Your dhcp can even give it an IP (but its probably better to set a static ip). In bridge mode, a "fake mac is spoofed alongside you nic’s real mac, and only for said VM)

At that point the VM id accessible likr any other device on the LAN.

if you then want to use vpn, just connect to your LAN however that works(vpn to computer or vpn to firewall/vpn server) and access.

if you want to access from WAN without vpn, then you need to understand reverse proxying and youll need a full proper firewall\gateway device at the front of your network (like OPNsense).

It dropped today! I would not recommend rolling out to production immediately without testing first. There are some known issues that do need thought.

I’d also like to make those who use opnsense aware that there is a community that specifically targets it. Of course we are here in Selfhosted to help, and wouldn’t stop.

I replied to a nginx plugin question years ago on Reddit. Simple fact is, the plugin is really just designed to host a simple-ish webpage. https://www.reddit.com/r/OPNsenseFirewall/comments/klauwb/setting_up_a_web_server_on_my_opnsense_box_with/

I recommend you serve whatever you want to serving on vm’s/whatever on your internal network, and then use HAProxy (Built-in) to do the forwarding via opnsense. HAProxy is a High Availability and Performance proxy and load balancer, it does what nginx proxy manager does and more.

Mine is ~300w @ 230v most of the day. It varies only on what is being used.

when power fails and i have to switch to generator, the servers stay about the same but I can add about 250w to that for my PC, modem(nbn) etc . (which is why i know this info!)

This is a different problem. But when you configure a competent DHCP server, you tell it to give out a bunch of information to the client, not just an IP address. It should tell it IP, subnet, gateway, DNS server IP and default domain name. (in opnsense most of this is default so you dont have to actually configure it - hit the (i) button and it will tell you. Example for domain name: “The default is to use the domain name of this system as the default domain name provided by DHCP. You may specify an alternate domain name here.”)

Then on top of that google devices are notorious for ignoring DNS (ahem chromecast, etc) and want to use 8.8.8.8. This is because google does all sorts of non-DNS buggery on those devices, for example checking and pushing updates). Chrome on you PC could well be doing this as well, but it shouldnt it should be honouring your NICs config. However I don’t for a second doubt that Chrome is preferring DoH to somewhere like 8.8.8.8 first.

You will need to create a rule to enforce your local DNS server and block all other outgoing attempts.

To do this create a NAT rule port forward -> set the interface to LAN ,set the destination to LAN net and INVERT. Then destination port to DNS. Finally redirect target to your DNS server (127.0.0.1 for your opnsense) and DNS port (53).

This NAT rule says any DNS NOT headed to the LAN network must be redirected to the DNS server in your LAN.

Holy crap. Burn it with fire and make the switch.

A few weeks ago, I purchased a TP-Link AX53 for $200 AUD. Not the absolute bleeding edge for speed, but its WIFI6 does WPA3, mobile devices typically get 1Gb/s. More than enough for most use cases (Yes, you can get much faster but expect $$$$$)

Well yes. Normally you would put opnsense on 192.168.1.1/24 and then the wifi device on say 192.168.1.10/24. Then you allow opnsense to do the DHCP and disable DHCP on the wifi (they like to offer these services which can be nice for really simple setups).

What you are realistically running into is a DHCP war, and google will probably win over opnsense for wifi devices.

If what you actually want is to separate the devices to different subnets, then you really need to create a LAN / WAN and WIFI interfaces. And plug the wifi devices in the the WIFI interface (another network port on your opnsense box).

Then doing this, you can create a firewall rule(s) that allows data LAN <-> WIFI etc however you please. (or not even, maybe only WIFI <-> WAN and not let wifi devices access your LAN net).

Alternatively if you have a smart enough switch you could isolate with VLANs. But for a simple network, this isnt really necessary.

Well in Interfaces -> LAN go to where you set your static IP for opnsense and change that to 192.168.1.1/16. That should get you running. But the google device would probably need to be told that it is 192.168.866.0/16 as well so it can see the 192.168.1.0 subnet.

However it would probably be better to disable DHCP on the google device, but I don’t know anything about them. (I read that on some you cannot disable it, so set the DHCP pool to 1 and then assign that IP to some mac address. Essentially stopping the google device from handing out that address).

If this is what you need to do, then on opnsense set up your DHCP pool to say 192.168.1.100-250. Then set the google device pool to 192.168.1.251-251 and then set a static lease in the google 192.168.251 to MAC: de:ad:be:ef:ca:fe.

(That wifi sounds like a shit device - maybe consider a tp-link or something more configurable)