Frequently Asked Questions
Published by skylar on Wednesday, May 3, 2023
Project Members - Network Related
Do I need IPv4 or IPv6 to connect to your network?
You can connect to our network using either protocol. We fully
support both for our WireGuard profiles and all routers will
respond to connections from either protocol as long as your
profile is valid.
I tried both protocols and cannot connect, help!
There have been some issues with a very few ISPs and some
locations such as universities or public cafes that do not
allow UDP connections. Unfortunately, WireGuard makes use
of UDP connections to work. While there are work arounds to
this problem, we choose not to deploy them except in very
specific situations because of the advanced configuration
that doing so requires. (Usually involves tunneling the UDP
traffic inside of TCP and takes a performance hit or making
OVPN look like HTTPS traffic, which has problems on its own.)
If WireGuard will not connect for you or is very unstable, our
team is not likely to create a TCP endpoint for you, but you
can try asking the support desk.
How do you handle DNS?
Our routers all run their own internal DNS service that randomly
reaches out to either 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1,
2001:4860:4860::8888, 2001:4860:4860::8844, 2606:4700:4700::1111,
and 2606:4700:4700::1001. These are external DNS services found
on Google and Cloudflare. They are not run by us, but are fast
enough to avoid DNS issues and pickup on changes very quickly.
Our routers will cache responses from these DNS servers for some
time once the request is answered and all WireGuard profiles that
we issue are configured to use our routers as their DNS.
We do not restrict the use of custom DNS servers, however, and
you may modify your profile to point to your own DNS if you wish.
I loaded my profile in two places and nothing is working!
Please, do not do this. It confuses our routers and only leads
to frustration for you as the end user. Reach out to support and
ask them for a /124 at minimum and let them know how many profiles
you actually need.
Our routers make use of dynamic endpoints to allow your profile to
roam about for situations like mobile phone use.
Are your IPv6 addresses on the public internet?
Yes. If your request for service gets approved, we will assign you
a publicly routable IPv6 address. There is a small catch though.
While you can get your homelab or device onto the public IPv6
internet, there are some systems and networks that do not like
our upstream’s ASN. Most things should work, but you may run into
issues for certain websites and games. This is nothing we can
do about it short of getting our own ASN and netblock, which isn’t
cheap or easy.
Do I have to get IPv4 access with my IPv6 request?
Not at all, in fact, that is the default configuration for approved
service request. IPv6 is our core focus, with IPv4 just being an
after thought. So no, unless you ask for IPv4 access, it will not
be enabled by default.
Are your IPv4 addresses on the public internet?
Yes, on the WAN side. If you do request IPv4 service along with your
IPv6 request, you will receive a NAT’d IPv4 address in the 10.0.x.x
range. This is provided as an option for convenience and is not the
focus of our project. Side note, if you want us to port forward
something to your NAT’d address, let us know what port and why.
We will get back to you when we have a moment.
Do you own your address space?
No, we don’t have that kind of funding. Our address space for both
IPv4 and IPv6 comes from our upstream provider. Due to record
keeping, however, sometimes our IP ranges will show either our
upstream’s information or “Marbled Fennec Networks.”
Why are there bandwidth limits on your routers?
Our physical host features a 1Gbps link between our server and the
data center. To make an attempt to prevent accidental network
saturation, we place hard limits on each of our router VMs that should
keep any one router from crashing the network. For our shared routers
the limit is currently 350Mbps shared. For our end users making use
of VM hosting with us, the CX router is limited to 250Mbps shared.
What do you mean by ’shared’ bandwidth?
All project members connected to one of our routers will share
the bandwidth on that router with all other members who are
currently connected. We run the project to get our members connected
to the greater IPv6 internet as well as to enable them to host things
in their homelabs in situations where their ISP does not make it easy
or possible to do so, not to be their sole ISP. For cost and practical
reasons, we cannot provide every member with line speed; therefor we
set what we determine to be reasonable limitations to allow everyone
fair use of the network. Additionally, our routers use QoS systems to
try and keep the total load balanced and latency acceptable.
Alright, I saw something about WireGuard. Are you a VPN provider?
Not in the sense that you are most likely thinking. While we do deploy
VPN technologies to connect our members, we do not focus on privacy or
‘hiding’any member’s traffic. If we may use a bit of a misnomer here,
we deploy what we call an ‘rVPN’ or reverse VPN network stack. Our goal
is to get your homelab or device on the public internet and reachable.
And…before you ask: Yes, we log various metrics and stats about our
connected members. Do not assume total privacy with our service, that is not
our goal at The MFN Project. Our volunteer staff all have access to various
metrics and real time data for every router and bridge.
Simple answer: No.
Are your systems automated?
Not right now and as far as I am aware, the group doesn’t plan to automate
too much on the network because a few of us enjoy working on the configurations
by hand. Plus, working on things by hand allows as to work closer with our
project members to ensure we create a profile that meets their needs for their
homelab or device.
Why are you so upfront about how the network operates?
Short answer- Nothing special or magical is going on here. Anyone
with enough know how and determination can match us on feature
parity and network design; and to be straight to the point, the
project and the network it operates is made that way on purpose.
Long answer-
Anyone who is into computer networking, Linux and virtual machines can
easily figure how our network is built and replicate it in about two to
three days if they really wanted to. We don’t have anything to hide here
or anything special going on in the back end. All of our tooling is
standard off-the-shelf firmware, applications, services and libraries.
Furthermore, being open and transparent means that our members will
be fully aware of what, who and how they are connecting their equipment
to us.
Our environment is virtualized and deploys a mix of network soft bridges,
opnsense powered routers, a few Linux VMs for various services and some
amount of hand written routing table and firewall mess. We wanted to try
and keep the project’s network stack on the more simple scale of things to
allow for new volunteer staff to be able to easily grasp the ropes and
be able to get up to speed quickly in their roles; but also to allow the
project to make sense to members who are moving on so they may recall and
make use of what they learned where ever they progress on to.
Project Members - Operations Related
If I request service, how long is the wait?
Bruh, we are hobbyist. This is a spare time project brought online because
we wanted to and we enjoy operating a virtual ISP. If you reach out to support
via the ticket system or email, you should expect to wait for a response
for around two to three days. We try to be quick with request and support
related inquiries, but all of our volunteer staff have lives, jobs and
projects outside of MFN.
What level of support is provided by the MFN team?
Skylar instructs, and usually limits, the rest of the team’s technical
support response to getting members connected, ports forwarded if needed,
subnets adjusted, VMs provisioned and answering general inquiries about
the project. The team is not required to assist with VM configuration
or recovery, router or system specific profile configs, member deployment
or other issues. Sure, some team members may take an interest in your
project and opt to provide a little more insight, but it is not to be
expected and is not required.
What is the process of on-boarding a new project member?
Typically once a guest has emailed support or created a ticket, the
request will be reviewed at a glance. If the request seems reasonable
and like it would be something we could help out with, it will be
forwarded from support to Skylar or another upper team member for
secondary review. During this time, things such as bandwidth impact,
configuration load, resources used and overall risk to the network
are evaluated by multiple team members.
If everyone agrees that the request is reasonable, we will reach
out to you for more information. If it is determined that your
request doesn’t fit within the scope of The MFN Project,
you should receive an email stating such.
Project Members - VM/GS Hosting Related
Is MFN a GSP? (Game Server Provider)
No.
If you wish to host a game on our network, you must either apply for a VM
to be hosted in house which is unlikely to be approved or host the game
server from your location using MFN as the transport for the data connection.
In either case you, not MFN, must have the appropriate licensing
and proper software keys to host your server. We do not provide premade game
server VMs and will not assist with the creation of any game server. This
has come up a few times before with would be members looking for a cheap/free
way to host their games and it is massively outside of the scope of operations
that MFN targets.
If your request for an in house VM does get approved, you will be emailed first
time login details and presented with a bare VM running the Debian OS. Our
volunteer staff members will not assist you with setup or hosting of said VM
outside of getting it connected to the network or resetting it to the “out
of the box” state.
What OSes do you allow for VMs?
MFN only allows approved project members to use the Linux/GNU or FreeBSD OSes
on VMs that that are hosted on our network (also known as hosted in house). The
Windows OS is not permitted to be installed on any VMs hosted in house.
If you are planning to request us to host a VM on your behalf, you need to make
sure your application can function on one of the above permitted OSes.
Also make note:
VMs that are discovered to have been boot strapped into the Windows OS and/or
reinstalled with the Windows OS will be removed from the network at once
without any notice or warning. The only exception to this is our two in house Windows
game servers and we only use them for Arma3, FTB and occasionally DayZ.
We are not approving other Windows VMs at this time.
Why do you offer VM hosting if the approval rate is not likely?
Members that have been with the project for a while and have proven themselves
to be trustworthy are able to request MFN to host VMs in house using resources
from our physical host that MFN is not making use of. There are ground rules
that we expect to be followed and full documentation of the VM’s use is expected
upon request. While we don’t approve VM hosting often, the option is there as
a gesture of good will towards our longer standing members. Members have been
approved in the past, members will be approved in the future, the process is
just kind of lengthy and requires both parties knowing one another fairly well.
Are the VM resource limits set in stone?
The resources you are granted are based upon network usage, CPU usage and free
memory on the physical host at the time you made your request. We have to balance
things so that the network performance does not suffer from being over taxed.
VM instances that abuse the space they are given, such as always maxing out their
vCPUs nearly constantly may see additional limits placed on them such as a lowered
CPU priority or even a CPU usage cap. Be fair and share the resources, please.
My application requires IPv4 but the ports I need are already taken!
All VM instances are connected to the internet through the CX router. For IPv4,
we use NAT to ensure connectivity, but this means that port forwards are issued
on a first come, first served basis. Change your application’s port assignment
if such is possible.
My application supports IPv6, but the port is already in use on my /128!
Reach out to us via the support desk and request either a /124, /120 or a
/64 from us. You need to let us know what all you plan to host and how you plan
on eventually using the remaining addresses. Straight forward, simple process.
I really would like my own IPv4 to skip your routers!
Two problems with this:
1) IPv4 addresses are too expensive to rent just for your use.
It cost MFN $12/mo for each /29 and we can only request one
additional /29 every three months and three of those addresses
must be “in service” by end of month one. We have been burned
doing this for past members of the MFN project who decided they
wanted to back track after the order was placed.
and
2) IPv4 is not the focus of the project. We only offer IPv4
as a mix of legacy support and a courtesy to our project members.
For what we do, IPv6 is much easier to work with and roll out.
The IPv6 protocol also allows us to service more project members
with our network stack.
If after reading the above you still really would like your own
IPv4 address, MFN encourages you to inquire about how the network
is designed and to rent a dedicated box from a data center to
build your own project on. It can be a fun and rewarding process
once you get the hang of it all.
FAQ for External Network SYSOPs
Under this header, you’ll find the FAQs that pertain to those who
are not a member of TheMFNProject but may still be connecting to
the network and making use of resources.
I was able to connect to your web server and now I am not?
There is a fair chance that someone within your /24 was aggressively
crawling the website with back to back request and to cut back on
traffic, we blocked the /24 at the router. We look at where the /24
comes from, how often pages are requested, what URLs are being hit and
the user agent when making decisions to block or not block a /24.
I know you guys once had an email server, but now I cannot see it…
There is a fair chance that someone within your /24 was found to be trying
to use us as a relay, trying to SASL login with ‘password’ or jumping ahead
in the protocol and it showed up in the logs. We do not tolerate any abuse
of the mail server at all and hand out subnet bans at the router in an
effort to stop these connections and keep the log clean.
If you are being prevented from delivering legitimate mail to our server,
reach out to the support desk for help.
If our volunteer support staff does unblock your /24 and you end up blocked
a second time, you will not be unbanned from accessing the email server. Clean
up your network if its unshared or try to work with your host if it is shared.