Re: Domain as endpoint when using wireguard with network namespaces

["\"Tomcsányi, Domonkos\"" <domi@tomcsanyi.net>]

Hi, 

Thanks for the kid and detailed answer, this is quite fascinating, I never looked deep into wireguard and namespaces, only dealt with a couple of simple IPsec + namespaces scenario before.
To me your issue seems to be valid, I hope you will get an answer from Jason sooner or later.

Cheers,
Domi

> 
>> 2021. aug. 18. dátummal, 23:19 időpontban Waishon <waishon009@gmail.com> írta:
>> 
>> Hey there,
>> 
>> thanks for your reply:
>> 
>> The reason why it works when using an IP instead of a domain is the "birth namespace" concept of wiregurard. You're creating the WireGuard interface inside your init-namespace (birth-namespace) which does have an internet connection. The UDP socket for sending and receiving the encrypted packets is also created here. 
>> 
>> Afterwards you move your WireGuard interface into a newly created network namespace. The UDP socket is still inside the birth-namespace. When you now call "wg set" with an IP-Address from inside the network namespace, it "tells" the UDP socket inside the birth-namespace to connect to this endpoint over the internet connection of the birth-namespace.
>> 
>> When the UDP socket receives encrypted packets, WireGuard decrypts them and puts the network packets in the device queue of the WireGuard interface, which is inside the network namespace (I hope I understood the source code correctly). So you don't need an internet connection inside the network namespace to create a wireguard tunnel, when using an ip-address. I've tested it and it works fine, as described in the documentation https://www.wireguard.com/netns/.
>> 
>> However when using a domain, "wg set" tries to lookup the domain inside the network namespace (which doesn't have an internet connection until the tunnel is created) and not inside the birth-namespace. 
>> 
>> I think that the wg-tool should determine the namespace of the udp socket and do the DNS lookup there. However I don't know if this is even possible to implement.
>> 
>> Kind regards
>> Am 18. Aug. 2021, 07:54 +0200 schrieb Tomcsanyi, Domonkos <domi@tomcsanyi.net>:
>> I am sorry, but I need to ask: if your namespace does not have an internet connection how would you connect to your remote endpoint after the DNS lookup issue is solved and you received the IP behind vpn.example.com?
>> 
>> Kind regards,
>> Domi
>> 
>> 17.08.2021 dátummal, 23:06 időpontban Waishon <waishon009@gmail.com> írta:
>> 
>> Hey there,
>> 
>> I'm currently trying to setup a wireguard-tunnel inside a
>> network-namespace as descriped in the documentation, which fails when
>> using a domain as endpoint:
>> https://www.wireguard.com/netns/
>> 
>> First I've created the wireguard interface inside the birth-namespace
>> of the host using "ip link add wg0 type wireguard". Then I moved the
>> wg0 interface to the newly created network namespace, which doesn't
>> have any network interfaces and network connections beside the
>> loopback interface.
>> 
>> Then I configured the wg0 interface inside the network namespace using
>> wg set "INTERFACE_NAME" \
>> private-key <SECRET \
>> peer "PEER" \
>> endpoint vpn.example.com:51820 \
>> persistent-keepalive 25 \
>> allowed-ips ::/0
>> 
>> This however results in a "Temporary failure in name resolution:
>> `vpn.example.com:51820'. Trying again in 1.00 seconds..." error
>> message, which makes sense, because the wireguard-tool tries to call
>> getaddrinfo inside the network namespace. The namespace doesn't have
>> an internet connection and the lookup fails.
>> https://github.com/WireGuard/wireguard-tools/blob/96e42feb3f41e2161141d4958e2637d9dee6f90a/src/config.c#L242
>> 
>> As a user I would expect that the wg-tool does the lookup in the
>> birth-namespace of the interface and not inside the newly created
>> network namespace.
>> 
>> What is the recommended solution to resolve an domain endpoint when
>> using network namespaces and wireguard? Just manually lookup the
>> domain in the birth-namespace and use the ip as endpoint? The
>> implementation however would be quiete hacky to make it properly work
>> with IPv4 and IPv6.
>