1. When we connect TLS or DTLS socket, measure the MTU for that socket,
using getsockopt TCP_INFO (TCP_MAXSEG as fallback), or IP_MTU.
2. Use TLS library functions to calculate the 'data MTU' for the largest
payload that can fit in a single wire packet.
(XX: Despite the name, gnutls_dtls_get_data_mtu *appears* to work for either TLS or DTLS.
XX: Need implementation for OpenSSL with TLS.)
3. Use the 'data MTU' to calculate the tunneled MTU for PPP.
TODO:
- Extend this approach to be used for GPST, oNCP, CSTP and Cisco DTLS.
- Extend it to be used for GP/Juniper/Pulse ESP (where calculate_mtu will
still be needed, because libraries won't do it for us).
Signed-off-by: Daniel Lenski <email address hidden>
Accept server's MRU (or --mtu override) as our MTU for PPP
This is meant as a temporary workaround until we rework our MTU
calculations and probing.
For now, we will just accept the PPP server's MRU as our MTU,
and when using DTLS, assume that our on-the-wire/link-layer MTU is
the standard Ethernet II frame size of 1500 bytes.
Signed-off-by: Daniel Lenski <email address hidden>
HDLC-like framing (RFC1662) means that tunneled packets may double in size as part of
their on-the-wire encapsulation, while efficient datagram transport requires calculation
of a predictable maximum transfer unit.
We hope no servers expect us to combine them.
Per dwmw2, we should refuse to do DTLS if HDLC is required.
Signed-off-by: Daniel Lenski <email address hidden>
In rebasing and cleaning up, I appear to have screwed up the PPP reconnect
state machine. The UDP mainloop runs first, starts a connection, which
is immediately torn down by the TCP mainloop because of the stale PPP
state from the previous connection.
Fix it by resetting the PPP state when attempting the DTLS reconnection
after a pause (which we determine by observing that the state isn't
PPPS_DEAD but the ssl_fd isn't actually connected).
The Fortinet UDP mainloop wants the same trick. And I want to consolidate
the two anyway.
[DL copied to Fortinet UDP mainloop.]
Signed-off-by: David Woodhouse <email address hidden>
Signed-off-by: Daniel Lenski <email address hidden>
This buffer is used to initiate the connection over either TLS or DTLS.
Cookies are not needed for it to succeed, and can potentially grow without bound,
which would make it too big to fit in a single DTLS packet (ick, HTTP over DTLS).
Therefore we exclude them.
Don't blame me. I didn't design this.
Signed-off-by: Daniel Lenski <email address hidden>
This is almost exactly a copy of the F5 DTLS support added in dcabb8738090ea2646864b740c805e70b58b71f8. Key differences:
- For Fortinet, vpninfo->ppp_dtls_connect_req differs from
vpninfo->ppp_tls_connect_req. For F5 they are identical.
- For Fortinet, the DTLS/UDP port always matches the TLS/TCP port.
For F5 they can differ.
Signed-off-by: Daniel Lenski <email address hidden>
