Cursed Silicons Wiki - User contributions [en]

How to Get Connected

2026-03-22T00:17:39Z

Snep: Remove left-over section from previously removed OPNsense section

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "open beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## Reboot the router, this step is necessary if you intend to use the web UI for any other configuration or see the status of the CGHMN connection, to make LuCI recognize Wireguard connections.
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface and the default <code>br-lan</code> or any other bridge the interface might belong to, to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Head over to https://signup.cghmn.org, fill out the form there with your details like an e-mail address we can reach you under and copy over the Wireguard public key from the script output into the appropriate field on the web page. Once your request has been approved, you'll receive an e-mail with your CGHMN Wireguard connections details. Note: If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code with your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In the e-mail from your sign-up server post approval, you will receive a tunnel IPv4 address (<code>100.65.x.x/32</code>) and a routed IPv4 subnet (<code>100.68.x.0/24</code> and up). These will be needed on the next step
# Run <code>ash setup-cghmn.sh set-tunnel-ip</code>, enter your new tunnel IP address with or without the <code>/32</code> subnet mask, enter your routed subnet '''with''' the CIDR netmask and supply your pre-shared key from the e-mail.
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard/IP traffic only) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Head over to https://signup.cghmn.org, fill out the forms with some details like an e-mail address we can reach you under and paste the newly generated public key into the public key field.
* After submitting your request, we'll approve it as soon as possible and you'll get two IP addresses sent over to your specified e-mail: Your tunnel IP address, with which ''your'' router talks to ''our'' router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* In the e-mail, you will also find a full Wireguard configuration looking a little like this:

[Interface]
PrivateKey = xxx
Address = 100.65.0.xxx/32

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = us.wg.cghmn.org:42070
AllowedIPs = 100.64.0.0/10
PersistentKeepalive = 15
PresharedKey = xxx

* Copy this configuration to a file, <code>wg-cghmn.conf</code>, for example.
* If you use wg-quick like below, you can also add the line <code>DNS = 100.64.12.2</code> in the [Interface] section to make use of our DNS resolvers and access other CGHMN member's services through domain names, though be adviced that we cannot guarantee public internet address lookups, which means this might break internet access for the host you're opening this Wireguard tunnel from! Alternatively, for advanced users, one can setup dnsmasq to automatically pull any domains we offer within the CGHMN and forward them to our DNS resolvers with the help of [https://raw.githubusercontent.com/CGHMN/openwrt-scripts/refs/heads/main/dns/update-dns-forwards.sh this script from our GitHub] and having it being run periodically through cron, systemd-timers or similar. See [[CGHMN DNS Information#dnsmasq Synchronization Script|this Wiki article]] for more information.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

==== Explore things available on the network ====
There is a collection of [[services people are running]] - things like email/hosting/chat/search/etc.

How to Get Connected

2026-03-22T00:17:04Z

Snep: Add DNS information to the manually configured Wireguard section, include the sign-up page and remove the obsolete OPNsense admin part of the manual connection guide

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "open beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## Reboot the router, this step is necessary if you intend to use the web UI for any other configuration or see the status of the CGHMN connection, to make LuCI recognize Wireguard connections.
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface and the default <code>br-lan</code> or any other bridge the interface might belong to, to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Head over to https://signup.cghmn.org, fill out the form there with your details like an e-mail address we can reach you under and copy over the Wireguard public key from the script output into the appropriate field on the web page. Once your request has been approved, you'll receive an e-mail with your CGHMN Wireguard connections details. Note: If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code with your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In the e-mail from your sign-up server post approval, you will receive a tunnel IPv4 address (<code>100.65.x.x/32</code>) and a routed IPv4 subnet (<code>100.68.x.0/24</code> and up). These will be needed on the next step
# Run <code>ash setup-cghmn.sh set-tunnel-ip</code>, enter your new tunnel IP address with or without the <code>/32</code> subnet mask, enter your routed subnet '''with''' the CIDR netmask and supply your pre-shared key from the e-mail.
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard/IP traffic only) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Head over to https://signup.cghmn.org, fill out the forms with some details like an e-mail address we can reach you under and paste the newly generated public key into the public key field.
* After submitting your request, we'll approve it as soon as possible and you'll get two IP addresses sent over to your specified e-mail: Your tunnel IP address, with which ''your'' router talks to ''our'' router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* In the e-mail, you will also find a full Wireguard configuration looking a little like this:

[Interface]
PrivateKey = xxx
Address = 100.65.0.xxx/32

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = us.wg.cghmn.org:42070
AllowedIPs = 100.64.0.0/10
PersistentKeepalive = 15
PresharedKey = xxx

* Copy this configuration to a file, <code>wg-cghmn.conf</code>, for example.
* If you use wg-quick like below, you can also add the line <code>DNS = 100.64.12.2</code> in the [Interface] section to make use of our DNS resolvers and access other CGHMN member's services through domain names, though be adviced that we cannot guarantee public internet address lookups, which means this might break internet access for the host you're opening this Wireguard tunnel from! Alternatively, for advanced users, one can setup dnsmasq to automatically pull any domains we offer within the CGHMN and forward them to our DNS resolvers with the help of [https://raw.githubusercontent.com/CGHMN/openwrt-scripts/refs/heads/main/dns/update-dns-forwards.sh this script from our GitHub] and having it being run periodically through cron, systemd-timers or similar. See [[CGHMN DNS Information#dnsmasq Synchronization Script|this Wiki article]] for more information.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

==== Explore things available on the network ====
There is a collection of [[services people are running]] - things like email/hosting/chat/search/etc.

CGHMN DNS Information

2026-03-22T00:15:31Z

Snep: Update dnsmasq update script

== About this page ==
This page exists to document information about the DNS of CGHMN, and some of the complexities that comes with a DNS infrastructure made of up varying platforms across decades of the protocol's evolution. See [[CGHMN-Demo-Network]] for detailed information about the underlying infrastructure

== DNS Configuration Guide ==

=== Getting Started ===

==== Pointing to the right DNS server ====
CGHMN has several DNS servers in use for differing purposes. '''The correct default DNS server you should be pointing at while getting started is 100.64.21.1 from the core network, or 100.89.128.0 from the Wireguard tunnel'''. This is the router, which then forwards the requests to the actual DNS.

==== What the different DNS servers are (or, is this thing on?) ====
CGHMN's DNS is configured such that there are three core servers that perform response modifications to allow the recreation of long defunct services, perform lookups, and act as the root name server for the network, which has two internal TLD (top level domain, like .com or .net) on it.

===== 100.64.11.11 - ns1.cghmn =====
This is the root name server for the .retro and .cghmn TLDs, as well as the 100.in-addr.arpa reverse lookup zone. This server exists to delegate domains to members of CGHMN, and serve as the name server for the internal network. This server is useful to perform a <code>dig</code> or <code>nslookup</code> against if you want to see if a subdomain has been delegated, for example:

<code>dig ns example.retro. @100.64.11.11</code>

or
nslookup

> server 100.64.11.11

> set type=ns

> example.retro.
This server does not perform lookups. It is currently running BIND.

===== <s>172.23.4.105</s> =====
<s>This is the recursive lookup server for the network. It is configured to recursively look up all requests for CGHMN domains, starting with ns1.cghmn, and then moving up based on delegations to member servers. Regular lookups still take place against real TLDs, if something needs to be pulled off the internet. This server is currently running BIND. This server is useful to use <code>dig</code> or <code>nslookup</code> against if you wish to see if your domain is resolving on the network after it has been delegated to you.</s>

<code><s>dig a test.example.retro. @172.23.4.105</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.105

> set type=a

> test.example.retro.</s>

===== <s>172.23.4.104 - legacydns.cghmhn</s> =====
<s>This is a dnsmasq server that is currently being used to perform modifications to DNS answers, by pulling from a list of servers that need to be faked in order to make old software, such as AIM, work correctly. This server overrides the DNS answer with these responses, so all relevant DNS records need to be added. The rationale for this is that instead of a user modifying their hosts file (which can be dozens of different DNS addresses long) we can simply return addresses that correspond within the network. Please ask if there is a service you would like added to the network that requires this kind of override. Otherwise, it just forwards the questions to the recursive lookup server 172.23.4.105. This server is useful to test against if you are having trouble connecting to a legacy service that utilizes hard coded DNS.</s>

<code><s>dig cname login.oscar.aol.com.</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.104

> set type=cname

> login.oscar.aol.com.</s>

===== 100.64.12.1 or 100.64.11.1 =====
This is the core router for the network, which also serves as a DNS forwarding. It forwards requests to .retro and .cghmn to ns1.cghmn, whilst resolving some legacy DNS overrides and custom DNS domains according to its local configuration. To get a list of domains for which this DNS resolver has overrides or local forwards configured, you can cURL/wget this URL: http://100.64.12.1:8080/dns-forward-domains.txt or if you're running dnsmasq as your resolver at home, directly include the configuration file available at http://100.64.12.1:8080/dns-forward-domains.dnsmasq.conf.

== Hosting Your Own DNS Name Server ==

=== About self-hosting ===
CGHMN can host member DNS zones on its nameserver, however it is welcome and even encouraged for them to explore setting up their own DNS name server for their subnet. This can be done with most DNS server software, provided they can be recursively looked up against by BIND. Please note that if you intend to run old Microsoft DNS, you will need to let us know that you are running it, as exceptions to the lookup procedure need to be added to the 172.23.4.105 server.

You will need to reach out to CGHMN and let us know you want to host your domain, and give us the domain, NS record, A record, and IP address of the DNS server.

=== What you need ===

==== A server ====
You will need a computer connected to CGHMN, running a DNS server software that is able to act as an authoritative name server. It will need to have UDP port 53 and TCP port 53 allowed in its firewall. You do not need a lot of power, but it should be fairly reliable as everything will depend on it to find your servers and services.

==== A SOA record ====
You will need a SOA (Start of Authority) record, this is the record that tells other DNS servers "I am in charge of this domain and here is the information about it". This record will need to be pointed to an NS (Name Server) record.

==== A NS record ====
You will need a NS record, this is the record that says "this is where you ask about this domain". This record should point at an A record.

==== An A record ====
You will need an A record, this is the record that maps the name of the DNS server to an IP address. This should be the FQDN (Fully Qualified Domain Name) of the DNS server, and the IP address it is listening to.

==== Summary ====
Your server will need to be configured as an authoritative name server. To do this, it must run a DNS name server software, which should have a zone containing an the SOA, which points at the NS, which points at the A.

== DNS Quirks ==

=== Windows DNS ===
Old Windows DNS servers will misbehave when BIND's recursive lookup server attempts to do a lookup against them, and will end in failure. The way around this is to disable edns lookups against this particular server in the BIND configuration. Bind is supposed to attempt again with edns disabled but it seems with Windows DNS specifically to fail.

=== DNS manipulation with multiple RR types ===
If a record is being looked up, and this record was once an A record, but still exists and is now a CNAME record, you will have an issue where the lookup will work with tools, but fail with actual lookups. This is because the CNAME record being returned from the real DNS server will take precedent over the fake A record. To resolve this issue, you have to fake both the CNAME and the A record.

== dnsmasq Synchronization Script ==
Since the CGHMN offers custom TLDs, keeping up with which domains are part of the CGHNM can become quite difficult. For this, @Snep built a small script (which is rather hacky, but works) that can be added on Linux systems which have dnsmasq running as their DNS resolver. It only needs <code>wget</code>, <code>grep</code> and <code>md5sum</code> (the BusyBox variants shipped with OpenWRT are fine). Download the following script to your router, for example into your root directory:
wget -O /root/update-dns-forwards.sh "https://raw.githubusercontent.com/CGHMN/openwrt-scripts/refs/heads/main/dns/update-dns-forwards.sh"
Next, run it manually once to make sure the CGHMN DNS configuration file exists and the script runs through without issue:
/bin/sh /root/update-dns-forwards.sh
Then, you can include the newly created configuration file in your dnsmasq instance. For OpenWRT devices, nagivate to Network -> DHCP and DNS -> Forwards and add <code>/etc/cghmn-domains.dnsmasq.conf</code> in the "Additional servers file" field, then hit "Save & Apply". On other systems, append the following line to your <code>dnsmasq.conf</code> file:
conf-file=/etc/cghmn-domains.dnsmasq.conf
Finally, to have the list get updated automatically every 15 minutes, add the following to your crontab (e.g. <code>crontab -e</code> as root):
*/15 * * * * /bin/sh /root/update-dns-forwards.sh
[[Category:Compu-Global-Hyper-Mega-Net]]

How to Get Connected

2026-03-21T23:49:03Z

Snep: Add the sign-up page to the setup script guide

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "open beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## Reboot the router, this step is necessary if you intend to use the web UI for any other configuration or see the status of the CGHMN connection, to make LuCI recognize Wireguard connections.
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface and the default <code>br-lan</code> or any other bridge the interface might belong to, to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Head over to https://signup.cghmn.org, fill out the form there with your details like an e-mail address we can reach you under and copy over the Wireguard public key from the script output into the appropriate field on the web page. Once your request has been approved, you'll receive an e-mail with your CGHMN Wireguard connections details. Note: If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code with your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In the e-mail from your sign-up server post approval, you will receive a tunnel IPv4 address (<code>100.65.x.x/32</code>) and a routed IPv4 subnet (<code>100.68.x.0/24</code> and up). These will be needed on the next step
# Run <code>ash setup-cghmn.sh set-tunnel-ip</code>, enter your new tunnel IP address with or without the <code>/32</code> subnet mask, enter your routed subnet '''with''' the CIDR netmask and supply your pre-shared key from the e-mail.
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 100.64.0.0/10
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== <s>Get connected - Server Side, the Admins Guide</s> ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do '''either one''' '''(not both!)''' of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

==== Explore things available on the network ====
There is a collection of [[services people are running]] - things like email/hosting/chat/search/etc.

How to Get Connected

2026-03-21T23:40:31Z

Snep: Add a reboot router step and clarify step four in the setup script tutorial

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "open beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## Reboot the router, this step is necessary if you intend to use the web UI for any other configuration or see the status of the CGHMN connection, to make LuCI recognize Wireguard connections.
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface and the default <code>br-lan</code> or any other bridge the interface might belong to, to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server. If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code printout of your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 100.64.0.0/10
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== <s>Get connected - Server Side, the Admins Guide</s> ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do '''either one''' '''(not both!)''' of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

==== Explore things available on the network ====
There is a collection of [[services people are running]] - things like email/hosting/chat/search/etc.

CGHMN DNS Information

2026-03-01T03:05:24Z

Snep: Updated DNS updater script

== About this page ==
This page exists to document information about the DNS of CGHMN, and some of the complexities that comes with a DNS infrastructure made of up varying platforms across decades of the protocol's evolution. See [[CGHMN-Demo-Network]] for detailed information about the underlying infrastructure

== DNS Configuration Guide ==

=== Getting Started ===

==== Pointing to the right DNS server ====
CGHMN has several DNS servers in use for differing purposes. '''The correct default DNS server you should be pointing at while getting started is 100.64.21.1 from the core network, or 100.89.128.0 from the Wireguard tunnel'''. This is the router, which then forwards the requests to the actual DNS.

==== What the different DNS servers are (or, is this thing on?) ====
CGHMN's DNS is configured such that there are three core servers that perform response modifications to allow the recreation of long defunct services, perform lookups, and act as the root name server for the network, which has two internal TLD (top level domain, like .com or .net) on it.

===== 100.64.11.11 - ns1.cghmn =====
This is the root name server for the .retro and .cghmn TLDs, as well as the 100.in-addr.arpa reverse lookup zone. This server exists to delegate domains to members of CGHMN, and serve as the name server for the internal network. This server is useful to perform a <code>dig</code> or <code>nslookup</code> against if you want to see if a subdomain has been delegated, for example:

<code>dig ns example.retro. @100.64.11.11</code>

or
nslookup

> server 100.64.11.11

> set type=ns

> example.retro.
This server does not perform lookups. It is currently running BIND.

===== <s>172.23.4.105</s> =====
<s>This is the recursive lookup server for the network. It is configured to recursively look up all requests for CGHMN domains, starting with ns1.cghmn, and then moving up based on delegations to member servers. Regular lookups still take place against real TLDs, if something needs to be pulled off the internet. This server is currently running BIND. This server is useful to use <code>dig</code> or <code>nslookup</code> against if you wish to see if your domain is resolving on the network after it has been delegated to you.</s>

<code><s>dig a test.example.retro. @172.23.4.105</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.105

> set type=a

> test.example.retro.</s>

===== <s>172.23.4.104 - legacydns.cghmhn</s> =====
<s>This is a dnsmasq server that is currently being used to perform modifications to DNS answers, by pulling from a list of servers that need to be faked in order to make old software, such as AIM, work correctly. This server overrides the DNS answer with these responses, so all relevant DNS records need to be added. The rationale for this is that instead of a user modifying their hosts file (which can be dozens of different DNS addresses long) we can simply return addresses that correspond within the network. Please ask if there is a service you would like added to the network that requires this kind of override. Otherwise, it just forwards the questions to the recursive lookup server 172.23.4.105. This server is useful to test against if you are having trouble connecting to a legacy service that utilizes hard coded DNS.</s>

<code><s>dig cname login.oscar.aol.com.</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.104

> set type=cname

> login.oscar.aol.com.</s>

===== 100.64.12.1 or 100.64.11.1 =====
This is the core router for the network, which also serves as a DNS forwarding. It forwards requests to .retro and .cghmn to ns1.cghmn, whilst resolving some legacy DNS overrides and custom DNS domains according to its local configuration. To get a list of domains for which this DNS resolver has overrides or local forwards configured, you can cURL/wget this URL: http://100.64.12.1:8080/dns-forward-domains.txt or if you're running dnsmasq as your resolver at home, directly include the configuration file available at http://100.64.12.1:8080/dns-forward-domains.dnsmasq.conf.

== Hosting Your Own DNS Name Server ==

=== About self-hosting ===
CGHMN can host member DNS zones on its nameserver, however it is welcome and even encouraged for them to explore setting up their own DNS name server for their subnet. This can be done with most DNS server software, provided they can be recursively looked up against by BIND. Please note that if you intend to run old Microsoft DNS, you will need to let us know that you are running it, as exceptions to the lookup procedure need to be added to the 172.23.4.105 server.

You will need to reach out to CGHMN and let us know you want to host your domain, and give us the domain, NS record, A record, and IP address of the DNS server.

=== What you need ===

==== A server ====
You will need a computer connected to CGHMN, running a DNS server software that is able to act as an authoritative name server. It will need to have UDP port 53 and TCP port 53 allowed in its firewall. You do not need a lot of power, but it should be fairly reliable as everything will depend on it to find your servers and services.

==== A SOA record ====
You will need a SOA (Start of Authority) record, this is the record that tells other DNS servers "I am in charge of this domain and here is the information about it". This record will need to be pointed to an NS (Name Server) record.

==== A NS record ====
You will need a NS record, this is the record that says "this is where you ask about this domain". This record should point at an A record.

==== An A record ====
You will need an A record, this is the record that maps the name of the DNS server to an IP address. This should be the FQDN (Fully Qualified Domain Name) of the DNS server, and the IP address it is listening to.

==== Summary ====
Your server will need to be configured as an authoritative name server. To do this, it must run a DNS name server software, which should have a zone containing an the SOA, which points at the NS, which points at the A.

== DNS Quirks ==

=== Windows DNS ===
Old Windows DNS servers will misbehave when BIND's recursive lookup server attempts to do a lookup against them, and will end in failure. The way around this is to disable edns lookups against this particular server in the BIND configuration. Bind is supposed to attempt again with edns disabled but it seems with Windows DNS specifically to fail.

=== DNS manipulation with multiple RR types ===
If a record is being looked up, and this record was once an A record, but still exists and is now a CNAME record, you will have an issue where the lookup will work with tools, but fail with actual lookups. This is because the CNAME record being returned from the real DNS server will take precedent over the fake A record. To resolve this issue, you have to fake both the CNAME and the A record.

== dnsmasq Synchronization Script ==
Since the CGHMN offers custom TLDs, keeping up with which domains are part of the CGHNM can become quite difficult. For this, @Snep built a small script (which is rather hacky, but works) that can be added on Linux systems which have dnsmasq running as their DNS resolver. It only needs <code>wget</code>, <code>grep</code> and <code>md5sum</code> (the BusyBox variants shipped with OpenWRT are fine). Download the following script to your router, for example into your root directory:
wget -O /root/update-dns-forwards.sh "https://raw.githubusercontent.com/CGHMN/openwrt-connect-script/refs/heads/main/openwrt/update-dns-forwards.sh"
Next, run it manually once to make sure the CGHMN DNS configuration file exists and the script runs through without issue:
/bin/sh /root/update-dns-forwards.sh
Then, you can include the newly created configuration file in your dnsmasq instance. For OpenWRT devices, nagivate to Network -> DHCP and DNS -> Forwards and add <code>/etc/cghmn-domains.dnsmasq.conf</code> in the "Additional servers file" field, then hit "Save & Apply". On other systems, append the following line to your <code>dnsmasq.conf</code> file:
conf-file=/etc/cghmn-domains.dnsmasq.conf
Finally, to have the list get updated automatically every 15 minutes, add the following to your crontab (e.g. <code>crontab -e</code> as root):
*/15 * * * * /bin/sh /root/update-dns-forwards.sh
[[Category:Compu-Global-Hyper-Mega-Net]]

CGHMN DNS Information

2026-02-15T01:58:12Z

Snep: Add dnsmasq sync script

== About this page ==
This page exists to document information about the DNS of CGHMN, and some of the complexities that comes with a DNS infrastructure made of up varying platforms across decades of the protocol's evolution. See [[CGHMN-Demo-Network]] for detailed information about the underlying infrastructure

== DNS Configuration Guide ==

=== Getting Started ===

==== Pointing to the right DNS server ====
CGHMN has several DNS servers in use for differing purposes. '''The correct default DNS server you should be pointing at while getting started is 100.64.21.1 from the core network, or 100.89.128.0 from the Wireguard tunnel'''. This is the router, which then forwards the requests to the actual DNS.

==== What the different DNS servers are (or, is this thing on?) ====
CGHMN's DNS is configured such that there are three core servers that perform response modifications to allow the recreation of long defunct services, perform lookups, and act as the root name server for the network, which has two internal TLD (top level domain, like .com or .net) on it.

===== 100.64.11.11 - ns1.cghmn =====
This is the root name server for the .retro and .cghmn TLDs, as well as the 100.in-addr.arpa reverse lookup zone. This server exists to delegate domains to members of CGHMN, and serve as the name server for the internal network. This server is useful to perform a <code>dig</code> or <code>nslookup</code> against if you want to see if a subdomain has been delegated, for example:

<code>dig ns example.retro. @100.64.11.11</code>

or
nslookup

> server 100.64.11.11

> set type=ns

> example.retro.
This server does not perform lookups. It is currently running BIND.

===== <s>172.23.4.105</s> =====
<s>This is the recursive lookup server for the network. It is configured to recursively look up all requests for CGHMN domains, starting with ns1.cghmn, and then moving up based on delegations to member servers. Regular lookups still take place against real TLDs, if something needs to be pulled off the internet. This server is currently running BIND. This server is useful to use <code>dig</code> or <code>nslookup</code> against if you wish to see if your domain is resolving on the network after it has been delegated to you.</s>

<code><s>dig a test.example.retro. @172.23.4.105</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.105

> set type=a

> test.example.retro.</s>

===== <s>172.23.4.104 - legacydns.cghmhn</s> =====
<s>This is a dnsmasq server that is currently being used to perform modifications to DNS answers, by pulling from a list of servers that need to be faked in order to make old software, such as AIM, work correctly. This server overrides the DNS answer with these responses, so all relevant DNS records need to be added. The rationale for this is that instead of a user modifying their hosts file (which can be dozens of different DNS addresses long) we can simply return addresses that correspond within the network. Please ask if there is a service you would like added to the network that requires this kind of override. Otherwise, it just forwards the questions to the recursive lookup server 172.23.4.105. This server is useful to test against if you are having trouble connecting to a legacy service that utilizes hard coded DNS.</s>

<code><s>dig cname login.oscar.aol.com.</s></code>

<s>or</s>
<s>nslookup

> server 172.23.4.104

> set type=cname

> login.oscar.aol.com.</s>

===== 100.64.12.1 or 100.64.11.1 =====
This is the core router for the network, which also serves as a DNS forwarding. It forwards requests to .retro and .cghmn to ns1.cghmn, whilst resolving some legacy DNS overrides and custom DNS domains according to its local configuration. To get a list of domains for which this DNS resolver has overrides or local forwards configured, you can cURL/wget this URL: http://100.64.12.1:8080/dns-forward-domains.txt or if you're running dnsmasq as your resolver at home, directly include the configuration file available at http://100.64.12.1:8080/dns-forward-domains.dnsmasq.conf.

== Hosting Your Own DNS Name Server ==

=== About self-hosting ===
CGHMN can host member DNS zones on its nameserver, however it is welcome and even encouraged for them to explore setting up their own DNS name server for their subnet. This can be done with most DNS server software, provided they can be recursively looked up against by BIND. Please note that if you intend to run old Microsoft DNS, you will need to let us know that you are running it, as exceptions to the lookup procedure need to be added to the 172.23.4.105 server.

You will need to reach out to CGHMN and let us know you want to host your domain, and give us the domain, NS record, A record, and IP address of the DNS server.

=== What you need ===

==== A server ====
You will need a computer connected to CGHMN, running a DNS server software that is able to act as an authoritative name server. It will need to have UDP port 53 and TCP port 53 allowed in its firewall. You do not need a lot of power, but it should be fairly reliable as everything will depend on it to find your servers and services.

==== A SOA record ====
You will need a SOA (Start of Authority) record, this is the record that tells other DNS servers "I am in charge of this domain and here is the information about it". This record will need to be pointed to an NS (Name Server) record.

==== A NS record ====
You will need a NS record, this is the record that says "this is where you ask about this domain". This record should point at an A record.

==== An A record ====
You will need an A record, this is the record that maps the name of the DNS server to an IP address. This should be the FQDN (Fully Qualified Domain Name) of the DNS server, and the IP address it is listening to.

==== Summary ====
Your server will need to be configured as an authoritative name server. To do this, it must run a DNS name server software, which should have a zone containing an the SOA, which points at the NS, which points at the A.

== DNS Quirks ==

=== Windows DNS ===
Old Windows DNS servers will misbehave when BIND's recursive lookup server attempts to do a lookup against them, and will end in failure. The way around this is to disable edns lookups against this particular server in the BIND configuration. Bind is supposed to attempt again with edns disabled but it seems with Windows DNS specifically to fail.

=== DNS manipulation with multiple RR types ===
If a record is being looked up, and this record was once an A record, but still exists and is now a CNAME record, you will have an issue where the lookup will work with tools, but fail with actual lookups. This is because the CNAME record being returned from the real DNS server will take precedent over the fake A record. To resolve this issue, you have to fake both the CNAME and the A record.

== dnsmasq Synchronization Script ==
Since the CGHMN offers custom TLDs, keeping up with which domains are part of the CGHNM can become quite difficult. For this, @Snep built a small script (which is rather hacky, but works) that can be added on Linux systems which have dnsmasq running as their DNS resolver. It only needs <code>wget</code> (the BusyBox variant is fine) and <code>md5sum</code>. Insert the following text to <code>/root/update-cghmn-domains.sh</code>:
#!/bin/sh
set -e

# setting static variables

SRC_URL="<nowiki>http://100.64.12.1:8080/dns-forward-domains.dnsmasq.conf</nowiki>"

CONF_FILE=/etc/cghmn-domains.dnsmasq.conf

TMP_CONF_FILE=/tmp/cghmn-domains.dnsmasq.conf

# download dns configuration to temporary location and get its md5 sum

wget -qO "${TMP_CONF_FILE}" "${SRC_URL}"

# get md5 sums of files

old_md5sum="$(md5sum -- "${CONF_FILE}" | cut -d' ' -f1)"

new_md5sum="$(md5sum -- "${TMP_CONF_FILE}" | cut -d' ' -f1)"

# do nothing if the md5sum of the new file is the same as the old

if [ "${old_md5sum}" = "${new_md5sum}" ]; then

exit 0

fi

# test if configuration file is valid

if ! dnsmasq -C "${TMP_CONF_FILE}" --test &>/dev/null; then

echo "New dnsmsq DNS configuration for the CGHMN is invalid" >*2

exit 1

fi

# copy configuration file to permanent location

cp "${TMP_CONF_FILE}" "${CONF_FILE}"

# restart dnsmasq service on changes

service dnsmasq restart
Next, run it manually once to make sure the CGHMN DNS configuration file exists and the script runs through without issue:
/bin/sh /root/update-cghmn-domains.sh
Then, you can include the newly created configuration file in your dnsmasq instance. For OpenWRT devices, nagivate to Network -> DHCP and DNS -> Forwards and add <code>/etc/cghmn-domains.dnsmasq.conf</code> in the "Additional servers file" field, then hit "Save & Apply". On other systems, append the following line to your <code>dnsmasq.conf</code> file:
conf-file=/etc/cghmn-domains.dnsmasq.conf
Finally, to have the list get updated automatically every 15 minutes, add the following to your crontab (e.g. <code>crontab -e</code> as root):
*/15 * * * * /bin/sh /root/update-cghmn-domains.sh
[[Category:Compu-Global-Hyper-Mega-Net]]

CGHMN 1.0

2026-02-03T21:24:50Z

Snep: Added stuff to my to-do

[[Category:Compu-Global-Hyper-Mega-Net]]
'''Ideally I wanna have this ready by April 24th 2026? Being able to do a talk and be like "by the way we just launched it go sign up" would be huge'''

== Tracking sheet for "what would we want in a general 1.0 release" ==

Let's break these down by user just to keep division of labor easy. This isn't a "we will do this" so much as a "request for comments"

=== CursedSilicon suggestions ===

We can trivially set up an OpenWRT build bot. But a custom splash screen that just asks for a users Wireguard+IP details would be fantastic for user onboarding. Need someone who can write Lua to do this though

=== ch0ccyra1n suggestions ===
<s>We should ensure that there is a better way to do onboarding. Some sort of web form on the clearnet for signups (or signup requests) would be good to have.<big>'''['''</big></s><big>'''[https://signup.cghmn.org done]]'''</big>

=== Sneps ToDo- and Wishlist: ===

* Create an IP plan, removing the 172.23.0.0/16 subnet and planing ahead for distributed CGHMN entry nodes across the world
* Storage Situation on the OVH Proxmox, either switch to thin provisioned VM disks or have a shared storage server with SMB and NFS?
* Proper backups of the CGHMN Proxmox box
* Separate Wireguard tunnels for admin work/cote hosting and members, so that not everything breaks down for 15 seconds when new clients are added
* Distributed network entry points across the world
* Blog for Updates and Changes on the CGHMN?
* Forum?
* Some form of ticket systembug tracker via e-mail for reporting and organizing issues and member feature wishes?
* Move the GRETAP tunnels to the Wireguard server and add them to the API to be created and destroyed automatically
* Dynamic Routing of members across servers?
* Set up EU server
* Central maintenance tunnel into the PVEs

CGHMN 1.0

2026-01-11T05:48:13Z

Snep:

[[Category:Compu-Global-Hyper-Mega-Net]]
'''Ideally I wanna have this ready by April 24th 2026? Being able to do a talk and be like "by the way we just launched it go sign up" would be huge'''

== Tracking sheet for "what would we want in a general 1.0 release" ==

Let's break these down by user just to keep division of labor easy. This isn't a "we will do this" so much as a "request for comments"

=== CursedSilicon suggestions ===

We can trivially set up an OpenWRT build bot. But a custom splash screen that just asks for a users Wireguard+IP details would be fantastic for user onboarding. Need someone who can write Lua to do this though

=== ch0ccyra1n suggestions ===
<s>We should ensure that there is a better way to do onboarding. Some sort of web form on the clearnet for signups (or signup requests) would be good to have.<big>'''['''</big></s><big>'''[https://signup.cghmn.org done]]'''</big>

=== Sneps ToDo- and Wishlist: ===

* Create an IP plan, removing the 172.23.0.0/16 subnet and planing ahead for distributed CGHMN entry nodes across the world
* Storage Situation on the OVH Proxmox, either switch to thin provisioned VM disks or have a shared storage server with SMB and NFS?
* Proper backups of the CGHMN Proxmox box
* Separate Wireguard tunnels for admin work/cote hosting and members, so that not everything breaks down for 15 seconds when new clients are added
* Distributed network entry points across the world
* Blog for Updates and Changes on the CGHMN?
* Forum?
* Move the GRETAP tunnels to the Wireguard server and add them to the API to be created and destroyed automatically
* Dynamic Routing of members across servers?
* Set up EU server
* Central maintenance tunnel into the PVEs

CGHMN-IP-Allocations

2025-12-25T00:41:44Z

Snep:

=== IP Address Allocations in the CGHMN Network ===
This page documents any IP addresses that are allocated statically to routers, subnets and members.

=== Networks on the CGHMN side ===
This is a list of all networks active on the CGHMN server side.
{| class="wikitable"
|+
!Network Name
!VLAN
!Subnet
!Router IP
!Notes
|-
|Core Services
| -
|100.64.11.0/24
|100.64.1.1
| -
|-
|CGHMN VMs
| -
| 100.64.21.0/24
| 100.64.21.1
| -
|-
|Wireguard Members Tunnel
| -
|100.89.128.0/22
|100.89.128.0
|The .0 for the router is not a typo, on P2P links the network address can also be used for a host
|}

=== Members' Networks ===
This list contains the subnets that are assigned to member routers on the network. Members which need routed subnets receive one <code>/24</code> network from the <code>100.96.0.0/13</code> block, in first-come-first-serve sequential order per default. Members who only need a single IP receive an IP from the <code>100.96.0.0/24</code> block, in first-come-first-serve sequential order per default.
{| class="wikitable"
|+
!Member Name
!Peer Endpoint/Via
!Tunnel IP
!Routed Subnet(s)
!Notes
|-
|CursedSilicon
|/dev/hack (usually)
|100.89.128.1
|100.96.1.0/24
| -
|-
|Talija
| DIY
|100.89.128.2
|100.96.2.0/24
| -
|-
|Snep
|OPNsense box and PPPoE server
|100.89.128.3
|100.96.3.0/24
| -
|-
|Snep
|PC VPN tunnel
|100.89.128.4
| -
| -
|-
|Hadn69
| DIY
|100.89.128.5
|100.96.5.0/24
| -
|-
|Lily
| Dell PowerEdge R620
|100.89.128.6
|100.96.6.0/24
| -
|-
|Theothertom
| Unknown
|100.89.128.7
|100.96.7.0/24
| -
|-
|Lily
| Raspberry Pi
|100.89.128.8
|100.96.8.0/24
| -
|-
|Loganius
| PPTP Bridge on Debian VM
|100.89.128.9
|100.96.9.0/24
| Using Microsoft Virtual Server 2005 under Windows Server 2003.
|-
|GothPanda
| OpenWRT
|100.89.128.10
|100.96.10.0/24
| TP-Link Archer C59 v2
|-
|ch0ccyra1n
| Unknown
|100.89.128.11
|100.96.11.0/24
| -
|-
|Chromaryu
|Unknown
|100.89.128.12
|100.96.12.0/24
| -
|-
|Serena
|Unknown
|100.89.128.13
|100.96.13.0/24
|Chivanet
|-
|CursedSilicon
|OpenWRT VM
|100.89.128.14
|100.96.14.0/24
|At home
|-
|Mel
|OpenWRT VM
|100.89.128.15
|100.96.15.0/24
|"Glinet Nugget"
|-
|Spz2024
|OpenWRT VM
|100.89.128.16
|100.96.16.0/24
| OpenWRT in QEMU on Windows host
|-
|Spaztron64
|Unknown
|100.89.128.17
|100.96.17.0/24
| -
|-
|Harry
|Unknown
|100.89.128.18
|100.96.18.0/24
| -
|-
|Mel
|OpenWRT VM
|100.89.128.19
|100.96.19.0/24
|OpenWRT VM
|-
|Spaztron64
|Unknown
|100.89.128.20
|100.96.20.0/24
| -
|-
|TsuboDii
|Unknown
|100.89.128.21
|100.96.21.0/24
| -
|-
|j4yc33
|Unknown
|100.89.128.22
|100.96.22.0/24
| -
|-
|CursedSilicon
|Unknown
|100.89.128.23
|100.96.23.0/24
|"Travel Router"
|-
|Dusty
|Unknown
|100.89.128.24
|100.96.24.0/24
| -
|-
|Nicuuut
|Unknown
|100.89.128.25
|100.96.25.0/24
| -
|-
|Tyler McVicker
|Unknown
|100.89.128.26
|100.96.26.0/24
|"Game Servers"
|-
|YoungChief
|Unknown
|100.89.128.27
|100.96.27.0/24
| -
|-
|Zefie
|Unknown
|100.89.128.28
|100.96.28.0/24
| -
|-
|CH
|Unknown
|100.89.128.29
|100.96.29.0/24
| -
|-
|Alyx
|Unknown
|100.89.128.30
|100.96.30.0/24
| -
|-
|Alyx
|Unknown
|100.89.128.31
|100.96.31.0/24
|"Datacenter"
|-
|Grawity
|Unknown
|100.89.128.32
|100.96.32.0/24
| -
|-
|pmc
|Unknown
|100.89.128.33
|100.96.33.0/24
| -
|-
|kirb
|Unknown
|100.89.128.34
|100.96.34.0/24
| -
|-
|GothPanda
|Unknown
|100.96.0.1
|N/A
|Proxy
|-
|Loganius
|Lenovo Yoga 6 that's falling apart.
|100.96.0.2
|N/A
|Travel
|-
|i430vx
|Unknown
|100.89.128.35
|100.96.35.0/24
| -
|-
|rwf93
|Unknown
|100.89.128.36
|100.96.36.0/24
| -
|-
|accipitroid
|Unknown
|100.89.128.37
|100.96.37.0/24
| -
|}

=== Member-Delegated (Sub-) Domains ===
{| class="wikitable"
|+
!Member Name
!Domain
!Nameserver
!Nameserver IP
!Notes
|-
|Serena
|chivanet
|pandora.chivanet
|100.96.13.7
| -
|-
|Nicuuut
|goat
|sanemi.nicuuut.goat
|172.23.0.53
| -
|-
|Talija
|coyote.retro
|a.ns.coyote.retro
|100.96.2.53
| -
|-
|''Snep''
|''snep.retro''
|''ns1.snep.retro''
|''172.23.8.11''
| Currently offline
|-
|Lily
|lily.retro
|ns1.lily.retro
|100.96.6.250
| -
|-
|Loganius
|loganius.retro
|kirk.loganius.retro
|100.96.9.3
| -
|-
|theothertom
|theothertom.retro
|north-foreland.theothertom.retro
|100.96.7.12
| -
|-
|Spaztron64
|arcesia.retro
|ns.arcesia.retro
|100.96.17.105
| -
|-
|ch0ccyra1n
|oohay.retro
|ns1.oohay.retro
|100.96.11.197
| -
|-
|Harry
|404.retro
|ns.404.retro
|100.96.18.254
| -
|-
|GothPanda
|northstar.retro
|ns1.northstar.retro
|172.23.3.201
| -
|-
|Loganius
|askme.retro
|kirk.loganius.retro
|100.96.9.3
| -
|}

=== Member Servers hosted on the CGHMN side ===
{| class="wikitable"
|+
!Member Name
!VM/CT ID
!Server Name
!Server IP
!Notes
|-
|Snep
|10811
|srv01.snep.retro
|172.23.8.11
| -
|-
|Talija
|118
|junko.coyote.retro
|172.23.3.173
|Network diagnostics
|-
|Loganius
|123
|kira.loganius.retro
|172.23.0.52
|WMS Server
|-
|Cursed
|107
|cghmn-mail.retro
|172.23.0.69
|Mail Server
|-
|Nicuuut
|124
|sanemi.nicuuut.goat
|172.23.0.53
| -
|-
|Nicuuut
|103
|mitsuri.nicuuut.goat
|172.23.0.54
| -
|-
|GothPanda
|104
|litwick.northstar.retro
|172.23.3.201
|also hosts tests.cghmn
|-
|Loganius
|109
|worf.loganius.retro
|172.23.0.55
|ILS Server (for MS NetMeeting)
|-
|Loganius
|10056
|elim.loganius.retro
|172.23.0.56
|Minecraft Reverse Proxy Server
|}
[[Category:Compu-Global-Hyper-Mega-Net]]

CGHMN DNS Information

2025-12-25T00:41:15Z

Snep:

CGHMN Certificate Authority

2025-12-25T00:36:58Z

Snep:

=== The CGHMN Certificate Authority ===
... is used to create internal certificates for old SSL and TLS applications with our custom domains .cghmn and .retro, which cannot receive actual, real world publicly trusted certificates.

To trust those certificates, navigate to http://certs.cghmn, download the Root CA certificate and install it into your operating systems root CA store.

'''WARNING:''' Only do this on retro machines that are attached to the CGHMN, don't do this on modern machines with data you care for and websites you'd rather not have potentially [[wikipedia:Man-in-the-middle_attack|MITM]]'ed. Installing and trustig the Root CA certificate would allow us (or anyone that has access to the root CA public and private keys together with the signing password) to create whatever certificate we like for any domain name out there and fool your OS into thinking it can trust that self-signed certificate.

Alternatively, you can always just click "Trust this page" or similar in your web browser and most applications that rely on SSL/TLS have some option to disable CA checking.

=== How to obtain a certificate for your .cghmn or .retro domain ===
If you'd like a certificate for your CGHMN internal domain, ping one of the admins in the Discord channel and pass along the following infos:

* Domain Name: The domain you'd like to receive a certificate for
* How to best send you your certificate, e.g. Discord DMs, E-Mail, some Messenger, Filesharing service etc., best not through a public channel
* Optionally:
** If you want a wildcard certificate, i.e. one certificate for the domain above and all subdomains underneath that domain (e.g. *.example.org)
** If you'd like the private key to be protected with a randomly generated password
** What two letter code to fill into the "Country" field of the certificate, default is "XX"
** What to fill into the "State or Province" field of the certificate, default is "Global"
** What to fill into the "Locality" field of the certificate, defaut is "The Internet"
** What to fill into the "Organization Name" field of the certificate, default is "Compu Global Hyper Mega Network"
** What to fill into the "Organizational Unit" field of the certificate, default is your username
** What to fill into the "E-Mail" field of the certificate, default is "complain@mail.cghmn"
** ''All of the above can be freely chosen and be whatever you like''

Then we'll create the certificate, private key and full chain certificate and send it over so you can install it into whatever service you like!

=== How to generate a certificate - For CGHMN Admins ===
[[File:Example Certificate Script Run.png|thumb|Script Example Output]]
To generate a members' certificate, <code>ssh</code> or <code>pct enter</code> into Container <code>11013</code> with IP address 100.64.11.13. In the root directory should be a Bash script called <code>create-and-sign-server-csr.sh</code>, run it with <code>bash /root/create-and-sign-server-csr.sh</code>.

It will first ask you what the output files should be called, it's best to enter something that associates the file with the target domain or member, e.g. the domain itself or the members' username. It's recommended to only use alpha-numerical characters, dashes, underscores and dots.

Next, you're asked if the key shall be protected with a password. If the member didn't specify or doesn't want one, you can just press '''Enter''' on this step to select the default value of ''not'' using a password. Otherwise type '''y''' and press '''Enter''' to confirm, then generate a random password with a website, tool or password manager of your choice and input said password in the "Enter PEM pass phrase" prompt. The password needs to be at least 4 characters long!

The next step asks you for the hostnames of the certificate. Enter all hostnames you want the certificate to be valid for, e.g. <code>example.retro</code>, <code>www.example.retro</code> and <code>mail.example.retro</code>. If the member requested a wildcard certificate, enter the base domain first, e.g. <code>example.retro</code>, followed by the wildcard domain, e.g. <code>*.example.retro</code>. Once all domain names are entered, press '''Ctrl+D''' to confirm.

If you've specified '''y''' at the question above if the private key should be password protected, you will next be asked to re-enter that password.

Next, you'll be asked for the Common Name, there enter the base domain for which the certificate is valid, e.g. '''example.retro'''.

Then, some certificate options can be set like Country, Organization and E-Mail assigned with the certificate, which are most of the optional details listed above that the member can specify if they like, which does not need to be real data, it can be whatever they like. Otherwise, just press '''Enter''' on the fields to select the predefined default values.

The next password requested from you is the Intermediate CA Signing Password, followed by two confirmations if you really really want to sign the new certificates with our intermediate CA. Input '''y''' and press '''Enter''' both times.

Now the certificate is created and ready for use, the script will tell you into which directory it has written the certificate files.

All that's left to do now is to SCP the files off the CA container and send them over to the member in a secure-ish fashion through their prefered channel. Don't send them in the Discord channel unless they're fine with it since it allows someone else to more easily impersonate their site, not that that's a huge concern in the CGHMN network, but still.

CGHMN 1.0

2025-12-25T00:26:32Z

Snep:

[[Category:Compu-Global-Hyper-Mega-Net]]
'''Ideally I wanna have this ready by April 24th 2026? Being able to do a talk and be like "by the way we just launched it go sign up" would be huge'''

== Tracking sheet for "what would we want in a general 1.0 release" ==

Let's break these down by user just to keep division of labor easy. This isn't a "we will do this" so much as a "request for comments"

=== CursedSilicon suggestions ===

We can trivially set up an OpenWRT build bot. But a custom splash screen that just asks for a users Wireguard+IP details would be fantastic for user onboarding. Need someone who can write Lua to do this though

=== ch0ccyra1n suggestions ===
<s>We should ensure that there is a better way to do onboarding. Some sort of web form on the clearnet for signups (or signup requests) would be good to have.<big>'''['''</big></s><big>'''[https://signup.cghmn.org done]]'''</big>

=== Sneps ToDo- and Wishlist: ===

* Create an IP plan, removing the 172.23.0.0/16 subnet and planing ahead for distributed CGHMN entry nodes across the world
* Storage Situation on the OVH Proxmox, either switch to thin provisioned VM disks or have a shared storage server with SMB and NFS?
* Proper backups of the CGHMN Proxmox box
* Separate Wireguard tunnels for admin work/cote hosting and members, so that not everything breaks down for 15 seconds when new clients are added
* Distributed network entry points across the world
* Blog for Updates and Changes on the CGHMN?
* Forum?
* Move the GRETAP tunnels to the Wireguard server and add them to the API to be created and destroyed automatically
* Dynamic Routing of members across servers?
* Set up EU server

How to Get Connected

2025-12-25T00:23:22Z

Snep:

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "open beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server. If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code printout of your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 100.64.0.0/10
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== <s>Get connected - Server Side, the Admins Guide</s> ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do '''either one''' '''(not both!)''' of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

==== Explore things available on the network ====
There is a collection of [[services people are running]] - things like email/hosting/chat/search/etc.

CGHMN 1.0

2025-11-22T14:01:29Z

Snep: Add some stuff to my (Snep) ToDo list

CGHMN 1.0

2025-11-19T13:17:16Z

Snep: Added some stuff to my todo list

CGHMN 1.0

2025-11-06T22:50:06Z

Snep: Added my (Sneps) changes

[[Category:Compu-Global-Hyper-Mega-Net]]
== Tracking sheet for "what would we want in a general 1.0 release" ==

Let's break these down by user just to keep division of labor easy. This isn't a "we will do this" so much as a "request for comments"

=== CursedSilicon suggestions ===

We can trivially set up an OpenWRT build bot. But a custom splash screen that just asks for a users Wireguard+IP details would be fantastic for user onboarding. Need someone who can write Lua to do this though

=== ch0ccyra1n suggestions ===
<s>We should ensure that there is a better way to do onboarding. Some sort of web form on the clearnet for signups (or signup requests) would be good to have.<big>'''['''</big></s><big>'''[https://signup.cghmn.org done]]'''</big>

=== Sneps ToDo- and Wishlist: ===

* Create an IP plan, removing the 172.23.0.0/16 subnet and planing ahead for distributed CGHMN entry nodes across the world
* Storage Situation on the OVH Proxmox, either switch to thin provisioned VM disks or have a shared storage server with SMB and NFS?
* Proper backups of the CGHMN Proxmox box

CGHMN NAT and Firewalls

2025-10-27T12:30:06Z

Snep: Small adjustment in the last sentence on how to allow inbound ports for clearer instructions on where to set up the rules

=== A brief history on how the internet worked in the 1990's ===

[[Compu-Global-Hyper-Mega-Net|Compu-Global-Hyper-Mega-Net (CGHMN)]] exists in a difficult kind of space. We aim to emulate "the old web". A time of roughly "1995 to around 2005 or so". A sort of nebulous "Before Web 2.0 took off" kind of period. Though, really we support anything that speaks ethernet and (usually) TCP/IP. We've had devices as old as a DOS 286 PC clone connected successfully. Most users trend toward Windows XP as their platform of choice due to its relative flexibility and widespread hardware and software support

Unfortunately for all of us we live at the "[[wikipedia:End_of_history|end of history]]". In 1995 the "World Wide Web" was in its infancy in such a way that every single year brought quantum technological leaps over the previous year. By the end of the millennium we'd gone from rudimentary analog Dial-Up services to ''Wireless Networking'' being accessible to consumers (Apple's AirPort routers alone showed up in 1999)

However on a technical level this began to create severe issues. The internet as it was originally designed assumed simple "end-to-end" connectivity. Every computer on the internet could (more or less) talk to another computer without exception.

<big>'''This created two major problems:'''</big>

The first one was IP exhaustion. Even by the 1990's there was an understanding that there simply wouldn't be enough IP addresses for everyone on the internet. This needed to be fixed, and fast! This lead to IPv6 as an evolutionary upgrade (a problem the internet still struggles to even deploy in 2025, despite being ratified in 1998)

The second, and much more obvious problem was security. By the year 2000 it was obviously apparent that every machine being able to talk to every other machine on Earth was a problem. Particularly when the dominant operating system these machines ran was what could be charitably described as..."not great" in terms of security. In the 2000's this would only escalate as the "[[wikipedia:ILOVEYOU|ILOVEYOU]]" worm gave way to some of Windows XP's greatest hits, [[wikipedia:Blaster_(computer_worm)|Blaster]], [[wikipedia:Sasser_(computer_worm)|Sasser]], [[wikipedia:Mydoom|Mydoom]], [[wikipedia:Nimda|Nimda]] and [[wikipedia:Conficker|Conficker]]. Among others.

A remedy proposed in the 1990's to the issue of IP exhaustion was "Network Address Translation" or "NAT". In layman terms this allows a bunch of computers to all sit behind a single IP address using a device such as a router. This technology is so ubiquitous that even in 2025 at time of writing it's still the defacto standard for home and business computers and other devices to access the modern internet.

'''''However,''''' this technology came at a cost. The internet as most folks imagine (or remember it) was originally built on the idea that every computer had its own, unique, IP address. NAT broke that assumption. And, in doing so, programs broke. Sometimes completely with services like FTP, sometimes in subtle ways. Like being unable to connect certain game players in a StarCraft lobby.

The problem that NAT introduced was that while "outbound" traffic would work fine. Such as you connecting to a website. If a program needed to ''receive'' data on your local computer, it could no longer simply sit and wait for a connection from a remote PC. An example would be AOL Instant Messenger (AIM). Chats between users are routed through a remote server. You and the Other User talk to a central server and it handles sending messages to-and-fro. ''However'' to save on bandwidth, sending files happens directly between users. If either user is behind NAT. They won't be able to "see" the remote computer and send data to it as desired.

The "solution" to this problem is known as '''''Port Forwarding'''''. You tell your router that [these ports] *always* go to [this IP address on the LAN] exclusively. This (mostly) solved the problem at the time. Additional solutions were proposed such as "UPnP" to allow programs to ask the router to forward ports for them dynamically. However, support for this was few-and-far-between (mostly BitTorrent clients) and in time it faded into oblivion.

As stated before, we live at the end of history. Which means we have the benefit of looking back on what was, and understanding the flaws. Which (finally) brings us to the point of this wiki page.

=== Okay but what does that have to do with CGHMN? ===
Every CGHMN user is allocated a /24 block of IP's. Effectively every user has 253 IP addresses to use as they'd like. This was a deliberate decision both to maximize the amount of freedom users would have to connect ALL their retro equipment if desired, and to try and allow direct end-to-end connectivity that the old web "expects"

'''''However''''' because we have the benefit of historical hindsight. Having directly allocated IP addresses does not mean that your devices are directly exposed to the network. By default (if using OpenWRT with Snep's setup script) your IP block will be ''firewalled'' against incoming connections. This is a necessary security measure because because of the very nature of "running a retro network". Connecting machines that are (likely) un-patched would make them immediately vulnerable to attack. Even before they're properly configured for service by the end user.

=== So, what stuff breaks, exactly? ===

There's no definitive list of "what" breaks under this decision. A broad (but by no means encompassing) list of things that ''won't work'' are

- Servers. You won't be able to run any kind of server or service (EG: hosting your own website, running a game server) without the ability for users to connect to it

- Games that '''''don't''''' use a server browser. Games like Quake or Halo where users all connect to a single server to play on will work (provided the server is either port forwarded or the firewall is disabled) but other games such as StarCraft or Command & Conquer have players connect dynamically connect to a single player as the "host" (typically the player that created the game lobby). These will not work

- FTP! FTP is such an old protocol that the '''''remote server''''' initiates a connection back to the client and then begins sending files that way. This was fixed in [https://datatracker.ietf.org/doc/html/rfc1579 RFC 1579] with the "Firewall-Friendly FTP" proposal. Unfortunately despite being proposed in February 1994, some software such as Microsoft FrontPage did not enable it until 2003(!)

- AIM file transfers. As described already on this wiki page, AIM (and IRC and other chat clients such as MSN or Yahoo) all use a direct connection between two computers to send files across a network

=== How do I opt-out out? ===
 

 

<big>'''It should be made completely clear that opting out of using the OpenWRT firewall is not a decision that should be made lightly. We cannot explicitly guarantee that a user won't accidentally (or intentionally) release a malware Pandora's Box on the network. Blaster/Sasser/Mydoom/ILOVEYOU/etc are still real malware samples that can be downloaded and executed either by mistake or by a malicious user. We highly recommend installing any and all software patches that were (or are) available for your chosen systems before doing this!'''</big>

There are two "modes" of opt-out available. Depending on user preference.

The most drastic is simply to disable OpenWRT's firewall completely. This means any machine you plug in will have direct access to the network and any other devices on the network will be able to directly access it. If you choose this option we highly recommend putting any machines behind a (preferably modern!) Firewall and then port forwarding as necessary

The other option is to set a static (fixed) IP address on the device you want to run servers or play games from. Once this is done you can access the OpenWRT Firewall page (Network -> Firewall -> Traffic Rules) and manually allow the required ports for that specific host to pass the firewall.

CGHMN-IP-Allocations

2025-06-15T06:00:45Z

Snep: Added cursed's mail server IP dibs

How to Get Connected

2025-05-26T13:38:25Z

Snep: Slight updates to the setup script

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

'''Since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation'''

=== Step 1: ===
[[Signup|'''Let us know you'd like to connect!''']]

(We'll need information from you such as your Wireguard Pubkey to let you connect to the network)[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router: <code>wget https://cghmn.snep.zip/connect.sh</code>
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server. If you cannot copy-paste, for example, because you're on a VM VNC console, you can run <code>ash setup-cghmn.sh pubkey-qr</code> to get a QR code printout of your public key, which can be scanned with a phone, tablet or software QR code parser to get the key as copy-pastable text.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 172.23.0.0/16, 100.89.128.0/22, 100.96.0.0/13
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do '''either one''' '''(not both!)''' of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

=== After you get connected ===
There are a few optional things you might want to do.

==== Network mailing list ====
There is a mailing list you can subscribe to if you want to be notified about things that may affect CGHMN or core services. You can subscribe to the list here: https://berwick-upon-tweed.cobaltqu.be/postorius/lists/cghmn-announce.lists.cobaltqu.be/.

If you need to post to the list, you will need to subscribe before you can be added to the list of poster.

CGHMN-IP-Allocations

2025-05-25T21:33:01Z

Snep:

CGHMN DNS Information

2025-05-16T06:49:26Z

Snep: Added info about default DNS being 100.89.128.0 in the WG tunnel

== About this page ==
This page exists to document information about the DNS of CGHMN, and some of the complexities that comes with a DNS infrastructure made of up varying platforms across decades of the protocol's evolution. See [[CGHMN-Demo-Network]] for detailed information about the underlying infrastructure

== DNS Configuration Guide ==

=== Getting Started ===

==== Pointing to the right DNS server ====
CGHMN has several DNS servers in use for differing purposes. '''The correct default DNS server you should be pointing at while getting started is 172.23.0.1 from the core network, or 100.89.128.0 from the Wireguard tunnel'''. This is the router, which then forwards the requests to the actual DNS.

==== What the different DNS servers are (or, is this thing on?) ====
CGHMN's DNS is configured such that there are three core servers that perform response modifications to allow the recreation of long defunct services, perform lookups, and act as the root name server for the network, which has two internal TLD (top level domain, like .com or .net) on it.

===== 172.23.4.101 - ns1.cghmn =====
This is the root name server for the .retro and .cghmn TLDs, as well as the 23.172.in-addr.arpa and 96.100.in-addr.arpa reverse lookup zones. This server exists to delegate domains to members of CGHMN, and serve as the name server for the internal network. This server is useful to perform a <code>dig</code> or <code>nslookup</code> against if you want to see if a subdomain has been delegated, for example:

<code>dig ns example.retro. @172.23.4.101</code>

or
nslookup

> server 172.23.4.101

> set type=ns

> example.retro.
This server does not perform lookups. It is currently running BIND.

===== 172.23.4.105 =====
This is the recursive lookup server for the network. It is configured to recursively look up all requests for CGHMN domains, starting with ns1.cghmn, and then moving up based on delegations to member servers. Regular lookups still take place against real TLDs, if something needs to be pulled off the internet. This server is currently running BIND. This server is useful to use <code>dig</code> or <code>nslookup</code> against if you wish to see if your domain is resolving on the network after it has been delegated to you.

<code>dig a test.example.retro. @172.23.4.105</code>

or
nslookup

> server 172.23.4.105

> set type=a

> test.example.retro.

===== 172.23.4.104 - legacydns.cghmhn =====
This is a dnsmasq server that is currently being used to perform modifications to DNS answers, by pulling from a list of servers that need to be faked in order to make old software, such as AIM, work correctly. This server overrides the DNS answer with these responses, so all relevant DNS records need to be added. The rationale for this is that instead of a user modifying their hosts file (which can be dozens of different DNS addresses long) we can simply return addresses that correspond within the network. Please ask if there is a service you would like added to the network that requires this kind of override. Otherwise, it just forwards the questions to the recursive lookup server 172.23.4.105. This server is useful to test against if you are having trouble connecting to a legacy service that utilizes hard coded DNS.

<code>dig cname login.oscar.aol.com.</code>

or
nslookup

> server 172.23.4.104

> set type=cname

> login.oscar.aol.com.

===== 172.23.0.1 =====
This is the core router for the network, which also serves as a DNS forwarding. It is currently forwarding all traffic to legacydns.cghmn, and performs no additional lookups or translation. This server is useful to test against for any purpose.

== Hosting Your Own DNS Name Server ==

=== About self-hosting ===
CGHMN can host member DNS zones on its nameserver, however it is welcome and even encouraged for them to explore setting up their own DNS name server for their subnet. This can be done with most DNS server software, provided they can be recursively looked up against by BIND. Please note that if you intend to run old Microsoft DNS, you will need to let us know that you are running it, as exceptions to the lookup procedure need to be added to the 172.23.4.105 server.

You will need to reach out to CGHMN and let us know you want to host your domain, and give us the domain, NS record, A record, and IP address of the DNS server.

=== What you need ===

==== A server ====
You will need a computer connected to CGHMN, running a DNS server software that is able to act as an authoritative name server. It will need to have UDP port 53 and TCP port 53 allowed in its firewall. You do not need a lot of power, but it should be fairly reliable as everything will depend on it to find your servers and services.

==== A SOA record ====
You will need a SOA (Start of Authority) record, this is the record that tells other DNS servers "I am in charge of this domain and here is the information about it". This record will need to be pointed to an NS (Name Server) record.

==== A NS record ====
You will need a NS record, this is the record that says "this is where you ask about this domain". This record should point at an A record.

==== An A record ====
You will need an A record, this is the record that maps the name of the DNS server to an IP address. This should be the FQDN (Fully Qualified Domain Name) of the DNS server, and the IP address it is listening to.

==== Summary ====
Your server will need to be configured as an authoritative name server. To do this, it must run a DNS name server software, which should have a zone containing an the SOA, which points at the NS, which points at the A.

== DNS Quirks ==

=== Windows DNS ===
Old Windows DNS servers will misbehave when BIND's recursive lookup server attempts to do a lookup against them, and will end in failure. The way around this is to disable edns lookups against this particular server in the BIND configuration. Bind is supposed to attempt again with edns disabled but it seems with Windows DNS specifically to fail.

=== DNS manipulation with multiple RR types ===
If a record is being looked up, and this record was once an A record, but still exists and is now a CNAME record, you will have an issue where the lookup will work with tools, but fail with actual lookups. This is because the CNAME record being returned from the real DNS server will take precedent over the fake A record. To resolve this issue, you have to fake both the CNAME and the A record.
[[Category:Compu-Global-Hyper-Mega-Net]]

CGHMN Certificate Authority

2025-05-15T20:10:02Z

Snep: Created page

=== The CGHMN Certificate Authority ===
... is used to create internal certificates for old SSL and TLS applications with our custom domains .cghmn and .retro, which cannot receive actual, real world publicly trusted certificates.

To trust those certificates, navigate to http://certs.cghmn, download the Root CA certificate and install it into your operating systems root CA store.

'''WARNING:''' Only do this on retro machines that are attached to the CGHMN, don't do this on modern machines with data you care for and websites you'd rather not have potentially [[wikipedia:Man-in-the-middle_attack|MITM]]'ed. Installing and trustig the Root CA certificate would allow us (or anyone that has access to the root CA public and private keys together with the signing password) to create whatever certificate we like for any domain name out there and fool your OS into thinking it can trust that self-signed certificate.

Alternatively, you can always just click "Trust this page" or similar in your web browser and most applications that rely on SSL/TLS have some option to disable CA checking.

=== How to obtain a certificate for your .cghmn or .retro domain ===
If you'd like a certificate for your CGHMN internal domain, ping one of the admins in the Discord channel and pass along the following infos:

* Domain Name: The domain you'd like to receive a certificate for
* How to best send you your certificate, e.g. Discord DMs, E-Mail, some Messenger, Filesharing service etc., best not through a public channel
* Optionally:
** If you want a wildcard certificate, i.e. one certificate for the domain above and all subdomains underneath that domain (e.g. *.example.org)
** If you'd like the private key to be protected with a randomly generated password
** What two letter code to fill into the "Country" field of the certificate, default is "XX"
** What to fill into the "State or Province" field of the certificate, default is "Global"
** What to fill into the "Locality" field of the certificate, defaut is "The Internet"
** What to fill into the "Organization Name" field of the certificate, default is "Compu Global Hyper Mega Network"
** What to fill into the "Organizational Unit" field of the certificate, default is your username
** What to fill into the "E-Mail" field of the certificate, default is "complain@mail.cghmn"
** ''All of the above can be freely chosen and be whatever you like''

Then we'll create the certificate, private key and full chain certificate and send it over so you can install it into whatever service you like!

=== How to generate a certificate - For CGHMN Admins ===
[[File:Example Certificate Script Run.png|thumb|Script Example Output]]
To generate a members' certificate, <code>ssh</code> or <code>pct enter</code> into Container <code>10402</code> with IP address <code>172.23.4.102</code>. In the root directory should be a Bash script called <code>create-and-sign-server-csr.sh</code>, run it with <code>bash /root/create-and-sign-server-csr.sh</code>.

It will first ask you what the output files should be called, it's best to enter something that associates the file with the target domain or member, e.g. the domain itself or the members' username. It's recommended to only use alpha-numerical characters, dashes, underscores and dots.

Next, you're asked if the key shall be protected with a password. If the member didn't specify or doesn't want one, you can just press '''Enter''' on this step to select the default value of ''not'' using a password. Otherwise type '''y''' and press '''Enter''' to confirm, then generate a random password with a website, tool or password manager of your choice and input said password in the "Enter PEM pass phrase" prompt. The password needs to be at least 4 characters long!

The next step asks you for the hostnames of the certificate. Enter all hostnames you want the certificate to be valid for, e.g. <code>example.retro</code>, <code>www.example.retro</code> and <code>mail.example.retro</code>. If the member requested a wildcard certificate, enter the base domain first, e.g. <code>example.retro</code>, followed by the wildcard domain, e.g. <code>*.example.retro</code>. Once all domain names are entered, press '''Ctrl+D''' to confirm.

If you've specified '''y''' at the question above if the private key should be password protected, you will next be asked to re-enter that password.

Next, you'll be asked for the Common Name, there enter the base domain for which the certificate is valid, e.g. '''example.retro'''.

Then, some certificate options can be set like Country, Organization and E-Mail assigned with the certificate, which are most of the optional details listed above that the member can specify if they like, which does not need to be real data, it can be whatever they like. Otherwise, just press '''Enter''' on the fields to select the predefined default values.

The next password requested from you is the Intermediate CA Signing Password, followed by two confirmations if you really really want to sign the new certificates with our intermediate CA. Input '''y''' and press '''Enter''' both times.

Now the certificate is created and ready for use, the script will tell you into which directory it has written the certificate files.

All that's left to do now is to SCP the files off the CA container and send them over to the member in a secure-ish fashion through their prefered channel. Don't send them in the Discord channel unless they're fine with it since it allows someone else to more easily impersonate their site, not that that's a huge concern in the CGHMN network, but still.

File:Example Certificate Script Run.png

2025-05-15T20:09:27Z

Snep:

Terminal output of the Root CA Certificate creation script showing the domain example.retro receiving a certificate

CGHMN-IP-Allocations

2025-05-09T23:33:47Z

Snep: Added GothPanda

CGHMN-IP-Allocations

2025-05-09T21:31:41Z

Snep: Added Lily Hosting

CGHMN-IP-Allocations

2025-05-09T21:14:02Z

Snep:

CGHMN-IP-Allocations

2025-05-09T21:13:07Z

Snep: Added loganius

How to Get Connected

2025-05-07T04:26:09Z

Snep: Added short Get Connected for manual Wireguard connections

This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 172.23.0.0/16, 100.89.128.0/22, 100.96.0.0/13
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

CGHMN-IP-Allocations

2025-05-06T21:39:25Z

Snep: Added theothertom to members list

How to Get Connected

2025-05-05T22:30:50Z

Snep: Added reminder to add member connection to IP allocations table

This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

<nowiki>#</nowiki> TODO: Add Linux commands to get connected without OpenWRT
=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

CGHMN-IP-Allocations

2025-05-05T22:26:20Z

Snep: Added hadn69 and lily

How to Get Connected

2025-04-24T01:48:11Z

Snep: Added a link to user admin side tutorial

This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

How to Get Connected

2025-04-24T01:47:15Z

Snep: damn linebreaks

This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, see below>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

How to Get Connected

2025-04-24T01:41:57Z

Snep: Added OpenWRT tutorial and Admin tutorial

This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following: '''Instance:''' <code>WG_Member</code> '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code> '''Name:''' <code>member.''<Nickname of the new member>''</code> '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code> '''Private Key:''' <code>''<blank>''</code> '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>'' '''Pre-Shared Key:''' <code>''<blank>''</code> '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, see below>''</code> '''Keepalive interval:''' ''<code><blank></code>'' '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

File:Example Configuration for new Wireguard Peer on Core Router.png

2025-04-24T01:16:17Z

Snep:

Shows an example of all the values filled in, which are needed to add a new Member Wireguard connection to the Core Router

CGHMN-IP-Allocations

2025-03-30T05:09:30Z

Snep: Added list entries for delegated domains and member servers on the CGHMN Proxmox

CGHMN-IP-Allocations

2025-03-29T21:15:01Z

Snep:

CGHMN-IP-Allocations

2025-03-29T21:13:37Z

Snep:

CGHMN-Demo-Network

2025-03-29T20:45:49Z

Snep: Added paragraph about changes to the network

=== Demo Network for the Interim Computer Festival ===
This page documents the quickly set up demo network to show off the CGHMN network at the [https://sdf.org/icf/ SDF's Interim Computer Festival] taking place between March 22nd and 23rd. Consider this a sort-of draft, an experimental first version, a test on what might work and what doesn't.

Currently, the basics are up and running on the CGHMN Proxmox hypervisor living in the [https://devhack.net/ /dev/hack Hackerspace] in Seattle. These include a router and Wireguard endpoint through an OPNsense VM, a VXLAN tunnel endpoint container with some custom scripts to make deploying new member tunnel easier and two containers running a basic authoritative BIND DNS server for <code>.cghmn</code> and <code>.retro</code> and one hosting a custom, internal Certificate Authority for those domains.

=== Changes to the network layout ===
Since this page was written, there have been quite a lot of discussions about how and what we might change going forward, after the initial test of the network at the ICF was a success. The biggest change, so far, has been the idea to move away from VXLANs to GRETAP tunnels for the Layer 2 and non-IP Layer 3 traffic. This is mostly due to the fact that VXLANs, by their RFC definition, MAY NOT fragment packets coming into the VTEP (aka. a VXLAN tunnel endpoint) and packets flowing out of a VTEP MAY be reassembled if fragmented, but don't necessarily have to. In addition to this, the IP packets generated by the VXLAN tunnels have the Don't Fragment bit set, so those packets may also not be fragmented. This means that the underlying transport of the VXLAN tunnels, here Wireguard, would have to open a path that allows 1500 byte frames through its tunnel, which would make the tunnel packets themselves quite large at ~1600 bytes, which would then be fragmented by whatever routers are in between the client router and the CGHMN router. Turns out, that's quite inefficient.

GRETAP tunnels, on the other hand, have the two flags <code>ignore-df</code> and <code>nopmtudisc</code>, which together with <code>ttl 255</code> create a tunnel over IP, which can carry ''and fragment'' 1500 byte Ethernet frames over a smaller underlying transport, still Wireguard in this case. This was a massive boost not only in speed under certain circumstances, like running this all on a small travel router with a weak MIPS CPU, but also reliability, as less dropped packets could be observed and MTU blackholes finally not happening in our testing.

To bring up a GRETAP tunnel within the network to the CGHMN central router, use the following commands on a Linux box:<blockquote><code>ip link add gretap-cghmn type gretap remote 172.23.4.103 dev wg0 ignore-df nopmtudisc ttl 255</code>

<code>ip link set gretap-cghmn master br0 mtu 1500</code>

<code>ip link set gretap-cghmn up</code></blockquote>Where <code>wg0</code> is your CGHMN Wireguard tunnel and <code>br0</code> is the bridge you'd want to bridge the GRETAP tunnel to.

However, to improve performance more and make the network a little more reliable, there was another idea for a change: Sending routable IP traffic not over the Layher 2 tunnel, but rather routing it directly through the Wireguard tunnel, which already is a straight Layer 3 path to the CGHMN core router. This is possible due to the nftables <code>bridge</code> filter table, which can match and filter packets on bridge interfaces, incuding what "bridge port" they come in and go out of. This means we can filter IP traffic from leaving the retro LAN bridge, to which you'd connect your retro machines via a phyiscal LAN port, by creating a filter that says "Block all traffic on bridge <code>br-retrolan</code> which leaves through a GRETAP interface" and "Block all traffic on bridge <code>br-retrolan</code> which comes in on a GRETAP interface". Now, you can assign the router a static IP address on the bridge, so it can talk to your retro machines, enable DHCP and NAT and route IP traffic from your machines straight to the CGHMN via Wireguard. In the future, this shall be extended to work without NAT on the client side, so that every member has a small subnet, /24 for example, which is routed to the Wireugard tunnel client IP. This also means that the VLAN1 described in the next section might not need an IP address in the future so that the VLAN1 is purely non-IP traffic at least from the CGHMN side of things.

Yet another idea mentioned was the ability to span tunnels directly between members, even without going through the CGHMN core network in the first place. This can be accomplished by creating another GRETAP interface whose <code>remote</code> IP argument points to the IP of another members router, either through the existing CGHMN Wireguard tunnel or through a separate tunnel that you span between you and the other member. This GRETAP interface is then bridged to the <code>br-retrolan</code> bridge and with a couple of (perhaps default) bridge firewall rules, you and the other member should be able to communicate directly! Of course, this also means we'd have to implement some sort of loopback protection not just on the member router side (the default bridge firewall rules mentioned in the last sentence), but also on the core router side. so this idea is not yet fully implemented for testing.

IP Allocations within the network are now kept track of [[CGHMN-IP-Allocations|in this Wiki page]], though the IPs listed there might not be applied in the current configuration yet.

=== Network Layout ===
This section describes the network layout currently set up for the CGHMN demo network, none of which is necessarily permanent and already set in stone. I (Snep) made some assumptions about domain names, IP addresses, firewall rules and general design ideas to get something up and running for the computer festival based on info from the many chats and discussions on the Cursed Silicon Discord's CGHMN channel (See [[Signup]] for more details). So, please feel free to give input on things you'd like to see changed or added!

On the Proxmox host, all VLANs mentioned below are available tagged on the bridge <code>brcghmn</code>, with exception of VLAN1, which is untagged and the default network when a new container or VM is added to this bridge.

For servers and retro clients, the subnet <code>172.23.0.0/16</code> is currently in place, divided into smaller subnets, and might be subject to change later down the line. For Wireguard clients, the <code>100.89.128.0/22</code> subnet out of the CGNAT block is used and again, might change later.

Below is a further breakdown of VLANs existing in this CGHMN demo network:

==== VLAN 1 - The Global LAN (172.23.0.0/22) ====
This network is our layer 2 bridged network to all members who wish to participate and is intended to be used for retro computers to directly communicate with each other even across the globe. This is accomplished by spanning a VXLAN tunnel across a Wireguard connection from the CGHMN server infrastructure to each members' router endpoint, which can be any OpenWRT compatible device that contains the packages for VXLANs and Wireguard. The idea is to bridge on of at least two available interfaces from said router to the VXLAN network and thus directly bridge any connected retro machines to VLAN1. All members will be in the same L2 broadcast domain, meaning even non-IP protocols that are able to run over Ethernet should be able to communicate with each other from all over the world.

Machines on this network are able to connect to all hosts on the Server VLAN (see below), the firewall for DNS, NTP and ICMP queries and to the root DNS and CA servers for DNS queries and HTTP access to the CA web server. They may also query DNS lookups at the legacy DNS server at <code>172.23.0.104</code>. They are not, however, able to communicate with any hosts on the internet, the /dev/hack network or any of the other existing VLANs aside from specific exceptions.

Addresses are handed out via DHCP by the router in the range <code>172.23.1.1-172.23.3.254</code>, the range <code>172.23.1.11-172.23.1.255</code> is reserved for static hosts. The search domain for this network is <code>clients.retro</code>.

==== VLAN 4 - Core Services (172.23.4.0/22) ====
This VLAN in intended for core internal services, like the root DNS server, VXLAN endpoint and our custom Certificate Authority. The Proxmox host also has an IP address in this subnet (<code>172.23.4.11</code>), it does not however have any routes to the rest of this CGHMN demo infrastructure and thus can only be accessed from clients in the Core Services subnet.

Hosts in this subnet may currently access the internet, the router for DNS, NTP and ICMP queries, query DNS lookups at the legacy DNS server at <code>172.23.4.104</code> and the VXLAN endpoint may send UDP datagrams to anyone at port <code>4789</code> for VXLAN tunnel replies, any other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.7.1-172.23.7.254</code>, the range <code>172.23.4.11-172.23.6.255</code> is reserved for static hosts. The search domain for this network is <code>core.cghmn</code>.

==== VLAN 8 - Servers (172.23.8.0/22) ====
This VLAN will contain all servers hosted and managed by members, which can be any (retro) service that works across an IP router. For anything that requires direct layer 2 access or the same broadcast domain as the client machines, it is advised to host said server in the Global LAN network. This is the only VLAN clients from the bridged Global LAN network may access freely, so members should be wary about what ports they open up for anyone outside of localhost. Another option is to run a tiny router instance based on OpenWRT in front of your server which will act as a basic firewall and NAT router behind which one can run their servers.

Hosts in this subnet may not access the internet inherently, however a firewall rule is in place that allows specific servers internet access, it is still uncertain if this will make it to the final CGHMN or if this subnet is also supposed to be entirely sealed off from the public internet. During a few chats on the Discord server, the idea of hosting local package mirrors of popular distros and projects was mentioned so that both modern and retro systems won't need to connect to internet servers for package installations and upgrades. Hosts may access the router for DNS, NTP and ICMP queries and query DNS lookups at the legacy DNS server at <code>172.23.4.104</code>, other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.11.1-172.23.11.254</code>, the range <code>172.23.8.11-172.23.10.255</code> is reserved for static hosts. The search domain for this network is <code>hosting.retro</code>.

==== VLAN 12 - DMZ (172.23.12.0/22) ====
Currently not in use.

=== Containers and VMs ===
Containers and VMs on the Proxmox host are currently assigned in the 10000 ID range to keep clear of existing VMs.

There is one VM and three containers at the time of writing this:

==== VM 10001 (demo-chhmn-router) ====
This is the OPNsense VM running as the primary router, firewall, DHCP server and Wireguard endpoint for the demo network. Its login credentials are currently in the paws of Snep, as I'm still unsure where any passwords for the CGHMN are going to be stored safely and with proper access rights.

The router has the first IP in any of the available demo network subnets and responds to IPv4 and IPv4 ICMP packets, DNS queries to its local Unbound resolver and NTP sync requests to the built-in NTP server.

Unbound currently resolves all requests it cannot resolve locally recursively against the internet root servers and returns those replies to clients, this may be subject to change as we potentially plan on sealing the network off more. It is configured to forward all requests with a TLD of <code>.cghmn</code> and <code>.retro</code> to the internal DNS root server.

The Wireguard endpoint servers as the connection into the CGHMN from the outside internet on <code>66.170.190.194:42070</code> for anyone that wishes to parttake the network. See [[Signup]] for more details on how to join.

==== Container 10401 (demo-cghmn-root-dns, VLAN4, 172.23.4.101) ====
This container, based on the absolutely tiny-footprinted Alpine image, hosts the BIND-based root DNS server for the internal CGHMN domains <code>.retro</code> and <code>.cghmn</code> together with the reverse DNS zone for the 172.23.0.0 network. It lives in the Core Services subnet and is reachable on port 53 for DNS queries from every other internal subnet. Zones are configured in the zone files under <code>/etc/bind/zones</code> and loaded by the zone blocks in the <code>/etc/named.conf</code> file.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10401</code> on the Proxmox host console.

==== Container 10402 (demo-cghmn-ca, VLAN4, 172.23.4.102) ====
This container, also based on Alpine, is hosting the custom Certificate Authority based on OpenSSL created and self-signed certificate files. It is currently constructed in a Root CA -> Intermediate CA -> Server Certificates structure, where the CA signed certificates of the intermediate CA, which then signs all certificates requested for servers and clients on the network. Clients thus should only need to install the CA certificate into their trusted keychain to have valid TLS connections to servers using certificates signed by this internal CA.

Clients can access a web server on <code>certs.cghmn:80</code> or <code>172.23.4.102:80</code> via plain HTTP to download the root CA and intermediate CA certificate files for installation on their retro machines. Note: This is not meant to be secure. When you add this root CA, we could pretend to be any server on the internet under any domain and any system that has the root CA or intermediate CA certificate installed will trust it. Don't add this on machines you would have personal data on or that you would let onto the public internet!

The /root directory of this container contains a script called <code>create-and-sign-server-csr.sh</code> that, when run without any arguments, will ask a few questions on the command line and generate a signed TLS certificate in the root directory for the specified DNS names to make deployment of new TLS certificates a little easier. This requires the password of the private key of the intermediate CA, which again is currently stored in Sneps password manager but of course will be copied to a safe location to store passwords once available for the CGHMN.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10402</code> on the Proxmox host console.

==== Container 10403 (demo-cghmn-vxlan-endpoint, VLAN4, 172.23.4.103) ====
This container, another Alpine instance, connects all the VXLAN clients together under one virtual Linux bridge and is constructed with a couple if-up/if-down scripts and a Bash script to create new tunnels at <code>/opt/vxlan-scripts/create-vxlan-interface.sh</code>.

This script, when called like for example so: <code>create-vxlan-interface.sh 100.89.128.90</code> will do the following:

# Find the first unused VXLAN ID
# Output the VXLAN ID for configuring a new VXLAN tunnel on the client side
# Add an interface configuration to <code>/etc/vxlan-interfaces/</code> which is sourced by ifupdown
# Bring up that new VXLAN interface, which bridges it to the Global LAN bridge

after which the client with IP 100.89.128.90 can connect a VXLAN tunnel with the newly added VXLAN ID to their router and join the network.

This is still a very manual process, though one which will probably become more streamlined in the future of the CGHMN network, perhaps with some APIs and/or custom OpenWRT web interface *wink wink*.

This container is only reachable by the firewall itself and by the clients connecting their VXLAN bridge to port 4789 from the Wireguard tunnel, as it doesn't do any routing or hosting of services directly aside from the VXLAN endpoint.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10403</code> on the Proxmox host onsole.

==== Container 10404 (demo-cghmn-legacy-dns, VLAN4, 172.23.4.104) ====
This container, based on Alpine, runs a dnsmasq instance configured to look up certain DNS overrides either in the hosts file at <code>/etc/cghmn-dns-overrides</code> or by including a dnsmasq configuration file from <code>/etc/dnsmasq-cghmn.d/*.conf</code>. Any other requests it cannot resolve locally are forwarded to the Unbound DNS resolver running on the OPNsense router VM. This setup is used to create DNS overrides for existing domains to make old software, which is hardcoded to specific DNS entries, work again with custom servers hosted internally.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10404</code> on the Proxmox host console.

=== Proposed Organization of IDs and IPs ===
My (Sneps) idea behind Proxmox container and VM IDs are as follows:

'''101xx - 103xx''' are for Containers and VMs in the bridged layer 2 network, so any hosts that members want to run in the bridged network directly.

'''104xx - 107xx''' are for Containers and VMs in the Core Services VLAN4, so anything that is necessary for the operation of the CGHMN network.

'''108xx - 111xx''' are for Containers and VMs in the Servers VLAN8, so anything that members would choose to host on the CGHMN Proxmox.

For IPs, I left the first 10 IPs in each subnet reserved for things like routers, for example (perhaps a second router and a virtual IP for failover down the line?).

After that, the first half of the subnet (see above under Network Layout for the actual start and end of this range) is supposed to be reserved for any hosts that are set up with a fully static IP. This is entirely outside of the DHCP range to avoid any conflicts. That DHCP range then starts with the second half of the subnet and goes up to the last available host IP of each subnet.

=== Other Notes ===

* Currently, the advertised DNS server via DHCP is the included Unbound Server on the OPNsense instance. If we want to completely seal off clients and servers from the rest of the internet, we could directly point the clients towards our root DNS server for all requests.
* Currently, the OPNsense router does DHCP as it already has an IP in each VLAN and comes with a solid DHCP server that can also support failover out of the box (ISC DHCP). I (Snep) chose this route over a standalone DHCP server to avoid having a second container/VM in each subnet that solely does DHCP or DHCP proxying, mainly to keep the setup and maintenance work as low as possible.
* A customized OpenWRT image for the Gl.iNet MT300n and AR300n are currently being built and tested, which includes required packages and UCI configurations out of the box to make joining the network perhaps a little bit easier. Will update this page or create a new one and link to it once a working image exists!

=== Reserved static IPs ===

* '''VLAN1, 172.23.0.11:''' WIREGUARD-EXTERNAL (CursedSilicon)

CGHMN-IP-Allocations

2025-03-23T06:43:21Z

Snep: Changed VLAN12 to VLAN256

CGHMN-IP-Allocations

2025-03-23T06:35:59Z

Snep: Changed VLAN1 to VLAN12

CGHMN-IP-Allocations

2025-03-23T06:23:00Z

Snep: Initial page creation

CGHMN-Demo-Network

2025-03-20T04:49:19Z

Snep: added information about the container 10404

=== Demo Network for the Interim Computer Festival ===
This page documents the quickly set up demo network to show off the CGHMN network at the [https://sdf.org/icf/ SDF's Interim Computer Festival] taking place between March 22nd and 23rd. Consider this a sort-of draft, an experimental first version, a test on what might work and what doesn't.

Currently, the basics are up and running on the CGHMN Proxmox hypervisor living in the [https://devhack.net/ /dev/hack Hackerspace] in Seattle. These include a router and Wireguard endpoint through an OPNsense VM, a VXLAN tunnel endpoint container with some custom scripts to make deploying new member tunnel easier and two containers running a basic authoritative BIND DNS server for <code>.cghmn</code> and <code>.retro</code> and one hosting a custom, internal Certificate Authority for those domains.

=== Network Layout ===
This section describes the network layout currently set up for the CGHMN demo network, none of which is necessarily permanent and already set in stone. I (Snep) made some assumptions about domain names, IP addresses, firewall rules and general design ideas to get something up and running for the computer festival based on info from the many chats and discussions on the Cursed Silicon Discord's CGHMN channel (See [[Signup]] for more details). So, please feel free to give input on things you'd like to see changed or added!

On the Proxmox host, all VLANs mentioned below are available tagged on the bridge <code>brcghmn</code>, with exception of VLAN1, which is untagged and the default network when a new container or VM is added to this bridge.

For servers and retro clients, the subnet <code>172.23.0.0/16</code> is currently in place, divided into smaller subnets, and might be subject to change later down the line. For Wireguard clients, the <code>100.89.128.0/22</code> subnet out of the CGNAT block is used and again, might change later.

Below is a further breakdown of VLANs existing in this CGHMN demo network:

==== VLAN 1 - The Global LAN (172.23.0.0/22) ====
This network is our layer 2 bridged network to all members who wish to participate and is intended to be used for retro computers to directly communicate with each other even across the globe. This is accomplished by spanning a VXLAN tunnel across a Wireguard connection from the CGHMN server infrastructure to each members' router endpoint, which can be any OpenWRT compatible device that contains the packages for VXLANs and Wireguard. The idea is to bridge on of at least two available interfaces from said router to the VXLAN network and thus directly bridge any connected retro machines to VLAN1. All members will be in the same L2 broadcast domain, meaning even non-IP protocols that are able to run over Ethernet should be able to communicate with each other from all over the world.

Machines on this network are able to connect to all hosts on the Server VLAN (see below), the firewall for DNS, NTP and ICMP queries and to the root DNS and CA servers for DNS queries and HTTP access to the CA web server. They may also query DNS lookups at the legacy DNS server at <code>172.23.0.104</code>. They are not, however, able to communicate with any hosts on the internet, the /dev/hack network or any of the other existing VLANs aside from specific exceptions.

Addresses are handed out via DHCP by the router in the range <code>172.23.1.1-172.23.3.254</code>, the range <code>172.23.1.11-172.23.1.255</code> is reserved for static hosts. The search domain for this network is <code>clients.retro</code>.

==== VLAN 4 - Core Services (172.23.4.0/22) ====
This VLAN in intended for core internal services, like the root DNS server, VXLAN endpoint and our custom Certificate Authority. The Proxmox host also has an IP address in this subnet (<code>172.23.4.11</code>), it does not however have any routes to the rest of this CGHMN demo infrastructure and thus can only be accessed from clients in the Core Services subnet.

Hosts in this subnet may currently access the internet, the router for DNS, NTP and ICMP queries, query DNS lookups at the legacy DNS server at <code>172.23.4.104</code> and the VXLAN endpoint may send UDP datagrams to anyone at port <code>4789</code> for VXLAN tunnel replies, any other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.7.1-172.23.7.254</code>, the range <code>172.23.4.11-172.23.6.255</code> is reserved for static hosts. The search domain for this network is <code>core.cghmn</code>.

==== VLAN 8 - Servers (172.23.8.0/22) ====
This VLAN will contain all servers hosted and managed by members, which can be any (retro) service that works across an IP router. For anything that requires direct layer 2 access or the same broadcast domain as the client machines, it is advised to host said server in the Global LAN network. This is the only VLAN clients from the bridged Global LAN network may access freely, so members should be wary about what ports they open up for anyone outside of localhost. Another option is to run a tiny router instance based on OpenWRT in front of your server which will act as a basic firewall and NAT router behind which one can run their servers.

Hosts in this subnet may not access the internet inherently, however a firewall rule is in place that allows specific servers internet access, it is still uncertain if this will make it to the final CGHMN or if this subnet is also supposed to be entirely sealed off from the public internet. During a few chats on the Discord server, the idea of hosting local package mirrors of popular distros and projects was mentioned so that both modern and retro systems won't need to connect to internet servers for package installations and upgrades. Hosts may access the router for DNS, NTP and ICMP queries and query DNS lookups at the legacy DNS server at <code>172.23.4.104</code>, other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.11.1-172.23.11.254</code>, the range <code>172.23.8.11-172.23.10.255</code> is reserved for static hosts. The search domain for this network is <code>hosting.retro</code>.

==== VLAN 12 - DMZ (172.23.12.0/22) ====
Currently not in use.

=== Containers and VMs ===
Containers and VMs on the Proxmox host are currently assigned in the 10000 ID range to keep clear of existing VMs.

There is one VM and three containers at the time of writing this:

==== VM 10001 (demo-chhmn-router) ====
This is the OPNsense VM running as the primary router, firewall, DHCP server and Wireguard endpoint for the demo network. Its login credentials are currently in the paws of Snep, as I'm still unsure where any passwords for the CGHMN are going to be stored safely and with proper access rights.

The router has the first IP in any of the available demo network subnets and responds to IPv4 and IPv4 ICMP packets, DNS queries to its local Unbound resolver and NTP sync requests to the built-in NTP server.

Unbound currently resolves all requests it cannot resolve locally recursively against the internet root servers and returns those replies to clients, this may be subject to change as we potentially plan on sealing the network off more. It is configured to forward all requests with a TLD of <code>.cghmn</code> and <code>.retro</code> to the internal DNS root server.

The Wireguard endpoint servers as the connection into the CGHMN from the outside internet on <code>66.170.190.194:42070</code> for anyone that wishes to parttake the network. See [[Signup]] for more details on how to join.

==== Container 10401 (demo-cghmn-root-dns, VLAN4, 172.23.4.101) ====
This container, based on the absolutely tiny-footprinted Alpine image, hosts the BIND-based root DNS server for the internal CGHMN domains <code>.retro</code> and <code>.cghmn</code> together with the reverse DNS zone for the 172.23.0.0 network. It lives in the Core Services subnet and is reachable on port 53 for DNS queries from every other internal subnet. Zones are configured in the zone files under <code>/etc/bind/zones</code> and loaded by the zone blocks in the <code>/etc/named.conf</code> file.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10401</code> on the Proxmox host console.

==== Container 10402 (demo-cghmn-ca, VLAN4, 172.23.4.102) ====
This container, also based on Alpine, is hosting the custom Certificate Authority based on OpenSSL created and self-signed certificate files. It is currently constructed in a Root CA -> Intermediate CA -> Server Certificates structure, where the CA signed certificates of the intermediate CA, which then signs all certificates requested for servers and clients on the network. Clients thus should only need to install the CA certificate into their trusted keychain to have valid TLS connections to servers using certificates signed by this internal CA.

Clients can access a web server on <code>certs.cghmn:80</code> or <code>172.23.4.102:80</code> via plain HTTP to download the root CA and intermediate CA certificate files for installation on their retro machines. Note: This is not meant to be secure. When you add this root CA, we could pretend to be any server on the internet under any domain and any system that has the root CA or intermediate CA certificate installed will trust it. Don't add this on machines you would have personal data on or that you would let onto the public internet!

The /root directory of this container contains a script called <code>create-and-sign-server-csr.sh</code> that, when run without any arguments, will ask a few questions on the command line and generate a signed TLS certificate in the root directory for the specified DNS names to make deployment of new TLS certificates a little easier. This requires the password of the private key of the intermediate CA, which again is currently stored in Sneps password manager but of course will be copied to a safe location to store passwords once available for the CGHMN.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10402</code> on the Proxmox host console.

==== Container 10403 (demo-cghmn-vxlan-endpoint, VLAN4, 172.23.4.103) ====
This container, another Alpine instance, connects all the VXLAN clients together under one virtual Linux bridge and is constructed with a couple if-up/if-down scripts and a Bash script to create new tunnels at <code>/opt/vxlan-scripts/create-vxlan-interface.sh</code>.

This script, when called like for example so: <code>create-vxlan-interface.sh 100.89.128.90</code> will do the following:

# Find the first unused VXLAN ID
# Output the VXLAN ID for configuring a new VXLAN tunnel on the client side
# Add an interface configuration to <code>/etc/vxlan-interfaces/</code> which is sourced by ifupdown
# Bring up that new VXLAN interface, which bridges it to the Global LAN bridge

after which the client with IP 100.89.128.90 can connect a VXLAN tunnel with the newly added VXLAN ID to their router and join the network.

This is still a very manual process, though one which will probably become more streamlined in the future of the CGHMN network, perhaps with some APIs and/or custom OpenWRT web interface *wink wink*.

This container is only reachable by the firewall itself and by the clients connecting their VXLAN bridge to port 4789 from the Wireguard tunnel, as it doesn't do any routing or hosting of services directly aside from the VXLAN endpoint.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10403</code> on the Proxmox host onsole.

==== Container 10404 (demo-cghmn-legacy-dns, VLAN4, 172.23.4.104) ====
This container, based on Alpine, runs a dnsmasq instance configured to look up certain DNS overrides either in the hosts file at <code>/etc/cghmn-dns-overrides</code> or by including a dnsmasq configuration file from <code>/etc/dnsmasq-cghmn.d/*.conf</code>. Any other requests it cannot resolve locally are forwarded to the Unbound DNS resolver running on the OPNsense router VM. This setup is used to create DNS overrides for existing domains to make old software, which is hardcoded to specific DNS entries, work again with custom servers hosted internally.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10404</code> on the Proxmox host console.

=== Proposed Organization of IDs and IPs ===
My (Sneps) idea behind Proxmox container and VM IDs are as follows:

'''101xx - 103xx''' are for Containers and VMs in the bridged layer 2 network, so any hosts that members want to run in the bridged network directly.

'''104xx - 107xx''' are for Containers and VMs in the Core Services VLAN4, so anything that is necessary for the operation of the CGHMN network.

'''108xx - 111xx''' are for Containers and VMs in the Servers VLAN8, so anything that members would choose to host on the CGHMN Proxmox.

For IPs, I left the first 10 IPs in each subnet reserved for things like routers, for example (perhaps a second router and a virtual IP for failover down the line?).

After that, the first half of the subnet (see above under Network Layout for the actual start and end of this range) is supposed to be reserved for any hosts that are set up with a fully static IP. This is entirely outside of the DHCP range to avoid any conflicts. That DHCP range then starts with the second half of the subnet and goes up to the last available host IP of each subnet.

=== Other Notes ===

* Currently, the advertised DNS server via DHCP is the included Unbound Server on the OPNsense instance. If we want to completely seal off clients and servers from the rest of the internet, we could directly point the clients towards our root DNS server for all requests.
* Currently, the OPNsense router does DHCP as it already has an IP in each VLAN and comes with a solid DHCP server that can also support failover out of the box (ISC DHCP). I (Snep) chose this route over a standalone DHCP server to avoid having a second container/VM in each subnet that solely does DHCP or DHCP proxying, mainly to keep the setup and maintenance work as low as possible.
* A customized OpenWRT image for the Gl.iNet MT300n and AR300n are currently being built and tested, which includes required packages and UCI configurations out of the box to make joining the network perhaps a little bit easier. Will update this page or create a new one and link to it once a working image exists!

=== Reserved static IPs ===

* '''VLAN1, 172.23.0.11:''' WIREGUARD-EXTERNAL (CursedSilicon)

CGHMN-Demo-Network

2025-03-20T03:51:24Z

Snep: Added reserved IP for WIREGUARD-EXTERNAL for CursedSilicon

CGHMN-Demo-Network

2025-03-20T02:57:56Z

Snep: Details about the demo CGHMN network for the SDF Interim Computer Festival