title: WireGuard client on Alpine (Docker)
body: <p>I recently pulled <a href="https://hub.docker.com/r/kizzx2/wireguard-socks-proxy" rel="nofollow noreferrer">kizzx2/wireguard-socks-proxy</a> from Docker Hub. Running the image worked as intended and didn't cause any issues. Then I cloned the corresponding <a href="https://github.com/kizzx2/docker-wireguard-socks-proxy" rel="nofollow noreferrer">GitHub repo</a> in order to modify it to my liking. Building the image from the unmodified repo worked but it wouldn't run.</p>
  <p>First, I got a permission error which could be fixed either by running the container in <code>--privileged</code> mode or by adding</p>
  <pre><code>sed -i &quot;s:sysctl -q net.ipv4.conf.all.src_valid_mark=1:echo Skipping setting net.ipv4.conf.all.src_valid_mark:&quot; /usr/bin/wg-quick
  </code></pre>
  <p>to the entrypoint file and setting <code>--sysctl 'net.ipv4.conf.all.src_valid_mark=1'</code> in <code>docker run</code>.</p>
  <p>After that, however, another error occurred:</p>
  <pre><code>[#] iptables-restore -n
  iptables-restore v1.8.7 (legacy): iptables-restore: unable to initialize table 'raw'
  
  Error occurred at line: 1
  Try `iptables-restore -h' or 'iptables-restore --help' for more information.
  </code></pre>
  <p>According to <a href="https://github.com/linuxserver/docker-wireguard/issues/60#issuecomment-945085205" rel="nofollow noreferrer">this</a> issue comment on GitHub, changing the <code>AllowedIPs</code> in my WireGuard configuration file from <code>0.0.0.0/0</code> to <code>0.0.0.0/1, 128.0.0.0/1</code> should fix the problem. The configuration file now looks like this:</p>
  <pre><code>[Interface]
  PrivateKey = &lt;private key&gt;
  ListenPort = 51820
  DNS = 1.1.1.1
  Address = 10.13.63.181/24
  
  [Peer]
  PublicKey = &lt;public key&gt;
  AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
  Endpoint = &lt;ip&gt;:&lt;port&gt;
  PersistentKeepalive = 25
  </code></pre>
  <p>Now the container runs without any error messages but it still doesn't work. <code>curl -x socks5://localhost:1080 ifconfig.co</code>, for example, just hangs and eventually times out.
  This problem is not related to the SOCKS5 proxy since running <code>curl ifconfig.co</code> in the container leads to the same result.</p>
  <p>How can I fix this?</p>