search

neocturne / fastd

Fast and Secure Tunnelling Daemon
Other
115 stars 16 forks source link

Keepalive mechanism #31

Closed marek22k closed 1 year ago

marek22k commented 1 year ago

Hello,

I wanted to ask if there is a keepalive mechanism like WireGuard have. If no, this should be a feature request.

A keepalive mechanism is useful when one peer is publicly reachable but the other is behind a NAT / firewall. Assuming both are not communicating regularly, the NAT or firewall forgets the Conntrack entry and the public peer can no longer reach the other peer. Therefore a keepalive mechanism would be nice.

This could be implemented by sending a kind of ping every X (adjustable) seconds.

neocturne commented 1 year ago

Hi @marek22k,

fastd does have a keepalive mechanism - besides keeping conntrack entries alive, it is also use to detect whether a connection is still alive or if the peer has disappeared. This is not configurable, but done unconditionally.

fastd sends a keepalive packet whenever there hasn't been any (keepalive or payload*) traffic for 20 seconds. After 90 seconds without receiving a packet from a peer, a connection is considered dead and will be reset.

( in L2TP offload mode, keepalive packets are sent every 20 seconds unconditionally*, as the payload packets are handled in the kernel and fastd doesn't actually see whether there is regular traffic)

marek22k commented 11 months ago

Maybe it is possible to introduce a switch with which you can change the interval?

neocturne commented 11 months ago

Maybe it is possible to introduce a switch with which you can change the interval?

Would be possible. Do you have the need to switch over to a different peer faster when the connection is lost?

marek22k commented 11 months ago

No, fastd works fine for me at 20 seconds (though both peers are public).

Another useful use would also be to increase the keepalive in case you know the Conntrack timeout of the firewall and want to minimize traffic.

For my purposes, the switch would probably be unnecessary.

neocturne commented 11 months ago

Then let's not increase complexity by adding configurability where it's not needed :)