Even though I live in a studio apartment, when my doorbell goes off (dumb doorbell with a tiny mic next to it) I have HA set the alarm volume to max on both my phone and tablet and send an alarm trigger. It sounds like a bunch of sirens going off whenever someone rings the doorbell. But it’s not entirely pointless, because I wear noise-cancelling headphones all the time whenever I’m home, so there’s always a chance I won’t hear the doorbell going off.
I’ve had to bypass DPI several times in the past. V2Ray has never failed me, but I had to set it up myself on my own VPS. It wasn’t being offered commercially by any VPN providers back when I needed it. More info here: https://www.v2fly.org/en_US/
Edit: Forgot to mention, for those interested in setting this up an easier option is to let Amnezia VPN set it up for you. It’s FOSS, can be found here https://github.com/amnezia-vpn/amnezia-client
You’ll need to have your own VPS or home server though, and if you want to use V2Ray at home and do some advanced routing to enable local LAN access for example, then it’s better to set things up from scratch than to use Amnezia.
They do block Wireguard. They use DPI (Deep Packet Inspection) at the national level (it’s as expensive as it sounds). They filter and monitor all traffic. Once you have something as invasive as DPI in place, Wireguard becomes rather easy to detect, because it doesn’t hide the fact that you’re establishing a tunnel (its purpose is just to obscure the data being tunneled).
According to the specification, a specific sequence of bytes (Handshake Initiation packet) is sent by the “client” to negotiate a connection, and a Handshake Response is sent back by the “server”. The handshake packets used to negotiate a connection are basically a recognizable signature of the Wireguard protocol, so if you are able to analyze all outgoing and incoming packets (which DPI enables you to do), you can monitor for these signature packets and block the connection attempt.
There are variants of the Wireguard protocol that can circumvent this method of censorship (Amnezia Wireguard is one example), but they only work as long as they stay under the radar and don’t see mass adoption. Their own “signatures” would also just get blocked in that case.
Ultimately, bypassing this level of censorship just isn’t something Wireguard was created for. Wireguard assumes you are only concerned with obscuring your traffic, not hiding the fact that you’re using a VPN. There are better tools for this job, like this: https://www.v2fly.org/en_US/
Edit: Better link with the language set to English
Sure, that’s always an option. But we’re not talking about buying here. To be precise, yes, a copy of the game is still being bought, but then it gets distributed among 100s of people. It’s pretty much like old-school piracy: VHS tapes and burning copies of games you own onto CDs.
That being said, you aren’t missing that much if you’re completely avoiding Denuvo games. Out of all the uncracked ones that I’ve tried using this method, only two games out of the last decade or so were worth the trouble (Wukong and Hi-Fi Rush).
There’s a workaround for Denuvo: buying a copy of the game with pooled funds and sharing the game with all the participants using online activation. It’s not exactly cracking, but it is one way around it. The issue is knowing where to find such groups, or starting one yourself. I can get you into one, If anyone is interested. Just send me a PM asking to join.
You can get older stuff for free as well. Practically everything is free, but you’ll have to wait longer with the newer titles because people who donated funds take priority.
Note: Unfortunately, this takes place in a Discord group. You’ll have to use Discord and you’ll have to have an account that is at least one-month old to be able to participate.
Usenet is generally better for 0-day and recent releases, but it doesn’t hold a candle to P2P when it comes to older stuff. What’s the max retention you get with the most premium plan with reputable providers these days? I think it was 13 years last time I checked. But aside from that, it’s almost always faster than P2P (unless you have a bad connection to the server from your location) and certainly more convenient in certain categories like movies and TV shows. I still use P2P for games, software, and music though.
Edit: Forgot we were talking primarily about security. Of course Usenet is better in that regard as well. The other replies explain why that’s the case.
Anschluss 2 when?
$130 over 14 years. 🏴☠️🏴☠️🏴☠️
Did you mean to say Dolby Vision?
Re batteries: You could also set up an automation that periodically checks the status and/or availability of your battery-powered sensors. Here’s a useful community blueprint for this: https://community.home-assistant.io/t/low-battery-notifications-actions/653754
I have mine checked once a week.
Using Nicotine+ on my server. https://github.com/fletchto99/nicotine-plus-docker
Soulseek, among others. Putting my ~400 GB classical music collection out there.
I think you already have a kill-switch (of sorts) in place with the two Wireguard container setup, since your clients lose internet access (except to the local network, since there’s a separate route for that on the Wireguard “server” container") if any of the following happens:
wg-quick down wg0 inside the container)I can’t be 100% sure, because I’m not a networking expert, but this seems like enough of a “kill-switch” to me. I’m not sure what you mean by leveraging the restart. One of the things that I found annoying about the Gluetun approach is that I would have to restart every container that depends on its network stack if Gluetun itself got restarted/updated.
But anyway, I went ahead and messed around on a VPS with the Wireguard+Gluetun approach and I got it working. I am using the latest versions of The Linuxserver.io Wireguard container and Gluetun at the time of writing. There are two things missing in the Gluetun firewall configuration you posted:
MASQUERADE rule on the tunnel, meaning the tun0 interface.FORWARD packets (filter table) by default. You’ll have to change that chain rule to ACCEPT. Again, I’m not a networking expert, so I’m not sure whether or not this compromises the kill-switch in any way, at least in any way that’s relevant to the desired setup/behavior. You could potentially set a more restrictive rule to only allow traffic coming in from <wireguard_container_IP>, but I’ll leave that up to you. You’ll also need to figure out the best way to persist the rules through container restarts.First, here’s the docker compose setup I used:
networks:
wghomenet:
name: wghomenet
ipam:
config:
- subnet: 172.22.0.0/24
gateway: 172.22.0.1
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 8888:8888/tcp # HTTP proxy
- 8388:8388/tcp # Shadowsocks
- 8388:8388/udp # Shadowsocks
volumes:
- ./config:/gluetun
environment:
- VPN_SERVICE_PROVIDER=<your stuff here>
- VPN_TYPE=wireguard
# - WIREGUARD_PRIVATE_KEY=<your stuff here>
# - WIREGUARD_PRESHARED_KEY=<your stuff here>
# - WIREGUARD_ADDRESSES=<your stuff here>
# - SERVER_COUNTRIES=<your stuff here>
# Timezone for accurate log times
- TZ= <your stuff here>
# Server list updater
# See https://github.com/qdm12/gluetun-wiki/blob/main/setup/servers.md#update-the-vpn-servers-list
- UPDATER_PERIOD=24h
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
networks:
wghomenet:
ipv4_address: 172.22.0.101
wireguard-server:
image: lscr.io/linuxserver/wireguard
container_name: wireguard-server
cap_add:
- NET_ADMIN
environment:
- PUID=1000
- PGID=1001
- TZ=<your stuff here>
- INTERNAL_SUBNET=10.13.13.0
- PEERS=chromebook
volumes:
- ./config/wg-server:/config
- /lib/modules:/lib/modules #optional
restart: always
ports:
- 51820:51820/udp
networks:
wghomenet:
ipv4_address: 172.22.0.5
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
You already have your “server” container properly configured. Now for Gluetun:
I exec into the container docker exec -it gluetun sh.
Then I set the MASQUERADE rule on the tunnel: iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE.
And finally, I change the FORWARD chain policy in the filter table to ACCEPT iptables -t filter -P FORWARD ACCEPT.
Note on the last command: In my case I did iptables-legacy because all the rules were defined there already (iptables gives you a warning if that’s the case), but your container’s version may vary. I saw different behavior on the testing container I spun up on the VPS compared to the one I have running on my homelab.
Good luck, and let me know if you run into any issues!
EDIT: The rules look like this afterwards:
Output of iptables-legacy -vL -t filter:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
10710 788K ACCEPT all -- lo any anywhere anywhere
16698 14M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
1 40 ACCEPT all -- eth0 any anywhere 172.22.0.0/24
# note the ACCEPT policy here
Chain FORWARD (policy ACCEPT 3593 packets, 1681K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
10710 788K ACCEPT all -- any lo anywhere anywhere
13394 1518K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- any eth0 dac4b9c06987 172.22.0.0/24
1 176 ACCEPT udp -- any eth0 anywhere connected-by.global-layer.com udp dpt:1637
916 55072 ACCEPT all -- any tun0 anywhere anywhere
And the output of iptables -vL -t nat:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER_OUTPUT all -- any any anywhere 127.0.0.11
# note the MASQUERADE rule here
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER_POSTROUTING all -- any any anywhere 127.0.0.11
312 18936 MASQUERADE all -- any tun+ anywhere anywhere
Chain DOCKER_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- any any anywhere 127.0.0.11 tcp dpt:domain to:127.0.0.11:39905
0 0 DNAT udp -- any any anywhere 127.0.0.11 udp dpt:domain to:127.0.0.11:56734
Chain DOCKER_POSTROUTING (1 references)
pkts bytes target prot opt in out source destination
0 0 SNAT tcp -- any any 127.0.0.11 anywhere tcp spt:39905 to::53
0 0 SNAT udp -- any any 127.0.0.11 anywhere udp spt:56734 to::53
Gluetun likely doesn’t have the proper firewall rules in place to enable this sort of traffic routing, simply because it’s made for another use case (using the container’s network stack directly with network_mode: "service:gluetun").
Try to first get this setup working with two vanilla Wireguard containers (instead of Wireguard + gluetun). If it does, you’ll know that your Wireguard “server” container is properly set up. Then replace the second container that’s acting as a VPN client with gluetun and run tcpdump again. You likely need to add a postrouting masquerade rule on the NAT table.
Here’s my own working setup for reference.
Wireguard “server” container:
[Interface]
Address = <address>
ListenPort = 51820
PrivateKey = <privateKey>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = wg set wg0 fwmark 51820
PostUp = ip -4 route add 0.0.0.0/0 via 172.22.0.101 table 51820
PostUp = ip -4 rule add not fwmark 51820 table 51820
PostUp = ip -4 rule add table main suppress_prefixlength 0
PostUp = ip route add 192.168.16.0/24 via 172.22.0.1
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip route del 192.168.16.0/24 via 172.22.0.1
#peer configurations (clients) go here
and the Wireguard VPN client that I route traffic through:
# Based on my VPN provider's configuration + additional firewall rules to route traffic correctly
[Interface]
PrivateKey = <key>
Address = <address>
DNS = 192.168.16.81 # local Adguard
PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE #Route traffic coming in from outside the container (host/other container)
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE
[Peer]
PublicKey = <key>
AllowedIPs = 0.0.0.0/0
Endpoint = <endpoint_IP>:51820
Note the NAT MASQUERADE rule.
I don’t get it.