Unknown DTLS packets

[Chaskiel Grundman]

It's possible that this is related to the issue I reported in january
(http://lists.infradead.org/pipermail/openconnect-devel/2018-January/004647.html),
which involves a bug in gnutls. The bug has been fixed upstream, but
debian stable and ubuntu have not taken new versions of gnutls 3.5 or
3.6 since that time.

openconnect could hack around this by adjusting the values passed to
gnutls_set_data_mtu upward until gnutls_get_data_mtu returns a value
that is at least what was requested by the gateway in X-DTLS-MTU

On Thu, Apr 12, 2018 at 11:40 PM, Daniel Lenski <dlenski at gmail.com> wrote:
> On Thu, Apr 12, 2018 at 8:18 PM, Charles Wise <ctwise at gmail.com> wrote:
>> Looks like it's the MTU. I did the -vvvv and --dump and the output
>> said the MTU should be 1322 (DTLS option X-DTLS-MTU : 1322). When I
>> enable DTLS and _don't_ set the MTU, I run iperf3 and the traffic
>> drops to zero almost immediately. When I set it explicitly (-m 1322)
>> the traffic goes through (plus it's much faster then with --no-dtls).
>
> I'm glad it works, but I'm still confused.
>
> 1. If the server says the MTU should be 1322 (via the "X-DTLS-MTU"
> header), then openconnect (via the vpnc-script) is setting the MTU of
> the interface to 1322.
> 2. If you specify `-m 1322` explicitly, openconnect (via the
> vpnc-script) is also setting the MTU of the interface to 1322.
>
> What is happening differently when you specify the MTU explicitly?
> What do the operating system configuration utilities say that the MTU
> of the tunnel device is in (1) vs (2)?
>
> Dan
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel