On Wed, 30 Sep 2020 15:42:19 -0700
PGNet Dev wrote:
> I've two linux machines connected with wg.
>
> Machine #1 is a remote VM, & connects to the public 'net.
>
> Machine #2 is local, on my LAN.
>
> To date, they've only routed internal traffic. Nice -n- easy.
>
> I'm adding forwarding of
On 27.09.20 01:24, prope...@secmail.pro wrote:
> This is severe security risk.
Yeah, but the Windows Firewall does manage to block WG packets, doesn't it?
Thus IMHO the security problem is on Comodo's side as they obviously
don't use the same system interface as the Windows firewall. It's their
I'm running the f-droid repo of the wireguard client on lineageos 17.1
After the tunnel is up:
I can ping the wireguard client, and I can initiate an outgoing connection
through the tunnel.
However, a process binding on all interfaces will not see any incoming traffic
on tun0.
The same
In answer to my own conribution and to further clarify the problem:
The server address was given as a DNS Name rather than an ip number.
Replacing it with the ip number, it works.
This probably means that wireguard tries to contact the server before DNS is
functioning.
And this does not
On 10/1/20 6:07 AM, B K E wrote:
> it's probably the easiest to let wg-quick do its work, then by hand modify
> the routes so they are correct, and then put the necessary route commands in
> a PostUp script.
yep.
Once I figured out that on _linux_, turning OFF auto-route generation is done
On Thu, Oct 1, 2020 at 1:24 PM Jasper Knockaert wrote:
>
> Hi
>
> Just one other issue with the MacOS client. When you have multiple users
> on the same computer (say user A and user B) user A can import a
> WireGuard config in the client. Then another user B can see the config
> name, but cannot
Hi
Just one other issue with the MacOS client. When you have multiple users
on the same computer (say user A and user B) user A can import a
WireGuard config in the client. Then another user B can see the config
name, but cannot modify or connect because the required keys are in the
Keychain
I've two linux machines connected with wg.
Machine #1 is a remote VM, & connects to the public 'net.
Machine #2 is local, on my LAN.
To date, they've only routed internal traffic. Nice -n- easy.
I'm adding forwarding of specific EXTERNAL traffic from the 'net, received at
Machine #1, to
Hi Laura,
We're actually trying to respond to these events using Apple's new
network extension notification APIs. But it seems like the behavior
can be a bit inconsistent and has changed between versions. We'll
devote some development cycles to improving this hopefully not before
too long.
Jason
Hello,
wg-quick in its default configuration causes routing conflicts when the same
host is also running a kubernetes
master node. The issue seems to be how wg-quick marks the traffic to route to
the Wireguard peer:
https://www.wireguard.com/netns/#routing-all-your-traffic
This leads to a loss
On Mon, Sep 28, 2020 at 3:00 PM Laura Smith
wrote:
>
> I am starting to seriously consider switching back to OpenVPN.
>
> Wireguard is great and all that, but frankly if there's not going to be any
> effort by the developers to fix these Mac and iOS problems then I'm not going
> to stick around
On Windows, wireguard is not obeying Comodo Firewall because wireguard
wintun network adapter is not including comodo's driver.
Note that this problem doesn't occur on OpenVPN's network adapter (V9)
because it loads comodo driver.
1. Disable Windows Firewall on Win10
2. Install Comodo
I'm running the f-droid repo of the wireguard client on lineageos 17.1
When set auto autostart on boot, it does run.
The wireguard process is running and the tun0 interface is up with its setup ip
address.
However the tunnel is not working. I can't ping the server.
After manually disabling and
FWIW, I first publicly reported this same problem with iOS in Jan
2020: https://lists.zx2c4.com/pipermail/wireguard/2020-January/004860.html
(with much more followup information in
https://lists.zx2c4.com/pipermail/wireguard/2020-January/004874.html).
It still happens periodically on my iOS 13
Same issue here. After a long time of being stable (since the iOS
betas), it now stops working when the phone switches from WiFi to cell
service and back. It shows connected but nothing can go through the
WG connection.
This, on a setup that was working perfectly for a long time. It
started not
Hey,
I'm not a MAC or iOS user but I've seen issues where if the peer
endpoint uses a DNS hostname, when the device tries to reconnect to
the endpoint cause DNS resolution isn't working it can't connect.
You tried hard coding the IP?
--
Jonny
--
Jonny
On Mon, 28 Sep 2020 at 14:12, Laura Smith
FWIW, I first publicly reported this same problem with iOS in Jan
2020: https://lists.zx2c4.com/pipermail/wireguard/2020-January/004860.html
(with much more followup information in
https://lists.zx2c4.com/pipermail/wireguard/2020-January/004874.html).
It still happens periodically on my iOS 13
17 matches
Mail list logo
