ANSWERED Real IP exposed for a few days

[airvpn88 1]

Hi,

 

I have been happily using AirVPN with the same config for a few years. But today, I just realized that my real IP has probably been exposed for a few days. I restarted openvpn and everything is now back to normal, but I would like to avoid that in the future, and I would appreciate any relevant advice.

 

I use an up to date Debian 9, and openvpn from the official packages. I created the config with the AirVPN configurator, and I added these lines, in order to automatically restart a stalled connection, and to have stats :

 

ping 10
ping-restart 60
remap-usr1 SIGHUP
status openvpn-status.log

 

What follows are excerpts from the syslog. It started like this:

 

[Altarf] Inactivity timeout (--ping-restart), restarting
/sbin/ip route del 62.102.xxx.xxx/32
/sbin/ip route del 0.0.0.0/1
/sbin/ip route del 128.0.0.0/1
Closing TUN/TAP interface
/sbin/ip addr del dev tun0 10.4.xxx.xxx/16
SIGHUP[soft,ping-restart] received, process restarting

 

Inactivity timeout is always working well. But not this time:

 

RESOLVE: Cannot resolve host address: europe.vpn.airdns.org:443 (Temporary failure in name resolution)

 

The resolving problems lasts for half an hour. After that, inactivity was still detected, restarting every minute :

 

[uNDEF] Inactivity timeout (--ping-restart), restarting
 

After one hour hour after, I see this message :

 

[server] Peer Connection Initiated with [AF_INET]213.152.xxx.xxx:443
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
AUTH: Received control message: AUTH_FAILED
SIGTERM received, sending exit notification to peer
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
SIGTERM[soft,exit-with-notification] received, process exiting

 

From now on, openvpn did not retry to connect, and my reaI IP is exposed. It was 4 days ago. How can I avoid such a behavior, so that my real IP is hidden, even if something like this happens again?

[LZ1 672]

Hello!

 

It goes without saying but the easiest way is using Airs software, Eddie, with Network Lock on.

[airvpn88 1]

Thanks!

 

I just thought, what if I simply remove the default route? Would that be a good idea? In that case, do I have to add manually a route to AirVPN, in case the tunnel fails?

[Staff 9973]

@airvpn88

 

Hello,

 

you might consider to run Eddie with Network Lock enabled. In this way you will prevent any possible traffic leak outside the tunnel and Eddie will also re-connect automatically when the connection is lost. If you don't have a graphical environment in your Debian system, Eddie can also run in "command line" mode.

 

Kind regards

[airvpn88 1]

Thank you for your answer.

 

I like to have a maximal control and understanding of my systems, so I would prefer not to use Eddie and write my own kill switch. Right now, I think I'm going for something like this :

 

A process or a service watches the output of "ip monitor route", and if I catch "Deleted 0.0.0.0/1 via 10.4.0.1 dev tun0" then I stop/kill some sensitive services/processes.

 

Do you think there is a better or a cleaner way to do this?

[go558a83nk 362]

Thank you for your answer.

 

I like to have a maximal control and understanding of my systems, so I would prefer not to use Eddie and write my own kill switch. Right now, I think I'm going for something like this :

 

A process or a service watches the output of "ip monitor route", and if I catch "Deleted 0.0.0.0/1 via 10.4.0.1 dev tun0" then I stop/kill some sensitive services/processes.

 

Do you think there is a better or a cleaner way to do this?

 

 

If it were me I'd download Eddie and see what iptables it puts in place with the network lock.  Then I'd imitate that.  If I wasn't going to use Eddie, that is.

[LZ1 672]

If I'm not mistaken, you can see some or all the rules here already.

[airvpn88 1]

I just implemented my idea with as a systemd service, it seems to work.

 

Anyway, thanks for your advices and ideas!

[LZ1 672]

What did you do exactly? Maybe it can help others

[airvpn88 1]

This is the watchdog script, that stops a sensitive service if the route to the VPN is deleted (/usr/local/sbin/kill-switch.sh) :

 

#!/bin/bash
(ip monitor route) | while read line; do
    if [ "${line}" == 'Deleted 0.0.0.0/1 via 10.4.0.1 dev tun0' ]; then
        msg='VPN route lost.\n'
        systemctl is-active sensitive.service
        if [ $? -eq 0 ]; then
            systemctl stop sensitive.service
            msg="${msg}Kill-switch stopped sensitive service.\n"
        fi
        printf "${msg}" | mail -s "Kill-switch" root
    fi
done

exit 0

 

This is the systemd unit file (/etc/systemd/system/kill-switch.service):

 

[Unit]
Description=kill-switch
After=network.target sys-devices-virtual-net-tun0.device

[Service]
Type=simple
ExecStart=/usr/local/sbin/kill-switch.sh

Restart=on-failure

[Install]
WantedBy=multi-user.target

 

Finally, I enabled the service and started it:

 

# chmod 750 /usr/local/sbin/kill-switch.sh
# systemctl enable kill-switch.service
# systemctl start kill-switch.service

 

 

I would be happy if anyone sees ways to improve this