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
On 6/6/21, Christian McDonald wrote:
> Would it not be better for wg to just fail outright instead of
> transforming a poorly generated key entered by a user, regardless of
> where the key came from? Especially if that problematic key passes the
> regex validation that was provided in another
Would it not be better for wg to just fail outright instead of
transforming a poorly generated key entered by a user, regardless of
where the key came from? Especially if that problematic key passes the
regex validation that was provided in another thread in this email
list? If not, what would be
It looks like whatever is generating those private keys is not
clamping them. Specifically, all private keys should undergo this
transformation:
key[0] &= 248;
key[31] = (key[31] & 127) | 64;
In your case, your `Lm` prefix (first byte: 0x2c) is being anded with
248, and thus
Hi Jason,
I've got an interesting case here. I've got what appears to be a few
private keys provided by Mullvad that are being mangled by wg(8) on
FreeBSD12.2 (pfSense 2.5.1+).
Private key ```Lm0BA4UyPilHH5qnXCfr6Lw8ynecOPor88tljLy3ALk=``` ...
becomes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
An experimental snapshot, v0.0.20210606, of WireGuard for FreeBSD has been
been tagged in the git repository.
At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues.
This patch depends on da5095d052860baa7fe2932fb1209628dd3e3813 from udp_tunnel
module,
and allows to bind the transport socket to a specific interface.
With this patch, it is possible to use wireguard with VRFs:
The transport uses a separate "WAN" VRF, cleanly isolating Local/VPN and WAN
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
11 matches
Mail list logo
