-
-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Add support for ProtonVPN to identify and choose servers based upon subscription tier and/or feature set. #1103
Comments
Indeed! Changed to use the tier value in 4c47b6f and there is definitely a difference!
Is there a difference between P2P and Port forwarding??? I'm working on implementing an automatic filter if VPN_PORT_FORWARDING is turned on. Finally, this adds filters cb99f90 (although |
Hi @qdm12, No, I'm not sure about either 😞. |
Tough to say with certainty. From here: https://protonvpn.com/support/port-forwarding
and from here: https://protonvpn.com/blog/port-forwarding/
So at least all port forwarding servers are p2p servers. But I'm not sure if all p2p servers are port forwarding servers. It does seem like it to me, from messing with it in the ui. But not sure. |
I'm pretty sure that every P2P server supports port forwarding, as stated here: https://protonvpn.com/support/port-forwarding-manual-setup/
So it seems like the P2P and port forwarding features are equivalent. |
Seems good enough validation to me 😄 I removed P2P_ONLY in favor of the existing PORT_FORWARD_ONLY in 5191f35. 5d75bbc adds 'auto-filtering' of servers to only use port forwarding compatible servers (equivalent to setting manually |
Summary regarding original issue @DiamondPrecisionComputing
Regarding:
Not sure what you mean here? Normal DNS traffic (plaintext, over TLS and over HTTPS) should work fine as well right?
Something missing at the end?
I'm not sure how to identify servers with this feature. So this issue is more or less completed, just waiting for some final feedback. |
I thought |
Yep indeed, just fixed it in ceb6ff4 - it was because it had the older field |
Ah yeah, just tested it and works perfectly. Thanks! |
Just found this issue after looking through qdm12/gluetun-wiki/49, I know this is a feature request and not an issue report, but the errors mentioned on 49 are not what I'm seeing. I just updated to latest image today and am seeing errors with server filtering. I was having trouble with my router's OpenVPN connection yesterday, too. So I reset my Proton credentials and downloaded a fresh ovpn config file, updated those in my router and that is back to working. So I'm trying to get gluetun back up and running now. Along with updating the credentials I also added the missing I'm running on a Synology, DSM 7, with Container Manager compose configuration. gluetun:
image: qmcgaw/gluetun:v3
container_name: vpn-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
- 8090:8090/tcp # port for qbittorrent
- 5802:5800/tcp # port for jdownloader
volumes:
- /volume1/docker/gluetun:/gluetun
environment:
- PUID=1034 #CHANGE_TO_YOUR_UID
- PGID=65538 #CHANGE_TO_YOUR_GID
- TZ=America/Chicago #CHANGE_TO_YOUR_TZ
- VPN_SERVICE_PROVIDER=protonvpn
- VPN_TYPE=openvpn #change as per wiki
- OPENVPN_USER=[redacted]+pmp
- OPENVPN_PASSWORD=[redacted]
- VPN_PORT_FORWARDING=on
- SERVER_COUNTRIES=United States #Change based on the Wiki
- SERVER_CITIES=Washington
- HTTPPROXY=off #change to on if you wish to enable
- SHADOWSOCKS=off #change to on if you wish to enable
- FIREWALL_OUTBOUND_SUBNETS=172.20.0.0/16,192.168.1.0/24 #change this in line with your subnet see note on guide.
# - FIREWALL_VPN_INPUT_PORTS=12345 #uncomment this line and change the port as per the note on the guide
- UPDATER_PERIOD=24h
network_mode: gluetunbridge
labels:
- com.centurylinklabs.watchtower.enable=false
security_opt:
- no-new-privileges:true
restart: always |
Rolling the docker image back to 3.38.1 is working. |
What's the feature 🧐
I considered hijacking #1076 but decided that this might be a larger ask than a single feature.
The issue is that not all paid ProtonVPN servers support P2P. (By default, all paid servers that support P2P also support port forwarding.) Proton provides a server list that tells you what servers support P2P but, in their infinite wisdom, does not document what keys and values in their API determine what the server supports.
(It should probably be noted that their free servers support neither P2P nor port forwarding.)
Updating the worker that pulls and parses the JSON data from Proton's API probably shouldn't be that difficult. But, the option to let end users add variables to specify which features they require and then picking a server based on that criteria is a significantly larger ask.
Ultimately, I can see these features being useful for some. Feel free to prioritize based upon which features are more widely used, or reject all together if the demand is not there. :)
Free vs paid tier
A. This is already implemented but I believe it is based upon whether "free" is located in the server name. There is a key that dictates what tier the server is. Unsure if there will be significant change in data accuracy based upon parsing out the server name vs using the key-value pair in the API.
Adblocker (NetShield)
A. Gluetun offers adblocking built-in but implementing this requires no code change, only documentation updates. Simply add the suffix +f1 to the username for blocking malware only. Add suffix +f2 for blocking malware, ads, and trackers.
P2P and Port Forwarding
A. By default, paid servers that support P2P also support Port Forwarding. The Features key-pair determines if this is supported on the server.
B. I don't believe Gluetun currently looks to verify P2P is supported on the selected server. This could cause issues when using clients that use the P2P protocol for communication as Gluetun would continue to error until the connection was unhealthy and then try another server.
TOR
A. Select servers auto tunnel traffic through a TOR relay. The Features key-pair determines if this is supported on the server.
Secure Core/Multihop
A. Gluetun already provides this as it looks to see if the entry and exit countries are different. The Features key-pair determines if this is supported on the server. Unsure if there will be significant change if code is updated of this.
A few additional notes.
I can provide the data needed to correctly identify the key-pair values for each of the features so no one else has to go down the rabbit hole. :)
Extra information and references
No response
The text was updated successfully, but these errors were encountered: