9.8 KiB
| layout | author | title |
|---|---|---|
| post | hexaitos | Hosting my websites at home but I only have a public IPv6 subnet |
I wanted to write a small series of blog posts detailing how I made it so that my websites that are hosted at the server in my apartment (which only has a public IPv6 address) can be accessed from the Internet even if you’re in an IPv4-only network and I wanted to start by writing a post about how I delegated an IPv6 prefix to my OPNsense installation from my FRITZ!Box. (Un)fortunately, just as I finished writing it, I found out that the official (I think) OPNsense documentation has the exact thing I wrote about documented already, so there’s really no point in my posting my own version that is almost literally the same thing.
Therefore, I’ll just be skipping that portion of my blog post. If you’re in Germany and a customer of Vodafone’s, then you should have been assigned a /59 IPv6 subnet and you can quite simply follow the instructions on the official documentation that I linked above.
Before I start this off, it is important to note that this will only work if you’re using Cloudflare’s proxy. I have not found any other DNS provider that allows you to do this, unfortunately. I know there are some who have quite strong (and often negative) opinions about Cloudflare, so if you’re one of those, then you will probably not be able to do this. If you’re not sure what I’m talking about, you should probably read up on Cloudflare and how their proxy functions first and try to form your own opinion on this matter. If you know of another (free!) way to do this without using Cloudflare, then I’d be happy to hear about it.
Also, I’m not claiming that anything I’m about to explain is necessarily the best way of going about this; it’s simply what I found works quite well for me. If I wrote something that’s terrible advice or if you found something that I could improve, you are more than welcome to contact me about that, too!
And lastly, please note that a lot of ISPs do not technically allow the hosting of webservers if you only have a consumer contract and you might have to pay for a (usually more expensive) business contract instead. Or they might just straight up block certain ports from working in the first place on consumer contracts. Therefore, before you do anything, I urge you to check your ISP’s terms of service.
With that out of the way, let’s get started!
Setup overview
Before we start, a quick rundown of my setup. I have a FRITZ!Box 6660 Cable (my main router) to which my server running Proxmox is connected. The FRITZ!Box gets a /59 IPv6 prefix but no public IPv4 (CGNAT). Running on the Proxmox host as a VM is an OPNsense installation. Its WAN network is connected to the LAN network of my FRITZ!Box (it, therefore, gets an IPv4 address in my FRITZ!Box’ LAN, 192.168.178.0/24) and the OPNsense’s LAN network is a virtual network that all other VMs running on my Proxmox installation are connected to. Additionally, I have assigned a /64 IPv6 prefix to the LAN network of my OPNsense (see OPNsense documentation above) and all VMs get both a private IPv4 address (in the OPNsense’s 10.10.10.0/24 network) via DHCP and an IPv6 address either via SLAAC or DHCPv6.
For my webserver in particular I made a separate and really small (/30) IPv4 subnet with a virtual IP in OPNsense, mostly so this public-facing LXC is in a different network from the VMs and LXCs that are not open to the public. I’ll probably switch that over to a VLAN instead of a virtual IP soon. I feel like this is a bit overkill (and probably doesn’t add that much security anyway), but I wanted to do it anyway. However, this means that my webserver has a static IPv4 in a different network, namely 10.11.10.2/30 with 10.11.10.1/30 being the virtual IP I assigned to the OPNsense installation and it cannot talk to any other VM or LXC.
I don’t want to share the exact IPv6 prefix I get from my ISP, but let’s just pretend it’s 2001:db8:0:e280::/59 where 2001:db8:0:e280::/64 is used by the FRITZ!Box itself and where 2001:db8:0:e291::/64 has been delegated to the OPNsense’s LAN interface. I have assigned a static IPv6 to the LXC which is running my webservers, namely 2001:db8:0:e280::1000:1/128.
My webserver is running Caddy and I’m using a module for Caddy called dns.providers.cloudflare so that Caddy can create an SSL certificate even when it’s behind Cloudflare’s proxy.
Okay, that was probably quite a bit of information. The best tl;dr I can think of is: the public IPv6 my webserver gets is 2001:db8:0:e280::1000:1/128 (the prefix is not my actual prefix, this is just as an example).
Setting up Cloudflare
I’ll assume that you already are somewhat familiar with Cloudflare and how it works, especially after what I mentioned earlier in the blog post and I’ll also assume that you have already added your domain to Cloudflare. If you have not yet done so, please refer to Cloudflare’s own documentation on how to do this.
What you have to do is go into your domain’s DNS settings and create only a single AAAA record with the proxy enabled. Do not add another AAAA record or even an A record; simply add a AAAA pointing to the IPv6 address of your server. This should look as follows:
This is probably the most important aspect of this entire thing if you want your website to be reachable even in networks that do not support IPv6. If you only set a AAAA record and no A record, Cloudflare will automatically translate requests from IPv4 networks so that your website can be reached even from those networks.
You may also have to change the SSL settings of your domain. By default, the SSL setting is set to flexible
which ended up not working for me and I had to set it to full
instead:
{:width="30%"}
While you’re here, you might as well also create an API key either for your entire account or only for a particular zone / domain. For more information about what permissions need to be set, you can look at the GitHub page for Caddy’s Cloudflare module.
Firewall rules
The first thing you’d have to properly set up are the firewall rules, especially the WAN rules. Since the only thing running on my LXC that needs to be accessed from the Internet is a webserver, it only really needs to have ports 443 and maybe also port 80 open to the public. I created an alias that includes both ports so that I don’t have to create two rules and I simply named it allowed_ports_default.
However, we can refine this rule a bit further: since all the traffic going to our webserver should come from Cloudflare (as we’re using their proxy), you change the rule so that only traffic from Cloudflare’s network is accepted.
To do this, you can simply create yet another alias that includes all the networks that Cloudflare uses. Luckily, Cloudflare publishes the list of their IPv6 subnets which you can find it here: https://www.cloudflare.com/ips-v6/#. So all we need to do is create an alias that includes all seven (at the time of writing) subnets and put that alias into the Source
field of our created WAN rules. The alias should end up looking as follows:
And the rule should end up looking as follows:
Additionally, you also have to set up the rules on the LAN interface. I created two LAN rules, one for the IPv6 and one for the IPv4 address of my webserver and I allowed only ports 443, 80, 123, 53 for both IPv4 TCP/UDP and IPv6 TCP/UDP. I also set up a LAN rule that blocks access from my webservers LAN network to all of my other LANs.
Caddy configuration
I’m assuming you know how to get a website up and running with Caddy. If not, I highly recommend looking at their documentation, it’s really quite simple!
However, getting Caddy to work with the Cloudflare DNS was a little bit annoying at first, because the Debian 12 LXC that I’m running did not have the newest version of Caddy in its repositories, apparently, and the version that was available did not have the add-package command which is needed to install the Cloudflare DNS module. So I simply downloaded the newest .deb file from Caddy’s GitHub, installed that and installed the Cloudflare DNS module using the command sudo caddy add-package github.com/caddy-dns/cloudflare. Afterwards, simply follow the instructions on their GitHub page on how to add the API key to your configuration.
If you then restart Caddy after adding your configuration (or simply starting it for the first time), it should automatically generate an SSL certificate for you and your website should become reachable from both IPv6- and IPv4-only networks.
Conclusion
Your website should now be accessible from the Internet! I hope you enjoyed reading this and I hope it will end up helping someone in the future. If you have any further questions, critique or whatever, feel free to reach out to me. This is the first blog post I have written in a long time, so if there’s anything you think could be improved in the next one, I would love to hear about it.