Keep Alive
-
@jimbo123 Maybe it pings localhost?
-
@jimbo123 I haven't looked at the code, so this is conjecture.
My guess is that the keep alive sends a state packet to the other endpoint. The issue is the timeout in any firewall in the path. Any packet will reset the timer.
If there is no means to initiate a connection from the remote end, there is likely no need for a keep-alive. The key reason to keep the tunnel active is for connections going in the reverse direction.
-
@traveller Ah ok, I’m curious how it would be aware any internal IPs to ping at the endpoint though? On my end I don’t have any tunnel IPs for the endpoint. Allowed IPs is set at 0000/0, I don’t have the tunnel address for the peer. Of course I have the servers public IP address but it wouldn’t ping that through the tunnel.
-
@jimbo123 I am fairly sure it is not a ping.
The tunnel has a connection to the endpoint. The local wireguard process can send the endpoint wireguard process a packet that has not real effect. It might even be as simple as a packet that is tagged as a keep-alive packet and dropped at the far end. No information is passed beyond the two wireguard processes.
SSH has a similar capability, but I cannot say how wireguard compares in its keep-alive handling.
-
@traveller Sorry I should have said an empty packet rather than “ping”. As long as it’s working correctly I’m happy. Thanks for your help, much appreciated.
-
If you are connecting to the VPN server behind a NAT, you will need to configure Keep Alive to a non-zero value to make sure that the NAT state entry on the router is retained and not cleared when no traffic is detected. Wireguard will then send keep alive packets periodically to the server based on the delay you specify so that the state entries are retained.
-
@dhiru Like @Traveller Was saying it's not important with my configuration because the "server" side doesn't need to sent traffic to me like it might if a site-to-site type setup was trying to be achieved. Unless you know otherwise, I don't think the use of NAT has anything to do with the decision to set a Keep Alive value. I can't think of a reason why it would, I can't remember reading anything about it in any of the WireGuard or openVPN documentation.
-
@jimbo123 When you assign an interface to the tunnel, you get a GW created under System > Routing > Gateway. Here you can specify the tunnel IP of the VPN provider end to be monitored or any public IP. The Gateway Monitoring Daemon will ping the IP and keep the tunnel up.
-
@ab5g Hi, I’m aware of that function but I don’t have the tunnel address of the VPN provider. It’s not something that’s required for WireGuard to work so they don’t give it to their connecting clients (peers). I could add a public IP address as a gateway monitor IP but I was more trying to figure out how Keep Alive works without any knowledge of tunnel IPs on the remote server side than anything else. I was thinking maybe it sends packets to localhost on 127.0.0.1 but I’m just guessing.
-
From the
wgmanual page on Linux:PersistentKeepalive -- a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently. For example, if the interface very rarely sends traffic, but it might at anytime receive traffic from a peer, and it is behind NAT, the interface might benefit from having a persistent keepalive interval of 25 seconds. If set to 0 or "off", this option is disabled. By default or when unspecified, this option is off. Most users will not need this. Optional.
-
@jimbo123 If you don't have the tunnel ip of the remote peer, because it is under NAT then the remote peer has to initiate the connection to you first. After the connection is up, you can keep it up by either using a keep alive timer of 20 sec or by the method I described above.
I have a very similar setup, whereby upstream VPN provider is behind a NAT (aka its a raspberry pi in my parent's house) - I get it to initiate the tunnel and then keep the tunnel up from my end by monitoring the 'internal' tunnel IP.Pfsense tunnel ip - 10.100.100.1/24
PI tunnel ip - 10.100.100.20/32
PI public IP - DynamicSo once the tunnel is up I monitor 10.100.100.20 to keep the tunnel up.
Alternatively under the remote peer config on pfsense set the keepliave to 20. -
@dem Thanks for digging that out
. When it says an “authenticated empty packet to the peer” I’m assuming that as it says “authenticated” it must mean the Keep Alive is sent to the remote peers public endpoint address and port number? Thanks for finding that. -
@ab5g Thanks for the reply, I’m on the client side connecting to my VPN provider so I initiate the tunnel and the server’s not behind NAT. That’s not something I’m concerned about. I use Keep Alive using OpenVPN with my VPN provider so that I don’t have to wait 10 seconds or so for the connection to re-establish every time the tunnel drops. As I understand, the time to re-establish the tunnel isn’t a problem with WireGuard. I was just trying to understand where the Keep Alive packets get sent if my end of the tunnel isn’t aware of any tunnel IP on the server side and if I should just set the value back to zero if it’s not doing anything. I think from @dem ’s reply with Linux documentation it maybe works differently to openVPN and the Keep Alive send an empty authenticated packet to the public IP address of the peer. Not too sure though.
-
I copied this from the WireGuard documentation:
This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.
I think by saying “a keepalive packet is sent to the server endpoint” they must mean the public IP address because on the pfSense GUI the Endpoint address is the public one and the Peer WireGuard Address is used to describe the peers tunnel address.
