Wireguard address binding - how to fix?

Wireguard address binding - how to fix?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


Hello,

the problem of wireguard being unable to bind to an IP address are
hunting us over and over again. Isolation via namespace is not always a
solution and I would consider it a hack in the first place.

To the wireguard authors: what needs to be done to add IP address
binding so that packets are always sent from a specific IP address?

Virtually every other network software out there has that option for a
good reason, only wireguard does not support it and thus does not work
properly on devices with multiple IP addresses.

What does it take to add IP address binding in wireguard?

Best regards,

Nico

-- 
Sustainable and modern Infrastructures by ungleich.ch

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: Wireguard address binding - how to fix?

[Daniel Gröber]

On Tue, May 14, 2024 at 12:50:25PM +0200, Nico Schottelius wrote:
> To the wireguard authors: what needs to be done to add IP address
> binding so that packets are always sent from a specific IP address?

Implemented, but wating for Jason to respond:
  https://lore.kernel.org/netdev/20240219114334.3057169-1-dxld@darkboxed.org/T/

--Daniel

Re: Wireguard address binding - how to fix?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]


Hello Jason,

do you mind applying the patch from Daniel? Or is there anything wrong with it?

Daniel: amazing work, I was not aware that you have already put in the
hard work, thank you so very much!

The world (*) is suffering because of the lack of IP address binding in wireguard.

Best regards,

Nico

(*) With world I refer to every engineer that needs to run wireguard in
non-trivial situations with multiple IP addresses on one host, which is
extremely common for anything that routes.

Daniel Gröber <dxld@darkboxed.org> writes:

> On Tue, May 14, 2024 at 12:50:25PM +0200, Nico Schottelius wrote:
>> To the wireguard authors: what needs to be done to add IP address
>> binding so that packets are always sent from a specific IP address?
>
> Implemented, but wating for Jason to respond:
>   https://lore.kernel.org/netdev/20240219114334.3057169-1-dxld@darkboxed.org/T/
>
> --Daniel

