binhex / arch-int-vpn

Docker build script for Arch Linux base with OpenVPN, WireGuard, Privoxy (http(s) proxy) and microsocks (Socks5 proxy)

Application

Privoxy
OpenVPN
WireGuard

Description

Privoxy is a non-caching web proxy with filtering capabilities for enhancing privacy, manipulating cookies and modifying web page data and HTTP headers before the page is rendered by the browser. Privoxy is a "privacy enhancing proxy", filtering Web pages and removing advertisements.

OpenVPN is an open-source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses a custom security protocol that utilizes SSL/TLS for key exchange.

WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.

Build notes

This is an intermediate Docker image which is used as a base image for other Docker images which require the OpenVPN client.

Usage

N/A, intermediate image used as a base for *VPN Docker Images.

Access application

N/A

Example

N/A, intermediate image used as a base for *VPN Docker Images.

Notes

N/A

---

If you appreciate my work, then please consider buying me a beer :D

Documentation | Support forum

arch-int-vpn's Issues

Multiple docker networks cause issues with allowing traffic to applications

My specific involves two docker networks:

• A shared one for use in a docker network for a reverse proxy
• A specific one for all services communicating with deluge (sonarr, radarr)

The issue is that iptable.sh uses the default route to figure out which the docker interface is and uses it to allow traffic to the application running in the VPN container (in this case Deluge on port 8112).

