Hi
On Tue, Jun 5, 2018 at 10:30 PM, Antonio Quartulli wrote:
> Hi,
>
> On 06/06/18 03:38, Selva Nair wrote:
>> Here is the diff of what I did for the Windows build run:
>>
>> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
>> index 2e33880..75336a9 100644
>> --- a/src/openvpn/tun.c
>> +++
Hi,
On 06/06/18 03:38, Selva Nair wrote:
> Here is the diff of what I did for the Windows build run:
>
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 2e33880..75336a9 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -5824,9 +5824,9 @@ open_tun(const char *dev, const
Hi,
On 06/06/18 03:59, Gert Doering wrote:
[cut]
>> Here is the diff of what I did for the Windows build run:
>>
>> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
>> index 2e33880..75336a9 100644
>> --- a/src/openvpn/tun.c
>> +++ b/src/openvpn/tun.c
>> @@ -5824,9 +5824,9 @@ open_tun(const
Hi,
We are developing a custom client for OpenVPN 2.4.x and it would be nice to
have some support from experienced community developers.
Is there anybody here available to help us with a consultancy regarding to
network protocols and its required state machines?
Thank you,
Best Regards.
--
On 04/17/2018 06:50 PM, Jason A. Donenfeld wrote:
>* Allow specifying 'none' to the --ca parameter, to specify that
> certificates should not be checked against a CA. Note that 'none'
> is already used in other similar options as a special placeholder.
>
>* When '--ca none' is
Hi,
On Tue, Jun 5, 2018 at 3:59 PM, Gert Doering wrote:
> Hi,
>
> On Tue, Jun 05, 2018 at 03:38:44PM -0400, Selva Nair wrote:
>> FWIW, I did a quick test --- looking into tap-windows sources it seems
>> the address is used only for ARP so passing some random address to the
>> ioctl looks ok (?).
From: Selva Nair
M_DEBUG only indicates the type of the message and will print even
at verb 0. Use D_LOW which is M_DEBUG combined with verb = 4 and
a mute level.
---
Moving towards what the man page says:
verb 0 means "No output except fatal errors."
M_WARN also needs replacement but that
Hi,
On Tue, Jun 05, 2018 at 03:38:44PM -0400, Selva Nair wrote:
> FWIW, I did a quick test --- looking into tap-windows sources it seems
> the address is used only for ARP so passing some random address to the
> ioctl looks ok (?).
Not sure about that. For ARP spoofing, it should use the
Hi,
On Tue, Jun 5, 2018 at 2:53 PM, Gert Doering wrote:
> Hi,
>
> On Tue, Jun 05, 2018 at 01:30:35PM -0400, Selva Nair wrote:
>> How to work around that depends on what the tap driver expects in the
>> v4 address. Ideally, we should patch the driver to work without a V4
>> address...
>
>
Acked-by: Gert Doering
While not strictly necessary, it makes the code somewhat easier to
follow ("this is only about IPv4, which does not interest me right now").
Stared-at-code, and tested (t_client + t_server) :-)
Your patch has been applied to the master branch (with some minor grammar
Hi,
On Tue, Jun 05, 2018 at 01:30:35PM -0400, Selva Nair wrote:
> How to work around that depends on what the tap driver expects in the
> v4 address. Ideally, we should patch the driver to work without a V4
> address...
Samuli's build/test rig seems to be close to finished, so now is the
time to
Hi,
On Wed, Jun 06, 2018 at 12:22:31AM +0800, Antonio Quartulli wrote:
> Why is it !ipv6 by default in the first place?
>
> I'd rather keep default behaviours as they are now, to avoid messing up
> the user experience.
>
> However, I also understand that if there is no IPv4 and gateway-redirect
Hi,
On Wed, Jun 06, 2018 at 12:11:40AM +0800, Antonio Quartulli wrote:
> > Without having done much review here, just one initial caveat: did you
> > test this with --ifconfig-pool-persist? What happens?
>
> It should just be ignored.
> At the moment pool-persist works only for IPv4 and there
Hi,
On Tue, Jun 05, 2018 at 10:23:29AM -0500, Derek Zimmer wrote:
> OpenVPN in UDP mode is still operating a TCP windowing layer
> somewhere, right?
Not for data packets - they get sent off as they come in from the
tun file descriptor and vice versa. No pacing (unless configured),
no
Hi,
On Tue, Jun 5, 2018 at 12:22 PM, Antonio Quartulli wrote:
> Hi,
>
> On 05/06/18 23:54, Selva Nair wrote:
> [cut]
>>> ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
>>>
>>> First, I'd leave off the bits about "this can be useful" of the commit
>>> message - because
Hi,
On 05/06/18 23:54, Selva Nair wrote:
[cut]
>> ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
>>
>> First, I'd leave off the bits about "this can be useful" of the commit
>> message - because that's not the point of this patch, you can *ignore*
>> the settings already
Hi,
On 05/06/18 22:51, Gert Doering wrote:
> HI,
>
> On Tue, Jun 05, 2018 at 05:36:28PM +0800, Antonio Quartulli wrote:
>> From: Antonio Quartulli
>>
>> With this change a server is allowed to allocate an
>> IPv6-only pool. This is required to make it capable
>> of managing an IPv6-only tunnel.
Hi,
On Tue, Jun 5, 2018 at 10:36 AM, Gert Doering wrote:
>
> Hi,
>
> Prelimiaries: I think this whole series should only go to 2.5, as it
> has the potential to be fairly intrusive and uncover hidden bugs - I've
> discussed this with Antonio already (and we're in agreement) but for
> the sake of
JJK, this is actually quite helpful data, as I saw similar results when
doing my internal testing. The falloff rate seems to increase as the
latency increases, suggesting a fixed window or at least one that isn't
scaling properly as latency increases, which causes unusually fast
performance drops
HI,
On Tue, Jun 05, 2018 at 05:36:28PM +0800, Antonio Quartulli wrote:
> From: Antonio Quartulli
>
> With this change a server is allowed to allocate an
> IPv6-only pool. This is required to make it capable
> of managing an IPv6-only tunnel.
Without having done much review here, just one
Hi,
Prelimiaries: I think this whole series should only go to 2.5, as it
has the potential to be fairly intrusive and uncover hidden bugs - I've
discussed this with Antonio already (and we're in agreement) but for
the sake of the list.
On Tue, Jun 05, 2018 at 05:04:17PM +0800, Antonio Quartulli
Sorry, that should be:
server Ubuntu 18.04
client arch linux
but the resulting vpn is ipv6 only and works well.
On 05/06/18 13:05, tincanteksup wrote:
Hi,
I have applied these 5 patches to master on ubuntu 18.04LTS
The resulting binary gave server+client ipv6 *only* tunnel
over ipv4 network.
Following up on myself
On 05/06/18 14:25, Jan Just Keijser wrote:
On 01/06/18 02:50, Derek Zimmer wrote:
I'm still working on this, as I think it is worthwhile for us to
explore and get some hard data on how all of these things perform in
a real world environment.
I've been stalled by
Hi,
On 01/06/18 02:50, Derek Zimmer wrote:
I'm still working on this, as I think it is worthwhile for us to
explore and get some hard data on how all of these things perform in a
real world environment.
I've been stalled by transitioning to a new job.
>Same here. I guess this interacts with
From: Antonio Quartulli
With this change a server is allowed to allocate an
IPv6-only pool. This is required to make it capable
of managing an IPv6-only tunnel.
Trac: #208
Cc: Gert Doering
Signed-off-by: Antonio Quartulli
---
v2:
- fix syntax error by adding missing ')'
src/openvpn/multi.c
From: Antonio Quartulli
This change ensures that an interface is properly brought
up even when only IPv6 settings are configured.
This can be useful on a client that wants to ignore the IPv4
settings pushed by the server and configure only IPv6.
To achieve the above, a client can use
This patchset allows clients and servers to work with a
tunnel configured with IPv6 only.
Patches 2 and 3 are mere cosmetic changes and could be merged
regardless of the rest (note that 3 depends on 2).
With this change a server can be configured by using only the
'--server-ipv6' directive.
This
From: Antonio Quartulli
(This is only code refactoring)
IPv4 and IPv6 members are all part of the same flat hierarchy
in the pool data structure, without a proper name convention.
Create 2 sub-structures to properly saperate IPv4 from IPv6
relate members. This should make the structure more
From: Antonio Quartulli
Due to the current logic it is not possible for a server
to create an IPv6-only tunnel, because OpenVPN mandates
the existance of an IPv4 configuration (even if fake).
This change relaxes this constraint and allows servers to
bring up tunnels without any IPv4 setting at
In preparation to having tls-auth/crypt keys per connection
block, it is important to ensure that such material is always
reloaded upon SIGUSR1, no matter if `persist-key` was specified
or not.
This is required because when moving from one remote to the
other the key may change and thus the key
Different VPN servers may use different tls-auth/crypt keys.
For this reason it is convenient to make tls-auth/crypt
per-connection-block options so that the user is allowed to
specify one key per remote.
If no tls-auth/crypt option is specified in a given connection
block, the global settings,
Hi,
On 05/06/18 11:29, Antonio Quartulli wrote:
> In preparation to having tls-auth/crypt keys per connection
> block, it is important to ensure that such material is always
> reload upon SIGUSR1, no matter is persist-key was specified or
> not.
>
> This is required because when moving from one
32 matches
Mail list logo
