Score:1

Wireguard forward traffic to host

cn flag

I'm using Wireguard as docker container on a pi. I'm running a couple other services on the pi that I want to be only accessible over the wireguard connection. The wireguard server created an interface wg0 and a subnet 10.8.0.0/24. From inside the container I'm able to connect to the host via 172.17.0.1 so I searched and was able to create the following configuration inside the container:

iptables -t nat -A PREROUTING -d 10.8.0.1/32 -j DNAT --to-destination 172.17.0.1

This allows me to connect from the wireguard client to the wireguard host ip 10.8.0.1 and through that way connect to all services running on the and other containers.

This works fine except that the source ip shows the ip from the docker container.

I have 3 questions:

  1. Is there any way to show the source ip as 10.8.0.2 (the wireguard client ip)?
  2. Does this impose any security risks?
  3. Is there a better way to do this?

I'm aware that I could also use docker host mode instead of bridge mode but that comes with it's own set of challenges. I also know that I could access 172.17.0.1 from the vpn client. Only that doesn't work when connected to multiple vpn's at the same time.

Many thanks in advance.

Score:1
cn flag
  1. Is there any way to show the source ip as 10.8.0.2 (the wireguard client ip)?

You probably also have an iptables rule running in the container that looks like this:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

That is what is changing the source IP of connections forwarded through the WireGuard container. With your current approach, to avoid using this rule, you'd have to adjust the routing in each of the other containers to use the WireGuard container as their gateway to the remote WireGuard client.

  1. Does this impose any security risks?

The remote WireGuard client can access any network services that the WireGuard container itself can access.

  1. Is there a better way to do this?

The simplest alternative would be to launch the other containers into the WireGuard container's own network namespace, like the following:

First, launch the WireGuard container with a name, like my-wg-container:

sudo docker run \
    --cap-add NET_ADMIN \
    --name my-wg-container \
    --publish 51820:51820/udp \
    --rm \
    --volume /srv/my-wg-container/conf:/etc/wireguard \
    procustodibus/wireguard

Then, launch the other containers into the WireGuard container's network namespace, with the --network container:my-wg-container option:

sudo docker run \
    --name my-web-server \
    --network container:my-wg-container \
    --rm \
    nginx

If the WireGuard container is using 10.8.0.1 for the address of its WireGuard interface (like in your example), you can access the web server runing in the my-web-server container at http://10.8.0.1/ from the remote WireGuard client. See the Use For Container Network section of this WireGuard containers guide for a complete example.

With this approach, you don't have to do anything special to the other containers (other than attach them to the WireGuard container), and the remote WireGuard client can only access services in the attached containers (instead of any other network services accessible to the WireGuard container).

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.