[root@94d9e466609a /]# iptables -L -v
Chain INPUT (policy DROP 107 packets, 5298 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   62  9226 ACCEPT     all  --  any    any     172.19.0.0/16        172.19.0.0/16       
29030 5394K ACCEPT     all  --  eth0   any     swiss.privacy.network  anywhere            
    0     0 ACCEPT     all  --  eth0   any     unn-156-146-62-213.cdn77.com  anywhere            
    0     0 ACCEPT     all  --  eth0   any     unn-212-102-37-2.cdn77.com  anywhere            
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8112
    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere             udp dpt:8112
    0     0 ACCEPT     tcp  --  eth0   any     172.16.0.0/12        172.19.0.0/16        tcp dpt:58846
    1    84 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-reply
  110 32135 ACCEPT     all  --  lo     any     anywhere             anywhere            
29008 3519K ACCEPT     all  --  wg0    any     anywhere             anywhere            

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 6 packets, 416 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   61  9276 ACCEPT     all  --  any    any     172.19.0.0/16        172.19.0.0/16       
30024 5060K ACCEPT     all  --  any    eth0    anywhere             swiss.privacy.network 
    0     0 ACCEPT     all  --  any    eth0    anywhere             unn-156-146-62-213.cdn77.com 
    0     0 ACCEPT     all  --  any    eth0    anywhere             unn-212-102-37-2.cdn77.com 
    0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:8112
    0     0 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp spt:8112
    0     0 ACCEPT     tcp  --  any    eth0    172.19.0.0/16        172.16.0.0/12        tcp spt:58846
    1    84 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-request
  112 32215 ACCEPT     all  --  any    lo      anywhere             anywhere            
30015 3088K ACCEPT     all  --  any    wg0     anywhere             anywhere            
[root@94d9e466609a /]# ip route
default via 172.19.0.1 dev eth0 
172.16.0.0/12 via 172.19.0.1 dev eth0 
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.3 
172.25.0.0/16 dev eth1 proto kernel scope link src 172.25.0.4 

A possible solution for the container being part of multile networks would be using a filter on interface like !wg0 (or whatever the VPN interface would be) to only dissalow access through the wireguard tunnel to Deluge.

Chain INPUT (policy DROP 107 packets, 5298 bytes)
...
    0     0 ACCEPT     tcp  --  !wg0   any     anywhere             anywhere             tcp dpt:8112
    0     0 ACCEPT     udp  --  !wg0   any     anywhere             anywhere             udp dpt:8112
...
Chain OUTPUT (policy DROP 6 packets, 416 bytes)
 pkts bytes target     prot opt in     out     source               destination         
...
    0     0 ACCEPT     tcp  --  any    !wg0    anywhere             anywhere             tcp spt:8112
    0     0 ACCEPT     udp  --  any    !wg0    anywhere             anywhere             udp spt:8112
...

Thoughts on that?

Cannot start container, tini outputs program usage

When I start this docker on my unraid machine the container immediately exits with tini writing its usage to the log:

tini (tini version 0.18.0 - git.fec3683)
Usage: tini [OPTIONS] PROGRAM -- [ARGS] | --version

Execute a program under the supervision of a valid init process (tini)

Command line options:

--version: Show version and exit.
-h: Show this help message and exit.
-s: Register as a process subreaper (requires Linux >= 3.4).
-p SIGNAL: Trigger SIGNAL when parent dies, e.g. "-p SIGKILL".
-v: Generate more verbose output. Repeat up to 3 times.
-w: Print a warning when processes are getting reaped.
-g: Send signals to the child's process group.
-e EXIT_CODE: Remap EXIT_CODE (from 0 to 255) to 0.
-l: Show license and exit.

Environment variables:

TINI_SUBREAPER: Register as a process subreaper (requires Linux >= 3.4).
TINI_VERBOSITY: Set the verbosity level (default: 1).
TINI_KILL_PROCESS_GROUP: Send signals to the child's process group.

Add support for ProtonVPN

ProtonVPN has an official command-line client for connecting to their servers: GitHub, ArchWiki. They also have a support article here: https://protonvpn.com/support/linux-vpn-setup/

PIA port assignment API is not responding

My arch-delugevpn container is failing to come up because the call to an IP address athttps://github.com/binhex/arch-int-openvpn/blob/master/run/root/getvpnport.sh#L78-L81 is failing.

Setting STRICT_PORT_FORWARD=no is a workaround.

PIA Next gen portfowarding

Dearest maintainer,

I have not been able to connect to the port forwarding IP for a few days. I have had others test it outside my network without any success either. PIA Support said "Please know that we are fully aware of the issue and we are doing our best to resolve this the soonest as possible we can."

There are a number of reddit threads about this issue and about the next gen port forwarding [1] [2]. I am honestly out of my depth with this kind of thing. I have aggregated some links to in progress work and scripts people have written for the next gen port forwarding [3] [4] [5].

There is no real action here. I just wanted to bring it to your attention. Please feel free to close it or leave it open to track a migration to next gen port forwarding.

Thank you for all of your time and work on this project

Dictated but not reviewed,
Becker

[1] https://www.reddit.com/r/PrivateInternetAccess/comments/iqt5aq/screw_you_pia/g4u4e1m/?utm_source=reddit&utm_medium=web2x&context=3
[2] https://www.reddit.com/r/PrivateInternetAccess/comments/i6qqu0/pia_portforward_request_ip_is_dead/
[3] https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh
[4] https://gist.github.com/triffid/da48f3c99f1ff334571ae49be80d591b#file-pia-portforward-sh
[5] qdm12/gluetun#236 (comment)

unable to redirect default gateway

I am using your awesome openvpn docker in two instances. In one instance, everything works perfectly. In another, I am getting this error:

Tue Dec 19 10:32:24 2017 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing

Both instances are using binhex/arch-openvpn:latest and have the exact same docker run configurations (with the exception of mounted config / data folder locations).

I noticed for the instance that is working, I see the following output:

Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: timers and/or timeouts modified
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mon Dec 18 20:27:46 2017 Socket Buffers: R=[212992->425984] S=[212992->425984]
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: --ifconfig/up options modified
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: route options modified
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: route-related options modified
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: peer-id set
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: adjusting link_mtu to 1657
Mon Dec 18 20:27:46 2017 OPTIONS IMPORT: data channel crypto options modified
Mon Dec 18 20:27:46 2017 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Dec 18 20:27:46 2017 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Dec 18 20:27:46 2017 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Dec 18 20:27:46 2017 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:03
Mon Dec 18 20:27:46 2017 TUN/TAP device tun0 opened
Mon Dec 18 20:27:46 2017 TUN/TAP TX queue length set to 100
Mon Dec 18 20:27:46 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Dec 18 20:27:46 2017 /usr/bin/ip link set dev tun0 up mtu 1500

2017-12-18 20:27:46,253 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 /usr/bin/ip addr add dev tun0 10.8.8.236/24 broadcast 10.8.8.255

2017-12-18 20:27:46,256 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 /root/openvpnup.sh tun0 1500 1585 10.8.8.236 255.255.255.0 init

2017-12-18 20:27:46,260 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 /usr/bin/ip route add 174.128.230.166/32 via 172.17.0.1

2017-12-18 20:27:46,263 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 /usr/bin/ip route add 0.0.0.0/1 via 10.8.8.1

2017-12-18 20:27:46,265 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 /usr/bin/ip route add 128.0.0.0/1 via 10.8.8.1

2017-12-18 20:27:46,268 DEBG 'start-script' stdout output:
Mon Dec 18 20:27:46 2017 Initialization Sequence Completed

2017-12-18 20:27:46,407 DEBG 'sabnzbd-script' stdout output:
[info] SABnzbd not running
[info] Attempting to start SABnzbd...

2017-12-18 20:27:47,059 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address 174.128.230.166

Here, you will see a reference

Mon Dec 18 20:27:46 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

...which appears to be missing from the failing build, and also is what its complaining about:

Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: timers and/or timeouts modified
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Tue Dec 19 10:32:24 2017 Socket Buffers: R=[212992->425984] S=[212992->425984]
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: --ifconfig/up options modified
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: route options modified
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: peer-id set
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: adjusting link_mtu to 1657
Tue Dec 19 10:32:24 2017 OPTIONS IMPORT: data channel crypto options modified
Tue Dec 19 10:32:24 2017 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Dec 19 10:32:24 2017 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Dec 19 10:32:24 2017 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2017-12-19 10:32:24,472 DEBG 'start-script' stdout output:
Tue Dec 19 10:32:24 2017 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:02
Tue Dec 19 10:32:24 2017 TUN/TAP device tun0 opened
Tue Dec 19 10:32:24 2017 TUN/TAP TX queue length set to 100
Tue Dec 19 10:32:24 2017 /root/openvpnup.sh tun0 1500 1585   init

2017-12-19 10:32:24,477 DEBG 'start-script' stdout output:
Tue Dec 19 10:32:24 2017 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing

It appears to coming from the execution of openvpn itself, in run/root/openvpn.sh but now I have hit a wall.

Any help would be greatly appreciated.

Cheers.

Torguard API+Wireguard

Torguard invalidates a wireguard config after 15 minutes of inactivity. They have an API that you can use to reactivate it. I'm trying to figure out a way to have the container run a curl to make sure the config is active when it tries bringing it up but I've run into two issues.

Wireguard has a PreUp command like the PostUp and PostDown you use for your scripts which is what it seems like I should use for this but it runs after the iptables are run so while the curl I need to do is hitting the wireguard port, it's using TCP and not UDP so it's attempting to get routed through the tunnel that's not up yet. So would it be possible to allow TCP as well as UDP to the VPN server IP?

The other issue I ran into (which was worked around easy enough through moving it to its own script instead) is, your sed to remove IPv6 is matching urls as well. I can deal with having the curl in its own script file but would be easier to just have it in the wireguard config so would it be possible to change that sed to match [a-f] instead of [a-z] since IPv6 is hex which would make the regex no longer match the https: of a url?

Env vars VPN_USER and VPN_PASS values shows up in logs.

[info] VPN_USER defined as 'USERNAME'
[info] VPN_PASS defined as 'USERPASSWORD123'

This PR #30 minimizes the scope but the line could be changed to a debug toggle level or removed altogether.

[info] VPN_USER defined as 'USERNAME'
[info] VPN_PASS last 4 defined as 'D123'

List of VPN remotes not supported

Related to binhex/arch-qbittorrentvpn#41

A method of providing a list of VPN remotes that have their own protocol and port is not available. This would be required to allow resolution of the linked issue.

Any way to use this as gluetun project

The gluetun project is great but it does not accept wireguard config and does not support domains in custom wireguard config.

I tried routing traffic through https://github.com/binhex/arch-qbittorrentvpn and it works as intended. Is there a way to make an image solely for this purpose so that any docker image can be routed through VPN using network_mode: service:vpn?

This seems like a better alternative.

drill fails when VPN provider has more than 63 A records

Copied over from binhex/arch-delugevpn#129

specify ovpn file manually through options?

is it possible to run the docker container pointing to the specific ovpn file I want to use?
eg, docker run ... -e VPN_CONFIG="/openvpn/nl2.ovpn",
rather than automagically choosing the first one available?

thanks

hosts file gets overwritten on restart

Hey, I noticed the /etc/hosts file will get overwritten on each restart, is there a way to keep manually added hosts lines?

I am using the https://github.com/binhex/arch-delugevpn variant, but I guess the corresponding code is in this repository

[FEATURE REQUEST] Custom script support

Feature request for custom scripts similar to linuxserver.io. I needed to run some additional iptables commands post-startup on binhex-privoxyvpn. I ended up copying /root/wireguardup.sh out of the container, modifying that, and volume linking my custom file into the container with that. Seems to be working well!

But I looked around for custom script support which this and downstream containers don't have, really handy feature.

I also tried modifying the PostUp and PostDown in my wg0.conf to add my additional iptables commands but it was overwritten upon restart.

https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers

So wanted to make a request. Thank you for the great contributions!!

P.S.

I ended up adding the following commands to wireguardup.sh

iptables -P FORWARD ACCEPT

iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE

This was to enable a secondary wireguard server to connect to the binhex-privoxyvpn to use that as the upstream server for clients.

My topology is like so:

PIA/Mullvad/Etc -> binhex-privoxyvpn -> wireguard (server) -> clients

The wireguard (server) has some default routing tables set to direct traffic to the binhex-privoxyvpn container.

I've run some leak testing on the downstream clients and various points, any potential for leaks?

This was done based on the following post: https://www.linuxserver.io/blog/routing-docker-host-and-container-traffic-through-wireguard

Privoxy blocking LAN http requests

In the most recent update of iptables.sh the lines

elif [[ "${APPLICATION}" == "privoxy" ]]; then
incoming_ports_ext=""
incoming_ports_lan="
fi

were removed. I think this is causing some routing problems with Privoxy. I can't get it to route requests to lan IPs. I reverted my container to a previous one and it functions correctly.

Prior to this a route from the Docker network to the LAN network was in the IP table with all ports enabled.

Google DNS Trouble

Hi @binhex I am having an issue with your Docker projects that depend on this repo. Specifically arch-delugevpn and arch-sabnzbdvpn.

The problem is that I have to block the Google DNS servers on my network because I use a Netflix region switching service (Unblock-Us). Some new devices such as Chromecasts and Rokus have the Google DNS servers hard coded in their firmware and will only fallback to my desired DNS provider (Unblock-Us) if the Google servers can't be reached. While this makes my Netflix region switching service work, it breaks your wonderful docker containers. I know this is an edge case but I'm wondering if you'd consider changing the DNS provider in your script from Google to a different public DNS service like Level3 or similar. Thanks for considering this. I'd be happy to make change this and submit a pull request if you'd be interested.

get_docker_networking() matches (and thus excludes) interfaces it shouldn't

In tools.sh is this line:

https://github.com/binhex/arch-int-vpn/blob/623db6937ba455ba39f4793cb18e1534b321d08a/run/root/tools.sh#L52C22-L52C143

The final grep will exclude any interface with lo in the name, but really it should only be excluding interfaces based on their full name.

Docker has the ability to name network interfaces, which can be very useful for disambiguating which interfaces are connected to which networks, for example:

networks:
  downloaders:
    external: false
    driver: bridge
    name: downloaders
    driver_opts:
      com.docker.network.bridge.name: br-downloaders
      com.docker.network.container_iface_prefix: downloaders

This will result in any container attached to the downloaders network having an interface named downloaders0. You can probably see where this is going already :)

