fastd v17

New features

  • Per-peer-group method specification

    It is now possible to override the supported crypto methods per peer group.

  • Connection reset via SIGUSR2

    Sending a SIGUSR2 to the fastd process will reset all connections.

  • Support for Android 4.1+

    Contributed by Rick Lei. See doc/README-Android.md.

  • Faster handshake

    fastd’s handshake should now take significantly less time (about 30-50%, not regarding the network latency). Due tue this change fastd depends on libuecc v5 (which is released together with fastd v17) now.

Bugfixes

  • Removed broken pmtu option

    The pmtu option was changed into a no-op (and fastd’s behaviour was changed to what was pmtu no before) as fastd didn’t handle a potentially discovered smaller path MTU correctly. It will probably return in a future version of fastd.

  • Improve handling of incoming packets from many peers after restarting fastd

    fastd will generate only one handshake per peer every 15 seconds now instead of one handshake per incoming packet.

  • Added a missing security check during handshake

    While I don’t think this issue allowed an attacker to impersonate a legitimate peer or perform a man-in-the-middle attack, fastd did accept some weird keys (the identity point) as valid keys, which shouldn’t be possible.

  • Fixed handling of severely reordered packets

    While fastd is supposed to handle reordered packets up to 64 sequence numbers, a bug would cause it to drop all older packets after a packet with a sequence number more than 64 packets in the future was received.

    The “verification failed” message has been downgraded from the “verbose” to the “debug2” level as it will cause a lot of log spam when there is extreme reordering.

  • x86 uClibc workaround

    A workaround has been added for systems without or with broken epoll_pwait libc wrappers. One libc with such a broken wrapper is the uClibc version used in OpenWrt on x86, which made fastd fail on OpenWrt x86 systems.

  • Only send packets from configured bind addresses

    When a configuration file contains only an IPv4 bind address and fastd tried to connect to an IPv6 remote address, it would use a random source port instead of falling back to IPv4 (and vice-versa).

    The behaviour without any bind addresses in the configuration hasn’t been changed.

Other changes

  • Better debug messages

    The sender’s public key will now be printed with more messages regarding handshake issues.

  • New handshake format

    Some parts of the handshake had been submitted as little endian for historical reasons. As the normal network byte order is big endian, support for a new handshake format using big endian has been added.

    fastd will continue to send its handshake the old format for the next versions to maintain compatiblity, but it does also understand the new format and will thus also work with future fastd versions which use the new handshake.

  • MTU mismatch is fatal

    fastd will now refuse to perform a handshake instead of just printing a warning when its configured MTU doesn’t match the peer’s one. Such a configuration is always broken and will lead to issues with big packets.