[Openvpn-devel] [PATCH applied] Re: Implement block-ipv6

[Gert Doering]

Acked-by: Gert Doering 

Stared at the code (long and hard, especially the changes to udp_checksum()
- which is a welcome generalization).  Looks all reasonable.  One of the
changes was uncrustify wrapping the call to process_ip_header() - which
looked ugly before, and looks ugly afterwards, but that's not your fault.

What I like quite a lot is that this patch does not auto-add an IPv6 
default route - it looked like a "why, we could do this automatically?"
initially, but is coming handy if you want more selective blocking.

Tested with tun on linux, and tap on FreeBSD.  Works nicely (*).

Stared at the synthesized ICMPv6 packet with tcpdump and wireshark, and
both tools tell me "the packet is good" ;-)

I have test compiled for Windows (mingw).  Builds fine.  Have not 
actually run the resulting binary, but given that the changes are 
fully platform independent, I expect no issues here.


Server mode --block-ipv6 doesn't work correctly for me, though  (but I've 
decided to move this towards a separate patch as it isn't blocking client 
side functionality and not breaking "normal" operation).

I run a "standard tun server" on linux, with --server, and --block-ipv6.

The server assigns a v6 address to the client, the client sends a packet
into the tunnel:

21:15:47.179356 IP6 2001:608:3:814::1000 > 2001:608::2: ICMP6, echo request, 
seq 1, length 64

.. and I can see it come out of the server's tun interface towards linux:

21:15:47.192493 IP6 2001:608:3:814::1000 > 2001:608::2: ICMP6, echo request, 
seq 1, length 64

.. the target hosts answers, and the answer is routed into the server's
tun interface:

21:15:47.192993 IP6 2001:608::2 > 2001:608:3:814::1000: ICMP6, echo reply, seq 
1, length 64

.. and then the server tells the remote IPv6 host that "no, my client is
not there"

21:15:47.193030 IP6 2001:608:3:814::2 > 2001:608::2: ICMP6, destination 
unreachable, unreachable route 2001:608:3:814::1000, length 112

.. but no ICMPv6 packet is ever sent towards the client.  Looks like the
multi.c code is somewhat confused about directions...  without block-ipv6
on the server, things work normally...

21:20:28.961067 IP6 2001:608:3:814::1000 > 2001:608::2: ICMP6, echo request, 
seq 1, length 64
21:20:28.961568 IP6 2001:608::2 > 2001:608:3:814::1000: ICMP6, echo reply, seq 
1, length 64
21:20:29.963421 IP6 2001:608:3:814::1000 > 2001:608::2: ICMP6, echo request, 
seq 2, length 64
21:20:29.963933 IP6 2001:608::2 > 2001:608:3:814::1000: ICMP6, echo reply, seq 
2, length 64



Tap mode might need a bit of tweaking as well - it does work, but it
blocks ND packets, instead of "user payload" (TCP SYN)...

21:22:23.923360 IP6 fd00:abcd:194:4::1007 > ff02::1:ff00:1: ICMP6, neighbor 
solicitation, who has fd00:abcd:194:4::1, length 32
21:22:23.923375 IP6 fd00:abcd:194:4::1 > fd00:abcd:194:4::1007: ICMP6, 
destination unreachable, unreachable route ff02::1:ff00:1, length 80

.. so you do not get back a "fast fail" on the payload, but it fails 
after ND timeout...

traceroute6 to fd00:abcd:194:4::1 (fd00:abcd:194:4::1) from 
fd00:abcd:194:4::1007, 64 hops max, 12 byte packets
 1  fd00:abcd:194:4::1007 (fd00:abcd:194:4::1007)  3058.434 ms !A  3038.031 ms 
!A  3055.928 ms !A

.. so while it works, it's not as nice as it could be - maybe we should
multicast packets (destination ff02::) just pass through in tap mode, so
a ND relationship with the remote can be established?  If I install a
manual ND entry, I get the proper "quick fail from the right source":

21:27:38.686757 IP6 fd00:abcd:194:4::1007.29319 > fd00:abcd:194:4::1.33437: 
UDP, length 12
21:27:38.686765 IP6 fd00:abcd:194:4::1 > fd00:abcd:194:4::1007: ICMP6, 
destination unreachable, unreachable route fd00:abcd:194:4::1, length 68