Here is what happens to the command in tools.sh with/without the final grep:

[root@1402fcdd8e21 /]# ip link show | grep -v 'state DOWN' | cut -d ' ' -f 2 | grep -P -o '^[^@:]+'
lo
downloaders0
[root@1402fcdd8e21 /]# ip link show | grep -v 'state DOWN' | cut -d ' ' -f 2 | grep -P -o '^[^@:]+' | grep -P -v "lo"
[root@1402fcdd8e21 /]#

I would suggest that a better version of that grep would be:

[root@1402fcdd8e21 /]# ip link show | grep -v 'state DOWN' | cut -d ' ' -f 2 | grep -P -o '^[^@:]+' | grep -P -v "^(lo|tun0)$"
downloaders0

External IP detection not working for a custom wireguard VPN

per binhex/arch-rtorrentvpn#165 the external_ip detection here is not reliable and can lead to unintentional IP spoofing/bugs in downstream projects by incorrectly setting the external IP to the IP of ns1.google.com

https://github.com/binhex/arch-int-vpn/blob/master/run/root/getvpnextip.sh

Is this a wireguard-specific bug? The VPN being tested is mullvad wireguard

feature support for piactl / pia client for dedicatedip token usage

I am told by PIA support that their dedicated ip token only works via their vpn client. Would you consider adding support for the pia client? I see some details on using the piactl command line interface here: https://helpdesk.privateinternetaccess.com/kb/articles/pia-desktop-command-line-interface-2

Happy to assist in testing, or maybe attempt a PR myself if I was directed to the appropriate files to mimic.

ping and ping-restart ignored

Hi binhex,

I'm having issues with the docker image recently. The VPN connection is constantly restarting. After a bit of investigation, I've noticed that the pushes from the server for ping and ping-restart get ignored now. The default option --keepalive 10 60 never changes and therefore the timeouts between client and server are different, which leads to the reconnects.

Sat Nov 25 17:12:37 2017 Pushed option removed by filter: 'ping 3'
Sat Nov 25 17:12:37 2017 Pushed option removed by filter: 'ping-restart 10'

So ignoring those options may not be the best way. I've temporarily removed them and everthing works fine.

Dockerhub latest tag doesn't match master

The latest tag on Dockerhub doesn't seem to have been built from the latest master. Could you please trigger a rebuild? I'm hoping to see the changes from PR binhex/scripts#4 for further work on binhex/arch-delugevpn.

ivan@mgmt1:~/dev/binhex/arch-int-vpn$ docker run --rm -it --entrypoint=/bin/bash binhex/arch-int-vpn:latest
[root@b273509ed764 /]# cat /usr/local/bin/cleanup.sh | grep patch
[root@b273509ed764 /]# exit

I do see that the test tag has been built with the latest master.

ivan@mgmt1:~/dev/binhex/arch-int-vpn$ docker run --rm -it --entrypoint=/bin/bash binhex/arch-int-vpn:test
[root@ad9abe40a026 /]# cat /usr/local/bin/cleanup.sh | grep patch
        pacman -Ru $(pacman -Qgq base-devel | grep -v awk | grep -v pacman | grep -v sed | grep -v grep | grep -v gzip | grep -v which | grep -v patch) --noconfirm
[root@ad9abe40a026 /]# exit

Both tests above were ran with an empty docker cache.

PIA generateToken endpoint HTTP 301

My container is having issues with the generateToken endpoint and failing constantly.
After further investigation, it seems like the URL https://privateinternetaccess.com/gtoken/generateToken responds with a 301 redirect.

It doesn't appear from my tests that curl follows the Location header by default unless you specify an option to do so, which may be the problem. I followed the redirect in postman to https://www.privateinternetaccess.com/ar/gtoken/generateToken and made a similar request but that URL responds with a 404. This seems like it's mostly a PIA problem, but if the 301 is their new response then

arch-int-vpn/run/root/getvpnport.sh

Line 74 in bc3b5e0

token_json_response=$(curl --interface "${VPN_DEVICE_TYPE}" --silent --insecure -u "${VPN_USER}:${VPN_PASS}" "https://privateinternetaccess.com/gtoken/generateToken")

may need to be updated to follow redirects.

I have also submit an issue on PIAs side for further analysis. pia-foss/manual-connections#137

PIA Next Gen issue with 10.0.0.0/24 LAN_NETWORK config

My LAN network is 10.0.0.0/24, with the router as 10.0.0.1.
2020-09-29 17:53:10.640597 [info] LAN_NETWORK defined as '10.0.0.0/24'

It looks like we use the 10.0.0.1 IP to generate a token:

2020-09-29 18:10:31,032 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://10.0.0.1/authv3/generateToken'
[info] 12 retries left
[info] Retrying in 10 secs...

As a workaround, i am able to open a shell in the docker, and route that IP thru the VPN, which fixes the issue:

sh-5.0# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.2.112.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        172.17.0.1      255.255.255.0   UG    0      0        0 eth0
10.0.0.1        10.2.112.1      255.255.255.255 UGH   0      0        0 tun0
10.2.112.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.2.112.1      128.0.0.0       UG    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.98.71.68    172.17.0.1      255.255.255.255 UGH   0      0        0 eth0

sh-5.0# route add 10.0.0.1 gw 10.2.112.1

After adding the route, its all working now. But I have to apply this workaround each time the docker restarts, as the VPN IP changes each time.

Support VPN via macvlan networking

Use case: I want to be able to have my router handle the VPN itself, but setup iptables in a way, that it wouldn't leak to other interfaces on container.

My idea of implementation: Setup the container in a macvlan, and have the network router do the VPN. Make sure with iptables that outgoing traffic to internet is only allowed via that said macvlan and not via other interfaces. Probably check periodly from a public service that IP address is not your connection's but the VPN's.

IPv6 support for Wireguard

Please explain, why is this needed?

https://github.com/binhex/arch-int-vpn/blob/master/run/root/wireguard.sh#L224-L226