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 <[email protected]> >> í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 >> <[email protected]>: >> 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 <[email protected]> í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. >
