FWIW, all those ports (4500, 1500, 500) seem to work for me with iOS 13 and
WireGuard for iOS build 0.0.20190610 (13).
On Wed, Sep 25, 2019 at 6:03 PM John huttley
wrote:
> Hi,
>
> Port 4500 is the IPSec UDP nat port and 500 is IKE.
>
> Anyconnect uses ISPEC so I think those ports are simply in
Hi,
Port 4500 is the IPSec UDP nat port and 500 is IKE.
Anyconnect uses ISPEC so I think those ports are simply in use.
--John
On 24/09/19 9:36 PM, wiregu...@p-np.de wrote:
Hello,
in place upgrades from iOS 12 -> iOS 13 (release) seem to work well in
general. But there is a bizarre issue
I have no control over that script, but I think having a compiler in place
when building stuff is such a reasonable pre-requisite so that the script
would not have to look for it.
Den ons 25 sep. 2019 kl 16:23 skrev Ulrich Kalloch :
> Am 25.09.19 um 13:01 schrieb Janne Johansson:
> > Den ons 25
Am 25.09.19 um 13:01 schrieb Janne Johansson:
> Den ons 25 sep. 2019 kl 10:52 skrev Ulrich Kalloch :
>
if you have installed firmware remove it if possible.
>>> The install Process check that /usr/include/machine is empty.
then check that the directory /usr/include/machine is empty.
>>> I
Den ons 25 sep. 2019 kl 10:52 skrev Ulrich Kalloch :
> >> if you have installed firmware remove it if possible.
> > The install Process check that /usr/include/machine is empty.
> >> then check that the directory /usr/include/machine is empty.
> > If not clean it.
> > I think this part is way off
Hi Dave,
On Wed, Sep 25, 2019 at 12:03 PM David Miller wrote:
> I didn't say "must" anything, I suggested this as a more smoothe
> and efficient way forward.
s/must/should/g? However it's characterized, I think your jugements
and opinions are generally sound, and I intend to put them into
action
From: Bruno Wolff III
Date: Wed, 25 Sep 2019 04:17:00 -0500
> Are there going to be two branches, one for using the current API and
> one using Zinc?
This is inapproprate to even discuss at this point.
Let's see what the crypto based stuff looks like, evaluate it,
and then decide how to proceed
From: "Jason A. Donenfeld"
Date: Wed, 25 Sep 2019 10:29:45 +0200
> His viewpoint has recently solidified: in order to go upstream,
> WireGuard must port to the existing crypto API, and handle the Zinc
> project separately.
I didn't say "must" anything, I suggested this as a more smoothe
and effi
Are there going to be two branches, one for using the current API and one
using Zinc?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
On Wed, Sep 25, 2019 at 11:06:18AM +1000, Brassy Panache wrote:
> I have a kernel without IPv6 support. I've noticed when running:
>
> $ wg-quick down vpn
>
>
> I receive the following errors:
>
> [#] ip -4 rule delete table 51820
> [#] ip -4 rule delete table main suppress_prefixlength 0
> RT
Am 25.09.19 um 07:47 schrieb Janne Johansson:
> Den tis 24 sep. 2019 kl 11:00 skrev Ulrich Kalloch :
>
>> Hello @ all
>> if you have installed firmware remove it if possible.
> The install Process check that /usr/include/machine is empty.
>> then check that the directory /usr/include/machine is emp
Hello,
in place upgrades from iOS 12 -> iOS 13 (release) seem to work well in general.
But there is a bizarre issue depending on remote endpoint ports. If you have,
in my case, 4500/UDP configured as remote endpoint the tunnel does not send or
receive traffic. Changing it to any other port work
(Apologies in advance if this email gets orphaned. I don't understand how
mailing lists work.)
What I can see is that wireguard uses the default route interface as it's
source IP for any outgoing packets. This means that if you receive a
connection request from eth1, if the default route is eth0 i
Hi Eddie,
Thanks for the response, I figured is was something with either the kernel or
iproute and I guess either the kernel does not support it or the iproute2
version does not "completely support it" or has a bug.
On your note about updating the kernel, the funny thing is initially I tried
t
I have a kernel without IPv6 support. I've noticed when running:
$ wg-quick down vpn
I receive the following errors:
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
RTNETLINK answers: Address family not supported by protocol
Dump terminated
RTNETLINK
Thank you Jason! This makes more sense as the issue did not appear
until the system reboot which would be consistent with the kernel not
WireGuard upgrade. Much appreciate your response.
Sent from my iPhone
> On Sep 24, 2019, at 04:47, Jason A. Donenfeld wrote:
>
> Hi folks,
>
> FYI, upstream Li
"Jason A. Donenfeld" writes:
> Hi folks,
>
> I'm at the Kernel Recipes conference now and got a chance to talk with
> DaveM a bit about WireGuard upstreaming. His viewpoint has recently
> solidified: in order to go upstream, WireGuard must port to the
> existing crypto API, and handle the Zinc pr
Hi folks,
I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream
18 matches
Mail list logo
