On 9/22/2021 3:54 PM, Jason A. Donenfeld wrote:
On Wed, Sep 22, 2021 at 4:53 PM Eddie wrote:
On 9/22/2021 3:45 PM, Eddie wrote:
On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
Hi Miguel,
On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz
wrote:
After the update, when I launch the app on
On 9/22/2021 3:45 PM, Eddie wrote:
On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
Hi Miguel,
On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz
wrote:
After the update, when I launch the app on the iPad, the row in
the tunnel list has a red background, and the first time I launched
it, the
On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
Hi Miguel,
On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz wrote:
After the update, when I launch the app on the iPad, the row in the tunnel
list has a red background, and the first time I launched it, the switch started
switching very quickly
On 9/21/2021 9:50 PM, Jason A. Donenfeld wrote:
Hi,
I'm not able to reproduce the bug quite yet, but I'd like to get a
better idea of what the bug is. Can you confirm that after reimporting
configs into iOS 15, they work just fine? And the issue is just in the
14->15 flow? If this is correct, I
On 9/21/2021 5:23 PM, Eddie wrote:
Title says it all. On both iPhone and iPad.
The configuration names still show, with the slider, but trying to
activate gives: Activation failure. Unable to retrieve tunnel
information from the saved configuration.
Selecting a tunnel name doesn't
Title says it all. On both iPhone and iPad.
The configuration names still show, with the slider, but trying to
activate gives: Activation failure. Unable to retrieve tunnel
information from the saved configuration.
Selecting a tunnel name doesn't show any configuration.
Cheers.
Hi,
Sorry if this message comes out of thread, I wasn't subscribed when the messages below
were sent (I did click on the web link containing "in-reply-to").
I'm also seeing the same on iOS (an iPhone and an iPad) after I put them to
flight mode (overnight or for more than a few hours).
It seem
Hi,
Sorry if this message comes out of thread, I wasn't subscribed when the
messages below were sent (I did click on the web link containing
"in-reply-to").
I'm also seeing the same on iOS (an iPhone and an iPad) after I put them
to flight mode (overnight or for more than a few hours).
It se
Wouldn't using Table = off do everything you need, without touching the
routing.
Cheers.
On 8/30/2020 1:56 AM, Aaron Bolton wrote:
Yes, this does thanks
I plan on using Quagga for BGP over WireGuard tunnels so I guess I
need to avoid wg-quick if that makes changes to the routing table and
fir
On 4/15/2020 2:39 PM, Jason A. Donenfeld wrote:
This is because ELRepo is a crumbling mess held together by bubble gum
and scotch tape. Run this:
$ sudo yum install yum-plugins-elrepo
And then try again.
Much better this time, updated successfully. Thanks.
Cheers.
On 4/15/2020 2:41 PM, Jason A. Donenfeld wrote:
It turns out that ELRepo is a bit of a crumbling mess, unfortunately.
FOR CENTOS USERS ONLY, the instructions in the previous email need to
include:
$ sudo yum install yum-plugins-elrepo
Hopefully Red Hat will simply include WireGuard in RHEL 7 an
Hi,
I'm running a Nethserver box, which is built on top of CentOS 7. Trying
to update to the latest wireguard throws the following:
Resolving Dependencies
--> Running transaction check
---> Package kmod-wireguard.x86_64 0:1.0.20200401-1.el7_7.elrepo will be
updated
---> Package kmod-wireguard
On 1/3/2020 9:14 AM, Jason A. Donenfeld wrote:
On Fri, Jan 3, 2020 at 5:43 PM Alvin Darkness wrote:
Unfortunately as slackware 14.2 is a (quite old now) stable release there isnt
much we can do about getting nft past 0.6. A good portion of us slackware
users have moved onto slackware -curren
Let me see if I can install 0.7 without too many dependencies creeping
in. I tried the latest Slackware current build of 0.9, but the
dependencies were getting out of hand.
Cheers.
On 1/3/2020 8:07 AM, Jason A. Donenfeld wrote:
I took a closer look. Indeed the issue is that nft 0.6 is too o
Agreed, way too ugly. :-) Don't do it for me.
Cheers.
On 1/3/2020 8:22 AM, Jason A. Donenfeld wrote:
We could do something like this:
https://git.zx2c4.com/wireguard-tools/commit/?h=jd/nft-version-detection
But that seems pretty ugly and I think I'd rather not.
_
I don't use those packages for wireguard. I build my own from source.
But yes, the rest of Slack seems to be stuck in a time-warp.
Cheers.
On 1/2/2020 12:10 PM, Jason A. Donenfeld wrote:
On 1/2/20 6:25 AM, Eddie wrote:
> First time running wireguard as a native client on my Slackw
so that wg-quick wouldn't find it, which allowed the connection
to be made.
Now all I need do is work out why the handshakes between client and
server are working, but traffic doesn't flow.
Cheers.
On 1/2/2020 12:04 AM, Eddie wrote:
Not sure if this helps, or not. But this is the
ip wg-quick-wg0 postmangle meta l4proto udp mark 51820 ct mark
set mark
add rule ip wg-quick-wg0 premangle meta l4proto udp meta mark set ct mark
'
/dev/fd/63:5:76-80: Error: syntax error, unexpected saddr
^
Cheers.
On 1/1/2020 11:34 PM, Eddie wrote:
Ha. Even older:
root@The-Tardi
eers.
On 1/1/2020 10:22 PM, Edward Vielmetti wrote:
Eddie - what version of nftables does Slackware come with? The output
of `nft -v` should be helpful.
There is a report from stackexchange that nftables at 0.7 gives this
error, but at 0.8.1 or better it's OK. I was not easily able to v
First time running wireguard as a native client on my Slackware 14.2
system throws this:
root@The-Tardis:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.150.14/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 5
On 10/14/2019 2:53 PM, Eddie wrote:
Title says it all. I'm still unable to connect to my home CentOS
server from my iPhone. A check of the IP shows I'm still routed via
AT&T.
On the server, wg shows no connectivity from the client at all and if
I temporarily block the port
Title says it all. I'm still unable to connect to my home CentOS server
from my iPhone. A check of the IP shows I'm still routed via AT&T.
On the server, wg shows no connectivity from the client at all and if I
temporarily block the port in my firewall it doesn't show any attempt to
connect.
I'll just repeat verbatim the response I got from Silvan (thank you)
when I reported the same issue previously:
The main problem is that the current standard kernel of CentOS simple
does not support the handling of "suppress_prefixlength".
Iproute2 supports it since it does not return any error
x27;t show any connected client for the assigned IP.
I've attached the logs from the iPhone.
I also connect to the server from an Android tablet, and that works
correctly.
Cheers,
Eddie
2019-01-10 13:10:38.818184: [APP] App version: 0.0.20190107 (1); Go backend
version: 0.0.2
nager?
-jugs
‐‐‐ Original Message ‐‐‐
On July 10, 2018 10:20 PM, Eddie wrote:
Not sure if this is intended behaviour, or not.
Every time I start an interface using wg-quick with the SaveConfig =
true it reloads all the previous, saved, IPv6 link-local addresses plus
generates a n
Not sure if this is intended behaviour, or not.
Every time I start an interface using wg-quick with the SaveConfig =
true it reloads all the previous, saved, IPv6 link-local addresses plus
generates a new one. So the first time the interface is started there
is 1 link-local address. The next
Hi,
I just updated both a RHEL and a CentOS system from 7 -> 7.5. Following
this, when running wg-quick, the routing tables are not updated
correctly. Both systems are running iproute.x86_64-4.11.0-14.el7, but
from different repositories and are definitely different builds as they
install to
As pointed out by Jason on 5/13, the snapshots after 21080420 no longer
support CentOS 7.4
Where can I download a copy of those, as the repository only appears to
hold the latest and minus one.
Cheers.
___
WireGuard mailing list
WireGuard@lists.zx2
Isn't that a little premature to drop support for CentOS 7.4. 7.5 was
only officially released 3 days ago.
Cheers.
On 5/13/2018 2:29 PM, Jason A. Donenfeld wrote:
We only support the most recent RHEL, which means 7.5, not 7.4. The
last snapshot supporting 7.4 is 0.0.20180420. To use future s
What is the correct procedure for updating WG with a new snapshot.
I'm currently running CentOS 7.4 and previously had installed the
20180420 snapshot. Today, I tried to update with the new 20180513 one,
and it appears to be failing. The command I used was: yum update
--disablerepo=* --enab
I didn't think that AllowedIPs would filter traffic like that. But
could be wrong. :-)
Here's my take on your problem:
Add "Table = off" and "FwMark = 1234 (or other value)" to the wg config,
which will stop the routing tables being updated and add the routing
mark to all encrypted packets.
Jason,
Gottcha. Thank you for the explanation.
Cheers.
On 4/26/2018 6:04 AM, Jason A. Donenfeld wrote:
Hello Eddie,
Precisely what's happening here is that your device has various TCP
connections that are open _before_ you turn on the VPN. Then you turn
on the VPN, and now those prio
Yes. All the internal Windows machines are pingable from my server, all
other machines in the internal network. Just not from a client
connected via wireguard.
Cheers.
On 4/25/2018 10:03 PM, Kalin KOZHUHAROV wrote:
On Thu, Apr 26, 2018 at 1:06 AM, Eddie wrote:
They are pingable from the
Another minor issue I've noticed in my tests.
I've configured wireguard to connect remotely to my home server, like a
roadwarrior set-up, from both an Android tablet and also a Linux laptop
connected to a mobile hot-spot. Everything appears to work, except for
one thing.
I can't ping the 2
source IP wouldn't match the allowed-ip.
Cheers.
On 4/25/2018 2:18 PM, Jason A. Donenfeld wrote:
Hi Eddie,
Those RX frame errors are caused by the interface receiving packets
that have a source IP not included in the allowed-ips list of the
peer.
https://git.zx2c4.com/WireGuard/tree/src
Only found out about this project a few days ago and have been trying it
out. Looks killer.
Noticed that connecting from the Android app (0.4.0), yeah I know it's
only Alpha level, the wg0 interface on the Linux side (0.0.20180420)
reports RX errors:
wg0: flags=209 mtu 1420
inet 19
36 matches
Mail list logo