[-- Attachment #2.1: Type: text/plain, Size: 62 bytes --]


-- 
Sustainable and modern Infrastructures by ungleich.ch

[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: Wireguard address binding - how to fix?

[Janne Johansson]

Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
<nico.schottelius@ungleich.ch>:
> Hello Jason,
> do you mind applying the patch from Daniel? Or is there anything wrong with it?
>
> Daniel: amazing work, I was not aware that you have already put in the
> hard work, thank you so very much!
>
> The world (*) is suffering because of the lack of IP address binding in wireguard.
>
> (*) With world I refer to every engineer that needs to run wireguard in
> non-trivial situations with multiple IP addresses on one host, which is
> extremely common for anything that routes.

Well, the main reason for wg to NOT do anything special is because
routing generally is done by looking at the destination ip and then
using the routing rules which the kernel uses to tell the packet which
interface is considered "best" in order to reach that ip, which is why
icmp and udp acts like this. I am certain that many engineers
hope/think it would be more logical (or fit their designs better) if
it responded on the same interface as the packet came in or whatever
but the reason for wg to act like it does is because this is how
connection-less packets have been acting since ages. The point that
many engineers design wg endpoints "the wrong way" is probably a fault
of education when it comes to how TCP/IP stacks did and do manage IP
output.

I have zero power to decide anything regarding how wg chooses to
implement a workaround for IP being designed the way it is designed,
but I can at least see why it hasn't immediately been accepted even if
it would make some engineers suffer(*) less, at least in the short
term.

There are a lot of workarounds for the times when you did design the
udp service as if it would act like tcp does in multihomed situations,
which includes firewall tricks, or VRF/namespace/routing-domains to
make sure the inner and outer address-pairs for the wg tunnel see
different views of the network to handle this without changing how wg
sends packets.

-- 
May the most significant bit of your life be positive.

Re: Wireguard address binding - how to fix?

[Stephan von Krawczynski]

Hello Janne,

I know that most people dealing with wg do not really understand how a box
works that has more than one IP and one interface.
A simple question: an interface has 100 IP addresses, how do you choose in wg
on which IP your tunnel end is?
Can you please (all wg infected) understand that about every box that has a
redundancy setup has several IPs per interface and you want wg connect to the
_right_ one, because this is the one taken over in case of failover.
The question is not about interface for routing, the question is about
LISTEN_ADDR.

I always thought it cannot get worse, but then came wg...
--
Regards,
Stephan




On Tue, 21 May 2024 13:11:00 +0200
Janne Johansson <icepic.dz@gmail.com> wrote:

> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
> <nico.schottelius@ungleich.ch>:
> > Hello Jason,
> > do you mind applying the patch from Daniel? Or is there anything wrong
> > with it?
> >
> > Daniel: amazing work, I was not aware that you have already put in the
> > hard work, thank you so very much!
> >
> > The world (*) is suffering because of the lack of IP address binding in
> > wireguard.
> >
> > (*) With world I refer to every engineer that needs to run wireguard in
> > non-trivial situations with multiple IP addresses on one host, which is
> > extremely common for anything that routes.  
> 
> Well, the main reason for wg to NOT do anything special is because
> routing generally is done by looking at the destination ip and then
> using the routing rules which the kernel uses to tell the packet which
> interface is considered "best" in order to reach that ip, which is why
> icmp and udp acts like this. I am certain that many engineers
> hope/think it would be more logical (or fit their designs better) if
> it responded on the same interface as the packet came in or whatever
> but the reason for wg to act like it does is because this is how
> connection-less packets have been acting since ages. The point that
> many engineers design wg endpoints "the wrong way" is probably a fault
> of education when it comes to how TCP/IP stacks did and do manage IP
> output.
> 
> I have zero power to decide anything regarding how wg chooses to
> implement a workaround for IP being designed the way it is designed,
> but I can at least see why it hasn't immediately been accepted even if
> it would make some engineers suffer(*) less, at least in the short
> term.
> 
> There are a lot of workarounds for the times when you did design the
> udp service as if it would act like tcp does in multihomed situations,
> which includes firewall tricks, or VRF/namespace/routing-domains to
> make sure the inner and outer address-pairs for the wg tunnel see
> different views of the network to handle this without changing how wg
> sends packets.
> 
> -- 
> May the most significant bit of your life be positive.

Re: Wireguard address binding - how to fix?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]


Hello Janne,

Janne Johansson <icepic.dz@gmail.com> writes:

> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
> <nico.schottelius@ungleich.ch>:
>> Hello Jason,
>> do you mind applying the patch from Daniel? Or is there anything wrong with it?
>>
>> Daniel: amazing work, I was not aware that you have already put in the
>> hard work, thank you so very much!
>>
>> The world (*) is suffering because of the lack of IP address binding in wireguard.
>>
>> (*) With world I refer to every engineer that needs to run wireguard in
>> non-trivial situations with multiple IP addresses on one host, which is
>> extremely common for anything that routes.
>
> Well, the main reason for wg to NOT do anything special is because
> routing generally is done by looking at the destination ip and then

No. Generally speaking that is incorrect.
It is not special to reply with the same IP address.

Generally speaking, when you have systems with multiple IP addresses you
want to be able to steer the binding to an IP address. And even if you
don't do that, you reply with the same IP address you have been
contacted with. Wireguard does neither of it at the moment.  I have
written this already many times on this list, but the reason is very
easy:

- A connection is initiated from device A, connecting to router B on IP adddress a.b.c.d
- The packet is correctly received by router B
- The router replies incorrectly with address f.d.g.h
- The reply packet is correctly blocked at the firewall of device A, because it comes
  from a random, unknown IP address

This is the basic 101 of networking is to reply with the same address
you have been contacted with, there is no discussion necessary. The
whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or
so.

Routing choices are independent of that, replying with the same IP
address is a standard behaviour.

Nico

(*) As does ssh, nginx, ipsec protocols, openvpn, any rails application,
any python application - I am not sure which software that binds to a
socket does not support it, with the exception of wireguard.


[-- Attachment #2.1: Type: text/plain, Size: 62 bytes --]


-- 
Sustainable and modern Infrastructures by ungleich.ch

[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: Wireguard address binding - how to fix?

[Sebastian Hyrvall]

The reason wireguard does it like this I think is because when designing 
it there was no thought given to any client,server scenario.

Both sides are behaving like clients that can jump between IPs at any 
time. This is a flawed concept given that in 90% of scenarios there
is at least one side acting as a server on a static ip. Unless the 
server side is a home user on dynamic ip and rebinding could be difficult.

I've also given a bit of thought to the security aspect of this for VPN 
providers. Since a remote party can override the configured "Endpoint" 
if there was a scenario where vpn provider privkeys are
compromised. The attacker can then, by knowing the connecting clients 
ip, get him to shift over the tunnel to their server and perform a long 
term, most likely undetected, mitm attack.

Anyway. I've waited for this binding option for years. It's insane to me 
it gets ignored.

One product is for example Mikrotik hardware. They don't want to 
implement third party patches so they are waiting for this bind-patch to 
be included in the kernel. Until then we're forced to use OpenVPN in our 
setups.


On 2024-05-21 19:58, Nico Schottelius wrote:
> Hello Janne,
>
> Janne Johansson <icepic.dz@gmail.com> writes:
>
>> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
>> <nico.schottelius@ungleich.ch>:
>>> Hello Jason,
>>> do you mind applying the patch from Daniel? Or is there anything wrong with it?
>>>
>>> Daniel: amazing work, I was not aware that you have already put in the
>>> hard work, thank you so very much!
>>>
>>> The world (*) is suffering because of the lack of IP address binding in wireguard.
>>>
>>> (*) With world I refer to every engineer that needs to run wireguard in
>>> non-trivial situations with multiple IP addresses on one host, which is
>>> extremely common for anything that routes.
>> Well, the main reason for wg to NOT do anything special is because
>> routing generally is done by looking at the destination ip and then
> No. Generally speaking that is incorrect.
> It is not special to reply with the same IP address.
>
> Generally speaking, when you have systems with multiple IP addresses you
> want to be able to steer the binding to an IP address. And even if you
> don't do that, you reply with the same IP address you have been
> contacted with. Wireguard does neither of it at the moment.  I have
> written this already many times on this list, but the reason is very
> easy:
>
> - A connection is initiated from device A, connecting to router B on IP adddress a.b.c.d
> - The packet is correctly received by router B
> - The router replies incorrectly with address f.d.g.h
> - The reply packet is correctly blocked at the firewall of device A, because it comes
>    from a random, unknown IP address
>
> This is the basic 101 of networking is to reply with the same address
> you have been contacted with, there is no discussion necessary. The
> whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or
> so.
>
> Routing choices are independent of that, replying with the same IP
> address is a standard behaviour.
>
> Nico
>
> (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application,
> any python application - I am not sure which software that binds to a
> socket does not support it, with the exception of wireguard.
>
>

Re: Wireguard address binding - how to fix?

[Nico Schottelius]

Hey Sebastian,


Sebastian Hyrvall <sh@keff.org> writes:
> [...]
> Anyway. I've waited for this binding option for years. It's insane to
> me it gets ignored.

I have to second this very strongly.

> One product is for example Mikrotik hardware. They don't want to
> implement third party patches so they are waiting for this bind-patch
> to be included in the kernel. Until then we're forced to use OpenVPN
> in our setups.

As well as this one. As written in the previous mail, virtually every
established networking software out there supports IP address binding,
with the exception of wireguard.

Dear wireguard authors, can be go into the direction of accepting an
already written patch (thanks again Daniel) or if that patch is not
suitable for some reason at least discuss what needs to be changed so
that IP address binding can make its way into wireguard?

BR,

Nico


-- 
Sustainable and modern Infrastructures by ungleich.ch

Re: Wireguard address binding - how to fix?

[Stephan von Krawczynski]

Hello Sebastian,

great to hear that you came to the same conclusion regarding the security of
wg. You have never read me on the list as I get continuously censored away
from it.
Obviously because my first post 3 years ago was exactly this:

#########################

From: Stephan von Krawczynski <skraw.ml@ithnet.com>
To: wireguard@lists.zx2c4.com
Subject: How to set source ip of wireguard packets?
Date: Tue, 20 Oct 2020 13:27:46 +0200
Organization: ith Kommunikationstechnik GmbH
X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu)

Hello all,

configuring wireguard for the first time I ran into a question I could not
find any answer in the docs, so:
Lets assume both client and server have several IPs on their outgoing
interface. How do you setup wireguard so that a specific IP is used as source
ip in the outgoing encrypted packets?
This is important in failover-setups where a VIP moves between some physical
hosts and we don't want to listen on the physical IPs but only the VIP ...

I would have expected this to be specified in "ListenPort" optionally like 
"ListenPort = IP:PORT", but that does not work currently.

--
Regards,
Stephan

###############################

Ever since I was censored away. I came to the same conclusion, which is that
wg is in fact only an orchestrated way to get vpn over the world completely
open to mitm attacks, just like your conclusion.
Even better the very same people always talk about the insecurity of PPTP,
completely dumping the fact that every PPP since the very beginning has a
(script) interface where you can check the connecting _IPs_ and users.
We don't talk about the encryption security here, because I bet that we all
cannot analyse this point in wg, away from the fact the special implementation
should be deeply reviewed, too.
Therefore we judge the current wg as high security risk which should not be
used in professional environment. A VPN where you cannot even verify the
connecting IP? Gimme a break ...
Being one of the last "forkers" of the cipe project where all wg problems were
solved decades ago we do really wonder why this project gets so much code
support being so badly designed from the start. That is why we think it is
orchestrated by interested parties.
While we're at it, the very same seems to be going on in the certificate
business where it is prevented for decades by the browser people to use
self-signed certificates which could be verified dead easy by a pointer in the
corresponding domains' dns-record.
We are not amused.
--
Regards
Stephan



On Tue, 21 May 2024 21:11:31 +0700
Sebastian Hyrvall <sh@keff.org> wrote:

> The reason wireguard does it like this I think is because when designing 
> it there was no thought given to any client,server scenario.
> 
> Both sides are behaving like clients that can jump between IPs at any 
> time. This is a flawed concept given that in 90% of scenarios there
> is at least one side acting as a server on a static ip. Unless the 
> server side is a home user on dynamic ip and rebinding could be difficult.
> 
> I've also given a bit of thought to the security aspect of this for VPN 
> providers. Since a remote party can override the configured "Endpoint" 
> if there was a scenario where vpn provider privkeys are
> compromised. The attacker can then, by knowing the connecting clients 
> ip, get him to shift over the tunnel to their server and perform a long 
> term, most likely undetected, mitm attack.
> 
> Anyway. I've waited for this binding option for years. It's insane to me 
> it gets ignored.
> 
> One product is for example Mikrotik hardware. They don't want to 
> implement third party patches so they are waiting for this bind-patch to 
> be included in the kernel. Until then we're forced to use OpenVPN in our 
> setups.
> 
> 
> On 2024-05-21 19:58, Nico Schottelius wrote:
> > Hello Janne,
> >
> > Janne Johansson <icepic.dz@gmail.com> writes:
> >  
> >> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
> >> <nico.schottelius@ungleich.ch>:  
> >>> Hello Jason,
> >>> do you mind applying the patch from Daniel? Or is there anything wrong
> >>> with it?
> >>>
> >>> Daniel: amazing work, I was not aware that you have already put in the
> >>> hard work, thank you so very much!
> >>>
> >>> The world (*) is suffering because of the lack of IP address binding in
> >>> wireguard.
> >>>
> >>> (*) With world I refer to every engineer that needs to run wireguard in
> >>> non-trivial situations with multiple IP addresses on one host, which is
> >>> extremely common for anything that routes.  
> >> Well, the main reason for wg to NOT do anything special is because
> >> routing generally is done by looking at the destination ip and then  
> > No. Generally speaking that is incorrect.
> > It is not special to reply with the same IP address.
> >
> > Generally speaking, when you have systems with multiple IP addresses you
> > want to be able to steer the binding to an IP address. And even if you
> > don't do that, you reply with the same IP address you have been
> > contacted with. Wireguard does neither of it at the moment.  I have
> > written this already many times on this list, but the reason is very
> > easy:
> >
> > - A connection is initiated from device A, connecting to router B on IP
> > adddress a.b.c.d
> > - The packet is correctly received by router B
> > - The router replies incorrectly with address f.d.g.h
> > - The reply packet is correctly blocked at the firewall of device A,
> > because it comes from a random, unknown IP address
> >
> > This is the basic 101 of networking is to reply with the same address
> > you have been contacted with, there is no discussion necessary. The
> > whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or
> > so.
> >
> > Routing choices are independent of that, replying with the same IP
> > address is a standard behaviour.
> >
> > Nico
> >
> > (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application,
> > any python application - I am not sure which software that binds to a
> > socket does not support it, with the exception of wireguard.
> >
> >  

Re: Wireguard address binding - how to fix?

[d tbsky]

> Sebastian Hyrvall <sh@keff.org> writes:
> > [...]
> > Anyway. I've waited for this binding option for years. It's insane to
> > me it gets ignored.

I  remembered how exciting when I tested wireguard at 2017. until I
asked muti-home question in the list.
wiregurad is beautiful,elegant,fast but not easy to get along with.
openvpn is not so amazing but it can get the job done.

Re: Wireguard address binding - how to fix?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]


d tbsky <tbskyd@gmail.com> writes:
> I  remembered how exciting when I tested wireguard at 2017. until I
> asked muti-home question in the list.
> wiregurad is beautiful,elegant,fast but not easy to get along with.
> openvpn is not so amazing but it can get the job done.

Nice summary, hits the nail quite well.

Jason, do you mind having a look at the submitted patches for IP address
binding and comment on them? Or alternatively can you give green light
for generally moving forward so that a direct inclusion in the Linux
kernel would be accepted?

Best regards,

Nico




[-- Attachment #2.1: Type: text/plain, Size: 62 bytes --]


-- 
Sustainable and modern Infrastructures by ungleich.ch

[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: Wireguard address binding - how to fix?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]


Jason,

may I shortly ask what your opinion is on the patch and whether there is
a way forward to make wireguard usable on systems with multiple IP
addresses?

Best regards,

Nico

Nico Schottelius <nico.schottelius@ungleich.ch> writes:

> d tbsky <tbskyd@gmail.com> writes:
>> I  remembered how exciting when I tested wireguard at 2017. until I
>> asked muti-home question in the list.
>> wiregurad is beautiful,elegant,fast but not easy to get along with.
>> openvpn is not so amazing but it can get the job done.
>
> Nice summary, hits the nail quite well.
>
> Jason, do you mind having a look at the submitted patches for IP address
> binding and comment on them? Or alternatively can you give green light
> for generally moving forward so that a direct inclusion in the Linux
> kernel would be accepted?
>
> Best regards,
>
> Nico

[-- Attachment #2.1: Type: text/plain, Size: 62 bytes --]


-- 
Sustainable and modern Infrastructures by ungleich.ch

[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: Wireguard address binding - how to fix?

[Stephan von Krawczynski]

Thank you Adrian,

but remember, we are all trained professionals here mostly "skilled in the
art". Which means we all know _hacks_ to do just about everything.
But honestly, do you favor a security-based project where you have to hack
around its deficiencies to make it work how it should?

Btw, some of us aren't even allowed to post in the ML. Guess why ...
--
Regards,
Stephan


On Mon, 24 Jun 2024 10:36:06 +0100 Adrian Larsen
<alarsen@maidenheadbridge.com> wrote:

> Hi Friends,
> 
> You can achieve address binding on a Linux box with a mix of marking, ip 
> rules, ip route and Source NAT.
> 
> 1) On WG interface, add "FwMark = 0x34" (the value 0x34 is an example, 
> you can put any value here)
> 
> 2) Create IP Rule "from all fwmark 0x34 lookup rt_wg0_out" -> this will 
> force the outgoing packet to use the route table "rt_wg0_out"
> 
> 3) On the route table "rt_wg0_out" create the default or specific route 
> to force the packet market with 0x34 to leave using the interface where 
> your desire "IP address" resides.
> 
> 4) Create a POSTROUTING -> SNAT forcing mark 0x34 via the desired "IP 
> address". This will bind your "IP address".
> 
> Done! The packet with mark 0x34 will be routed via the correct interface 
> using the source IP you want.
> 
> I hope this helps.
> 
> Best regards,
> 
> Adrian Larsen
> Maidenhead Bridge
> Cloud Security Connectors for SSE vendors.
> m: +44 7487640352
> e:alarsen@maidenheadbridge.com
> 
> On 09/06/2024 16:39, Nico Schottelius wrote:
> > Jason,
> >
> > may I shortly ask what your opinion is on the patch and whether there is
> > a way forward to make wireguard usable on systems with multiple IP
> > addresses?
> >
> > Best regards,
> >
> > Nico
> >
> > Nico Schottelius<nico.schottelius@ungleich.ch>  writes:
> >  
> >> d tbsky<tbskyd@gmail.com>  writes:  
> >>> I  remembered how exciting when I tested wireguard at 2017. until I
> >>> asked muti-home question in the list.
> >>> wiregurad is beautiful,elegant,fast but not easy to get along with.
> >>> openvpn is not so amazing but it can get the job done.  
> >> Nice summary, hits the nail quite well.
> >>
> >> Jason, do you mind having a look at the submitted patches for IP address
> >> binding and comment on them? Or alternatively can you give green light
> >> for generally moving forward so that a direct inclusion in the Linux
> >> kernel would be accepted?
> >>
> >> Best regards,
> >>
> >> Nico
> >>  
>