4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 as WG endpoint node
WG 0.0.20180420-1
DHCP no
Firewall off (both ends, except unknown for the GSM provider in between)
wg-quick not utilized
Android 8.1.0 (security patch level april 2018) not rooted
kernel 4.4.78
wg app 0.4.2
- establishing a connection is t
There are no "clients inside a WG tunnel", only traffic inside the tunnel :-D
Sure, till the point where you got a VPN inet gateway scenario with a wg
endpoint node to route other wg peers through to the inet. Most of those
VPN apps offering these days split DNS such as clients (routed peers
There is no need for a nob in wireguard to ensure that the wireguard
traffic goes through a specific interface or is bound to a specific ip
address.
All those statements are solely off the WG community and are certainly
commendable. However, there is no (regular) external audit of WG, at
le
Had hoped there would a way for the clients to utilize the
endpoint node's DNS resolver.
There are many ways to do that. You could setup post-up scripts that
modify resolv.conf when the wg interface is up. You could run a
caching dns server on your lan that talks to your gateway dns
On Sun, May 6, 2018 at 9:39 PM, ѽ҉ᶬḳ℠ wrote:
> With a thread model considering every piece of software being flawed in
> mind, and with whatever CVE unearthed being a point in case, it should be
> of little surprise that the question of mitigating surface exposure is
> raised. Once WG would gain
On Mon, May 7, 2018 at 1:21 PM, ѽ҉ᶬḳ℠ wrote:
> 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 as WG endpoint node
> WG 0.0.20180420-1
> DHCP no
> Firewall off (both server and client)
> wg-quick not utilized
>
> Which DNS resolver is utilized by the clients inside a WG tunnel, the
> client's resolver or the
Re-adding the ML that I removed from my response by mistake
On Mon, May 7, 2018 at 3:12 PM, ѽ҉ᶬḳ℠ wrote:
> Thank you for the instant response.
>
>>
>> Wireguard does not mess with the DNS (afaik) so whatever is already
>> configured on the client is used.
>>
>
> Had hoped there would a way for t
On May 7, 2018 11:37 AM, Matthias Urlichs wrote:
> On 07.05.2018 10:41, Jordan Glover wrote:
>
> > Pointing to go and rust implementations which are being
> >
> > worked on will be much better.
>
> They still run in userspace.
And pointing to them will be better example for argumentation. Po
4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 as WG endpoint node
WG 0.0.20180420-1
DHCP no
Firewall off (both server and client)
wg-quick not utilized
Which DNS resolver is utilized by the clients inside a WG tunnel, the
client's resolver or the server's? And can this be tweaked in WG?
---
Clients ar
On 07.05.2018 10:41, Jordan Glover wrote:
> Pointing to go and rust implementations which are being
> worked on will be much better.
They still run in userspace.
That being said, I still don't see any reason for doing something in WG
for which (a) there's no threat model, (b) a perfectly adequate
On May 7, 2018 10:24 AM, ѽ҉ᶬḳ℠ wrote:
> > SSH is different for two reasons: It runs over TCP, and it runs in
> >
> > userspace.
> >
> > Secondly, because SSH runs in userspace, a lot of the processing (such
> >
> > as the TCP handshake) is done by the kernel on the application's behalf.
> >
>
SSH is different for two reasons: It runs over TCP, and it runs in
userspace.
Secondly, because SSH runs in userspace, a lot of the processing (such
as the TCP handshake) is done by the kernel on the application's behalf.
So the only way the application has of telling the kernel not to do
this,
12 matches
Mail list logo
