Hi,
Talking about my example with chained VPNs. It is a misconfiguration but
not intentional, and no responsible administrator can solve this because
client really has no way to tell a VPN provider what MTU he needs.
Technically VP providers can make such interface for clients but none of
On Mon, 7 Jun 2021 16:46:17 +0500
Roman Mamedov wrote:
> On Mon, 7 Jun 2021 13:27:10 +0200
> "Jason A. Donenfeld" wrote:
>
> > Can you walk me through your use case a bit more, so I can wrap my mind
> > around the requirements?
> >
> > ingress --plain--> wireguard --wireguard[plain]--> vxlan
On 2021-06-06 21:03, Roman Mamedov wrote:
> On Sun, 6 Jun 2021 11:13:36 +0200
> "Jason A. Donenfeld" wrote:
>
>> Specifically the change would be to not allow IP fragmentation of the
>> encrypted UDP packets. This way, in the case of a loop, eventually the
>> packet size exceeds MTU, and it gets
On Sun, Jun 06, 2021 at 01:14:16PM +0200, Peter Linder wrote:
> This would break things for me. We're doing a lot of L2 over L3 site to
> site stuff and we are using wireguard as the outer layer. Inner layer is
> vxlan or l2tpv3.
>
> In particular, people connect lots of stuff with no regard for
This is indeed the case for me, spot on.
On 2021-06-07 13:46, Roman Mamedov wrote:
So this same host that just generated the 1574-byte encapsulated VXLAN packet
with something it received via its eth0 port, now needs to send it further to
its WG peer(s). For this to succeed, the in-tunnel WG
On Mon, 7 Jun 2021 13:27:10 +0200
"Jason A. Donenfeld" wrote:
> Can you walk me through your use case a bit more, so I can wrap my mind
> around the requirements?
>
> ingress --plain--> wireguard --wireguard[plain]--> vxlan
> --vxlan[wireguard[plain]]--> egress
Not sure I understand your
Hi Roman,
On Mon, Jun 7, 2021 at 1:13 PM Roman Mamedov wrote:
> In the L2 tunneling scenario the large VXLAN packets are generated locally, as
> it will be common for the same host (aka "the router") to be both a WG peer
> and a VXLAN VTEP, so it is going to be affected.
Can you walk me through
Hey Jason,
Jason A. Donenfeld writes:
> Hey folks,
>
> There seems to be a bit of confusion about *which* stage of
> fragmentation would be affected by the proposal, so I drew some
> diagrams to help illustrate what I'm talking about. Please take a
> look:
>
>
On Mon, 7 Jun 2021 11:34:21 +0200
"Jason A. Donenfeld" wrote:
> 2) Local egress fragmentation WOULD be affected by this and is the
> most relevant thing in this discussion. In this case, a packet that
> gets encrypted and winds up being larger than the mtu of the interface
> that the encrypted
Hey folks,
There seems to be a bit of confusion about *which* stage of
fragmentation would be affected by the proposal, so I drew some
diagrams to help illustrate what I'm talking about. Please take a
look:
https://data.zx2c4.com/potential-wg-fragmentation-proposal.png
1) Ingress fragmentation
On Sun, 6 Jun 2021 11:13:36 +0200
"Jason A. Donenfeld" wrote:
> Specifically the change would be to not allow IP fragmentation of the
> encrypted UDP packets. This way, in the case of a loop, eventually the
> packet size exceeds MTU, and it gets dropped: dumb and effective.
> Depending on how
This would break things for me. We're doing a lot of L2 over L3 site to
site stuff and we are using wireguard as the outer layer. Inner layer is
vxlan or l2tpv3.
In particular, people connect lots of stuff with no regard for MTU. For
some things it's also very hard to change so we just assume
Hello,
so given that fragmentation is disallowed the PMTU discovery always
needs to work and the wireguard MTU needs to be correctly adjusted.
Speaking of a DC situation, I think this might be tricky. Imagine the
following situation:
- endhost A has an MTU of 9k. PMTU 9k. wg 8920.
- the path
Hi,
I've dig into the subject two years ago and only vague remember details.
As far as I can recall there was a time when WireGuard set DF flag by
default and there were two issues:
1) for security reasons WireGuard doesn't issue ICMP fragmentation
required response in the unencrypted
Hi,
WireGuard is an encrypted point-to-multipoint tunnel, where onion
layering of packets via a single interface or multiple is a useful
feature. This makes handling routing loops very hard to manage and
detect. I'm considering changing and simplifying loop mitigation to a
different strategy, but
15 matches
Mail list logo