traceroute6 to fd00:abcd:194:4::1 (fd00:abcd:194:4::1) from 
fd00:abcd:194:4::1007, 64 hops max, 12 byte packets
 1  fd00:abcd:194:4::1 (fd00:abcd:194:4::1)  0.113 ms !N  0.072 ms !N  0.057 ms 
!N

$ telnet fd00:abcd:194:4::1 22
Trying fd00:abcd:194:4::1...
telnet: connect to address fd00:abcd:194:4::1: No route to host
telnet: Unable to connect to remote host


Anyway.  Room for improvement :-)

Your patch has been applied to the master branch.

commit e11d2d14a9ef5311f791a9a614ab367c6f50ff11 (master)
Author: Arne Schwabe
Date:   Mon Dec 3 17:48:18 2018 +0100

 Implement block-ipv6

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20181203164818.15756-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17977.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Add tls-crypt-v2 to the list of supported inline options

[Gert Doering]

Your patch has been applied to the master branch.

commit 584b1717e7eaa8e44c675efb1f2dcbbaed2c0db3
Author: Arne Schwabe
Date:   Tue Dec 4 17:05:02 2018 +0100

 Add tls-crypt-v2 to the list of supported inline options

 Signed-off-by: Arne Schwabe 
 Acked-by: Steffan Karger 
 Message-Id: <20181204160502.1089-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17980.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add tls-crypt-v2 to the list of supported inline options

[Steffan Karger]

On 04-12-18 17:05, Arne Schwabe wrote:
> Signed-off-by: Arne Schwabe 
> ---
>  doc/openvpn.8 | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index eae2bd94..9d1a3fa6 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -6921,9 +6921,10 @@ X509_1_C=KG
>  .SH INLINE FILE SUPPORT
>  OpenVPN allows including files in the main configuration for the
>  .B \-\-ca, \-\-cert, \-\-dh, \-\-extra\-certs, \-\-key, \-\-pkcs12, 
> \-\-secret,
> -.B \-\-crl\-verify, \-\-http\-proxy\-user\-pass, \-\-tls\-auth
> +.B \-\-crl\-verify, \-\-http\-proxy\-user\-pass, \-\-tls\-auth,
> +.B \-\-tls\-crypt,
>  and
> -.B \-\-tls\-crypt
> +.B \-\-tls\-crypt-v2
>  options.
>  
>  Each inline file started by the line
> 

Absolutely correct.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Add tls-crypt-v2 to the list of supported inline options

[Arne Schwabe]

Signed-off-by: Arne Schwabe 
---
 doc/openvpn.8 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index eae2bd94..9d1a3fa6 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -6921,9 +6921,10 @@ X509_1_C=KG
 .SH INLINE FILE SUPPORT
 OpenVPN allows including files in the main configuration for the
 .B \-\-ca, \-\-cert, \-\-dh, \-\-extra\-certs, \-\-key, \-\-pkcs12, \-\-secret,
-.B \-\-crl\-verify, \-\-http\-proxy\-user\-pass, \-\-tls\-auth
+.B \-\-crl\-verify, \-\-http\-proxy\-user\-pass, \-\-tls\-auth,
+.B \-\-tls\-crypt,
 and
-.B \-\-tls\-crypt
+.B \-\-tls\-crypt-v2
 options.
 
 Each inline file started by the line
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (Wed, 28th Nov 2018)

[Jan Just Keijser]

Hi Lev,

On 29/11/18 16:18, Lev Stipakov wrote:


Some background information.

In openvpn3 we decided not to implement fragments, because:

 - this is quite a big feature which has to be supported through the 
whole stack (client, server, kernel module)

 - we assume that it is not used by most of users

However, for those who needs --fragment, we'll implement:

 - mssfix support, this should solve problems with tcp-based protocols
 - sending icmp "packet too big" for other protocols, we assume that 
they'll respect icmp response


I'd thoroughly test this with protocols like Google's QUIC, which uses 
UDP underneath. How does it respond to such ICMP messages? what does it 
do to throughput?




--fragment is/was very useful on a system where you do not /
cannot change the tun MTU size. Up to Windows XP, this was not
possible without rebooting the OS. Since Vista, it *is* possible
to change the MTU of an adapter on the fly (as explained in my
trusty old cookbook, of course ;))


