ANSWERED Question about strange ping to AirVPN using OpenVPN

[thekvpn 0]

I am using OpenVPN to establish a connection with the server. I also implemented a kill switch with iptables to ensure that traffic can only use the tunnel (tun0) once established (it may be an unnecessary measure, but it is part of my experimentation). Everything works fine, although while looking at the logs of my iptables, I found a strange packet that I can't explain.
 

Every 10 seconds (I assume it is OpenVPN's ping), a packet is sent through my physical interface (enp0s3) to an endpoint that is 2 units greater than the IP of the server I am connected to. For example, if I am connected to the Alruba server, my exit IPv4 is 185.195.237.203, and this "strange packet" is directed to 185.195.237.205. This is always the case, +2 to the IP of the server I am connected to (I have tried with various different servers).

Clearly, this is due to a manipulation that OpenVPN makes on my routing table once a connection with AirVPN is established.

EDIT: Now that I review it again, the IP where this ping is sent is the IP of the server, meaning the outgoing IP is always -2 from the server. Still, I wonder why OpenVPN uses my physical interface. Is it to reconnect in case the connection is lost?

My question is, what is the purpose of this "ping"? Is it correct that it uses the physical interface? If it is to verify the connection with the VPN, shouldn’t it use tun0? Is this a mechanism of OpenVPN to ensure that there is no packet leakage?
 

I am attaching the log of my iptables and my routes.
 

0.0.0.0/1 via 10.26.54.1 dev tun0 
default via 192.168.0.1 dev enp0s3 proto dhcp src 192.168.0.11 metric 100 
10.26.54.0/24 dev tun0 proto kernel scope link src 10.26.54.199 
128.0.0.0/1 via 10.26.54.1 dev tun0 
185.195.237.205 via 192.168.0.1 dev enp0s3 
192.168.0.0/24 dev enp0s3 proto kernel scope link src 192.168.0.11 metric 100 

oct 07 12:54:51 nixos kernel: Blocked OUTPUT: IN= OUT=enp0s3 SRC=192.168.0.11 DST=185.195.237.205 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=53227 DF PROTO=UDP SPT=57679 DPT=443 LEN=49 
oct 07 12:55:01 nixos kernel: Blocked OUTPUT: IN= OUT=enp0s3 SRC=192.168.0.11 DST=185.195.237.205 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=56793 DF PROTO=UDP SPT=57679 DPT=443 LEN=49 
oct 07 12:55:11 nixos kernel: Blocked OUTPUT: IN= OUT=enp0s3 SRC=192.168.0.11 DST=185.195.237.205 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=63963 DF PROTO=UDP SPT=57679 DPT=443 LEN=49

❤️
 

Edited 10/07/2024 by thekvpn

[Staff 10116]

  On 10/7/2024 at 4:12 PM, thekvpn said:

the IP where this ping is sent is the IP of the server, meaning the outgoing IP is always -2 from the server

Hello!

AirVPN servers have different entry and exit IP addresses to prevent various correlation attacks.
 

  Quote

what is the purpose of this "ping"?

An OpenVPN ping (not to be confused with the ping tool relying on ICMP) every 10 seconds is part of the keep alive session method implemented in OpenVPN and compliant with the configuration "ping" directive. See also OpenVPN manual:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6 (jump to --ping n)
 

  Quote

Is it correct that it uses the physical interface? ...

Yes, it is correct. Any virtual network must at some point rely on something physical.


  Quote

If it is to verify the connection with the VPN, shouldn’t it use tun0?

OpenVPN's ping is inside the OpenVPN Control Channel and not inside the Data Channel. Keep in mind that OpenVPN performs multiplexing, i.e it combines multiple logical channels in a single physical channel. In AirVPN configuration, OpenVPN's ping and the whole Control Channel are cryptographically secure.

Kind regards
 

[thekvpn 0]

Thank you! Everything is clearer to me now.