Open DiamondPrecisionComputing opened 2 years ago
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.
Indeed! Changed to use the tier value in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 and there is definitely a difference!
By default, paid servers that support P2P also support Port Forwarding. The Features key-pair determines if this is supported on the server.
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 cb99f90bb5eadd49fac87570c45f6603afecc701 (although P2P_ONLY
might get removed if it's the same as PORT_FORWARD_ONLY
).
@kvanzuijlen are you aware of a difference between 'p2p' and 'port forwarding' in terms of feature for Protonvpn? I'm looking at #1103 (comment) and thinking of removing P2P_ONLY in favor of PORT_FORWARD_ONLY. Also are all p2p servers able to port forward?
EDIT: Please answer on #1103 π Since I don't get notified for this PR anymore
Hi @qdm12,
No, I'm not sure about either π.
Tough to say with certainty. From here: https://protonvpn.com/support/port-forwarding
Note that port forwarding is only permitted on our special P2P servers.
and from here: https://protonvpn.com/blog/port-forwarding/
[...] toggle the Port Forwarding switch on. You can then connect to one of our many P2P-enabled servers.
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/
All our P2P servers support port forwarding. P2P servers can be easily identified in our apps and on our VPN configuration download pages by a double-arrow icon.
So it seems like the P2P and port forwarding features are equivalent.
It does seem like it to me, from messing with it in the ui
Seems good enough validation to me π I removed P2P_ONLY in favor of the existing PORT_FORWARD_ONLY in 5191f3558f03140442f7545f3b1aef1950529218.
5d75bbc86904d58924a400ea98faf38625ccdc4f adds 'auto-filtering' of servers to only use port forwarding compatible servers (equivalent to setting manually PORT_FORWARD_ONLY=on
if port forwarding (VPN_PORT_FORWARDING=on
) is requested. This applies to both ProtonVPN and Private Intenet Access for now, resolving 3.B.
Summary regarding original issue @DiamondPrecisionComputing
PORT_FORWARD_ONLY
added in 4c47b6f142a1bf860caa447bd45f5e5d09d35066 + 5191f3558f03140442f7545f3b1aef1950529218 and automatic filtering added in 5d75bbc86904d58924a400ea98faf38625ccdc4fTOR_ONLY
SECURE_CORE_ONLY
Regarding:
Secure Core servers only support Adblocker Normal servers only support Adblocker
Not sure what you mean here? Normal DNS traffic (plaintext, over TLS and over HTTPS) should work fine as well right?
TOR servers only support
Something missing at the end?
10Gbps local server connection
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 PORT_FORWARD_ONLY
would be usable as soon as it landed on master, but it does not seem to be working for my gluetun setup for testing. Should I wait for a release?
Yep indeed, just fixed it in ceb6ff4ca424b62110533b257c1c2551dcb605be - it was because it had the older field p2p
instead of the newer field port_forward
in the servers.json data.
Also the free detection was bugged, it's also fixed in that commit. (11pm here, see you tomorrow! π π€)
Yep indeed, just fixed it in ceb6ff4 - it was because it had the older field
p2p
instead of the newer fieldport_forward
in the servers.json data. Also the free detection was bugged, it's also fixed in that commit. (11pm here, see you tomorrow! π π€)
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 +pmp
to the username for port forwarding, and tried 4 different cities (Chicago, Denver, Phoenix, and Washington), and changing from udp to tcp and back. I also tried going from latest
to v3
image, no change.
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