As James wrote a while ago (13 years ago :)

https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html

> A lot of experience gained during the OpenVPN 1.x releases showed 
that it's best to fix the tunnel MTU at
> 1500 and vary the other parameters (and use --mssfix to prevent 
fragmentation rather than a lower tunnel MTU).
Don't know if still holds. Assuming that we can change tun-mtu on any 
supported platforms, do you think that it is better

to do _that_, rather than have mssfix/icmp ptb workaround?

With that, it would be possible to fix the link-mtu to 1500 (or
whatever is set on the outbound interface) and then subtract the
header size to get a meaningful tun-mtu size.


Do you think 1500 is a safe value? Arne just mentioned today that his 
network interface MTU is 1500 and router's MTU is 1492 due to PPPoE, 
and openvpn2 works because it assumes that mtu is 1450.


I am not sure what a good default value is - it all depends on the 
intermittent networks. What OpenVPN needs is the ability to send a 
single UDP packet containing encapsulated data, knowing that that same 
single UDP packet arrives at the destination. How the underlying 
protocols/networks achieve this, is unknown.


Also, all of this applies only to UDP mode - in TCP mode it is best to 
not fragment at all - simply let the TCP stream take care of the 
encapsulated data, possible with TCP_NODELAY set.



Having said all that, I do have one gripe with the way the link or
tun mtu is calculated in the current codebase:
In the 2.3 code base, the server tun mtu size was equal to the
client tun-mtu size.
In the 2.4+ code base, the server-side tun mtu size is set to some
ridiculous low level (with link-mtu 1500 set) in order to
accomocate all possible encryption ciphers - *even if I add
ncp-disable* . To me, that does not make a whole lot of sense. If I
add '--ncp-disable' I'd expect the client and the server to behave
pretty much like an OpenVPN 2.3 client (with a possible 3
bytes difference to accomodate for the peer id).


With 2.4 codebase I noticed that what man page says is not what 
openvpn2 code does - it does include transport overhead, while

man page says it doesn't (copying my mail here):

              Announce to TCP sessions running over the tunnel that 
they should limit their send packet sizes such that after OpenVPN has 
encapsulated them, the resulting UDP packet size that OpenVPN sends to 
its peer will not exceed max bytes. The  default  value is 1450.


              The max parameter is interpreted in the same way as the 
--link-mtu parameter, i.e. the UDP packet size after encapsulation 
overhead has been added in, but not including the UDP header itself. 
Resulting packet would be at most 28 bytes larger for IPv4 and 48 
bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header).


So it means that with "mssfix" 1300 resulting IPv4 packet size would 
be at most 1328.


This is what I see in Wireshark (server - git master, client 2.4.6):

Internet Protocol Version 4, Src: 128.199.xxx.yyy, Dst: 10.0.200.20
    0100  = Version: 4
     0101 = Header Length: 20 bytes (5)
    Total Length: 1300
    Protocol: UDP (17)
User Datagram Protocol, Src Port: 1194, Dst Port: 1194
    Source Port: 1194
    Destination Port: 1194
    Length: 1280
OpenVPN Protocol
    Type: 0x49 [opcode/key_id]
    Peer ID: 0
    Data (1268 bytes)

While man page statement is technically correct - UDP packet size is 
1300, which is "at most 1328", I think it should say:


> the resulting IP packet size that OpenVPN sends to its peer will not 
exceed max bytes


and

> The max parameter is interpreted in the same way as the --link-mtu 
parameter, i.e. the IP packet size
after encapsulation overhead has been added in, including UDP and IP 
headers.


you seem to be talking about the mssfix size, wheras I am talking about 
the tun-mtu size. When you add

  link-mtu 1500
  ncp-di

[Openvpn-devel] Topics for the community meeting (Wed, 5th Dec 2018)

[Samuli Seppänen]

Hi,

We're going to have an IRC meeting starting at 11:30 CET
(10:30 UTC) on #openvpn-meeting  irc.freenode.net. You do not have
to be logged in to Freenode to join the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments
on the topics by responding to this email or to the summary email sent
after the meeting. Whenever possible, we'll also respond to existing,
related email threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock















signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel