Thanks for the nice write-up, saving it in case I find myself behind CGNAT in the future.
this post was submitted on 28 Oct 2024
76 points (95.2% liked)
Selfhosted
40644 readers
827 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
In most environments ipv6 bypasses cgnat (because, why would you need a nat with ipv6).
Like I said ip6 is useless when it comes to torrenting. Even if the tracker supports it it's not persavive with users connecting to you.
The general topic was about self-hosting. IPv6 is very useful for self-hosting,.. connections.
I'll admit there is a critical mass problem with torrenting clients, but if you're trying to set up a wire guard tunnel with your friends, IPv6 is a absolute banger
Hey, great post. I have one request. Can you maybe add some description for what the iptables entries do? I have a similar setup with a lot less iptables rules that works well for me. But I'm not an expert in networking, and am now worried that I might be missing something that can leak my home IP.
Thanks for the feed back. I started out with that post I referenced in my article, which had fewer entries. It didn't work. Caveat was although the online port checkers were reporting the port as open, it was not actually making through the tunnel!
I actually solved it by asking chatgpt!! I put in the suggestions and it worked. I'm also no expert on creating iptables, but once it was in place it seemed self explanatory.
I ran netcat as client-server to test it actually worked.
Idk man, it seems pretty irresponsible to me to write a blogpost with stuff that you got from ChatGPT without understanding it. People will assume that if you wrote a blogpost on this then you know what you're doing. ChatGPT gets stuff wrong all the time, and we're talking about firewall configuration here. If it misconfigured some stuff it could leave you and your readers vulnerable to all kinds of shit.
In this case it seems to me that (luckily) there's just a bunch of redundant routing, but the next time it could be leaking your and your readers' torrent traffic out of the VPN tunnel, leaving you vulnerable to legal repercussions for piracy.
Please don't authoritatively post stuff that you got from the automatic bullshit generator without understanding it.
I understand what you mean. It's become a habit of mine lately, and I learn lots in the discussion to.
In my defence I did run some tests and confirm it's functioning.
I understand what you mean. It's become a habit of mine lately, and I learn lots in the discussion to.
In my defence I did run some tests and confirm it's functioning.
Look at the very least you should write in the blogpost clearly which parts are generated by LLMs, so your readers can decide whether to trust them.
I took a look at it. From what I understand, some of the lines in your setup are redundant. The final product seems to do basically the same job as mine. In any case, if it works, it works.
another option is to use Cloudflare's tunnels. it's free, I use it all the time. really great.
I've set up some tunnels. Works nice but then the voices came. 'Why would you trust a company like Cloudflare with all your data?' 'Why rely on this one company for all your services?'
Nearly a year into my selfhosting journey and I'm more confused than ever.
tl;dr: classic convenience/privacy. depends on your threat model. surely better than Google. models of zero trust will help.
That's a great question, that I have asked myself before too. It doesn't have one answer, and any one would make their own choices based on their own respective threat model. I'll answer you with some of my thoughts, and why I do use their services.
I'll take as an example my usage of NextCloud, coming as a replacement to Google Drive for example.
let's break up the setups:
- client (mobile app, desktop client, browser)
- communication to server
- server
It's oversimplified, but to the point: In Google's setup, you have control of 0 out of three things.
- you use their closed source client, 2. they decide the communication to the server (if there's any CDN, where their servers located, TLS version), and 3. data is on their servers, wether encrypted or not is up to them.
In NextCloud's setup,
- The clients are open source (you can varify them, or build your own),
- communication to server is up to you. and in this case you trust your data with CF, that's right. gonna have to trust them.
- server is your server, and you encrypt the files how you want.
From just this look, NC is clearly better off. now, it's not perfect, and each one will do their own convenience vs privacy deal and decide their deal.
If you deploy some sort of e2ee, the severity level of CF drops even more, because they're exposed to less data. specifically for NC they do do e2ee, but each solution to its own. https://nextcloud.com/encryption/ this goes as an example for zero trust model. if you handle the encryption yourself (like using an e2ee service), you don't have to trust the medium your data is going through. like the open internet.
Thanks. I agree with your conclusion. I probably have spent too much time in privacy communities. In the end you'll have to trust someone.
that's not to wear off of the importance of awareness. you should be aware always, even if you don't take action.
surely better than Google
This contradicts your threat model comment, though. If you fear Google's access to your data, you fear nation states, or hate Google. Cloudflare is in the same boat for size, scope, and US ownership.
Obviously I'm not avoiding it all together, but I'm taking a step in the right direction.
And it's not just replacing Google by CF, because CF has much less access in comparison as I explain.
you can deploy some zero trust models in your setup, and eliminate the threat even further. for example end to end encryption
Oh yes, wasn't trying to say it was a bad decision at all. If it fits your threat model, and it makes life easier, it's probably the right choice.
Yeah it's a popular choice for various things. But wouldn't it be against TOS using it for p2p and that amount of traffic?
gotta admit I haven't read the ToS, but I didn't encounter any problems. I'm streaming GBs of music via the tunnel and it still works. p2p I didn't try, but I don't really see a reason to?
Just remember that Cloudflare decrypts and re-encrypts all your data, so they can read absolutely everything that passes through those tunnels.
mind elaborating?
If I let them handle the TLS for me then I can see that. but if, for example, I'm using NextCloud, which implement end to end encryption from client to server, then I wouldn't care if they did, no?
Huh, good to know. I'm out remember some of us have traffic in the TBs pretty month!
Nice, I recently went through the same struggle of setting up this configuration based on that LinuxServer post. My main nitpick on this is that automating the ip route configuration for the qBittorrent container is a pretty important step which is not explained in the post. Leaving any manual steps in any Docker setup is pretty bad practice.
Since you're using LinuxServer's QBT image a good way to do this is to make use of their standard custom init scripts. You can just mount a script with the ip route commands to /custom-cont-init.d/my-routes.sh:ro on the container and it will be run automatically on each startup.
Another nitpick is that the PostDown commands in the wireguard configs are useless since you're running them in Docker.
Thanks for the addition. It's also mentioned in that original blog post I linked in the article.
Yes that's how I'm automating it, and it's noted in the blog I highlighted. Your point about post down does make sense 😕
I haven't read your post, but I set this up a few years ago after finding this post: https://golb.hplar.ch/2019/01/expose-server-vpn.html
Oh cool. I couldn't find any info on doing this. And struggled lots at I don't understand Iptables