You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not exactly a bug or an RFE, maybe more a request for help - though the RFE would be to make what I've tried to do on my side a supported use case.
My goal was to run this container as a router within a MACVLAN network, so that my other devices could use it as a gateway. I've been successful in that I've managed to make other contains route their traffic through the VPN both from the same machine and from other machines, as well as outside docker by creating network namespaces in Linux. So far so good.
The issue is that when downloading large files, I get top-notch bandwidth (talking 200Mbps) for a minute or 2, and then several minutes of 0-bandwidth; then the cycle repeats. This does NOT happen when I download large files from a computer on the same LAN using a ProtonVPN client. This DOES happen even if I add throttling on the download client. This DOES happen no matter if the download client is running inside the protonwire container, in another container, or outside docker in a network namespace using protonwire as gateway.
Here's the Ansible version of my current protonwire setup:
docker_container:
name: protonvpn
image: ghcr.io/tprasadtp/protonwire:latest
init: true
restart_policy: unless-stopped
state: started
env:
WIREGUARD_PRIVATE_KEY: "{{ proton_vpn_private_key }}"
PROTONVPN_SERVER: "node-nl-110.protonvpn.net" # since then replaced by a premium server, same issue though
DEBUG: "0"
KILL_SWITCH: "1"
capabilities:
- NET_ADMIN
sysctls:
net.ipv4.conf.all.rp_filter: 2
net.ipv4.conf.all.src_valid_mark: 1
net.ipv6.conf.all.disable_ipv6: 1
mounts:
- type: tmpfs
target: /tmp
networks:
- name: macvlan-vpn
ipv4_address: 192.168.1.225
This is fairly close to the official docker-compose structure, I've added net.ipv4.conf.all.src_valid_mark: 1 after reading somewhere that this was needed for proper ip forwarding and use as a gateway - but bear in mind my knowledge of networks only goes so far.
Can anyone reading this relate to what is happening? Is there a best practice I'm missing that may be causing this behaviour?
Cheers
Pierric.
Code of Conduct & PII Redaction
I have verified that this feature request is not a duplicate and is not not addressed by the FAQ and Troubleshooting.
I agree to follow this project's Code of Conduct
I have removed any sensitive personally identifying information(PII) and secrets from in this issue report.
The text was updated successfully, but these errors were encountered:
Update: while I'm not 100% sure of anything, I believe this is not specific to this container image. I've had similar issue connecting to Proton via a WireGuard container image (from linuxserver). Connecting from Windows or Linux openVPN or Wireguard clients outside of Docker, I have no issue (barring a potential CPU one with openVPN on a small VM). So it must be something related to Docker networking.
While I'd love for this to work with Docker, for now I've set up a small VM that acts as the gateway I wanted.
Version
latest arm64
Details about Feature/Enhancement
This is not exactly a bug or an RFE, maybe more a request for help - though the RFE would be to make what I've tried to do on my side a supported use case.
My goal was to run this container as a router within a MACVLAN network, so that my other devices could use it as a gateway. I've been successful in that I've managed to make other contains route their traffic through the VPN both from the same machine and from other machines, as well as outside docker by creating network namespaces in Linux. So far so good.
The issue is that when downloading large files, I get top-notch bandwidth (talking 200Mbps) for a minute or 2, and then several minutes of 0-bandwidth; then the cycle repeats. This does NOT happen when I download large files from a computer on the same LAN using a ProtonVPN client. This DOES happen even if I add throttling on the download client. This DOES happen no matter if the download client is running inside the protonwire container, in another container, or outside docker in a network namespace using protonwire as gateway.
Here's the Ansible version of my current protonwire setup:
This is fairly close to the official docker-compose structure, I've added
net.ipv4.conf.all.src_valid_mark: 1
after reading somewhere that this was needed for proper ip forwarding and use as a gateway - but bear in mind my knowledge of networks only goes so far.Can anyone reading this relate to what is happening? Is there a best practice I'm missing that may be causing this behaviour?
Cheers
Pierric.
Code of Conduct & PII Redaction
The text was updated successfully, but these errors were encountered: