Score:-1

OpenVPN headless on Debian 11.7 IP does not change

cn flag

I have a ProtonVPN paid account. I want to use it on my VPS server (so in headless), to change my ip.

Their client does not work in headless mode, so I use OpenVPN.

I download the Linux config file on ProtonVPN. I installed ProtonVPN and resolvconf.

When I launch :

sudo openvpn conf_vpn.ovpn

It seems to work :

2023-07-31 11:21:54 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2023-07-31 11:21:54 OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
2023-07-31 11:21:54 library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
2023-07-31 11:21:54 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-07-31 11:21:54 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2023-07-31 11:21:54 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2023-07-31 11:21:54 TCP/UDP: Preserving recently used remote address: [AF_INET]146.70.194.98:51820
2023-07-31 11:21:54 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-07-31 11:21:54 UDP link local: (not bound)
2023-07-31 11:21:54 UDP link remote: [AF_INET]146.70.194.98:51820
2023-07-31 11:21:54 TLS: Initial packet from [AF_INET]146.70.194.98:51820, sid=69f07161 a4eee661
2023-07-31 11:21:54 VERIFY OK: depth=2, C=CH, O=ProtonVPN AG, CN=ProtonVPN Root CA
2023-07-31 11:21:54 VERIFY OK: depth=1, C=CH, O=ProtonVPN AG, CN=ProtonVPN Intermediate CA 1
2023-07-31 11:21:54 VERIFY KU OK
2023-07-31 11:21:54 Validating certificate extended key usage
2023-07-31 11:21:54 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Server Authentication
2023-07-31 11:21:54 ++ Certificate has EKU (oid) 1.3.6.1.5.5.7.3.2, expects TLS Web Server Authentication
2023-07-31 11:21:54 ++ Certificate has EKU (str) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
2023-07-31 11:21:54 ++ Certificate has EKU (oid) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
2023-07-31 11:21:54 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2023-07-31 11:21:54 VERIFY EKU OK
2023-07-31 11:21:54 VERIFY OK: depth=0, CN=node-fr-21.protonvpn.net
2023-07-31 11:21:54 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634'
2023-07-31 11:21:54 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
2023-07-31 11:21:54 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
2023-07-31 11:21:54 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
2023-07-31 11:21:54 [node-fr-21.protonvpn.net] Peer Connection Initiated with [AF_INET]146.70.194.98:51820
2023-07-31 11:21:55 SENT CONTROL [node-fr-21.protonvpn.net]: 'PUSH_REQUEST' (status=1)
2023-07-31 11:21:55 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.16.0.1,sndbuf 524288,rcvbuf 524288,redirect-gateway def1,explicit-exit-notify,comp-lzo no,route-gateway 10.16.0.1,topology subnet,ping 10,ping-restart 60,socket-flags TCP_NODELAY,ifconfig 10.16.0.8 255.255.0.0,peer-id 6,cipher AES-256-GCM'
2023-07-31 11:21:55 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
2023-07-31 11:21:55 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
2023-07-31 11:21:55 OPTIONS IMPORT: timers and/or timeouts modified
2023-07-31 11:21:55 OPTIONS IMPORT: explicit notify parm(s) modified
2023-07-31 11:21:55 OPTIONS IMPORT: compression parms modified
2023-07-31 11:21:55 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
2023-07-31 11:21:55 Socket Buffers: R=[212992->425984] S=[212992->425984]
2023-07-31 11:21:55 OPTIONS IMPORT: --socket-flags option modified
2023-07-31 11:21:55 NOTE: setsockopt TCP_NODELAY=1 failed
2023-07-31 11:21:55 OPTIONS IMPORT: --ifconfig/up options modified
2023-07-31 11:21:55 OPTIONS IMPORT: route-related options modified
2023-07-31 11:21:55 OPTIONS IMPORT: peer-id set
2023-07-31 11:21:55 OPTIONS IMPORT: adjusting link_mtu to 1656
2023-07-31 11:21:55 OPTIONS IMPORT: data channel crypto options modified
2023-07-31 11:21:55 Data Channel: using negotiated cipher 'AES-256-GCM'
2023-07-31 11:21:55 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-07-31 11:21:55 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2023-07-31 11:21:55 TUN/TAP device tun0 opened
2023-07-31 11:21:55 net_iface_mtu_set: mtu 1500 for tun0
2023-07-31 11:21:55 net_iface_up: set tun0 up
2023-07-31 11:21:55 net_addr_v4_add: 10.16.0.8/16 dev tun0
2023-07-31 11:21:55 /etc/openvpn/update-resolv-conf tun0 1500 1584 10.16.0.8 255.255.0.0 init
resolvconf: Error: Command not recognized
Usage: resolvconf (-d IFACE|-a IFACE|-u|--enable-updates|--disable-updates|--updates-are-enabled)
2023-07-31 11:21:55 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-07-31 11:21:55 Initialization Sequence Completed

But if I let this Terminal tab open, and open a new one connecting by ssh, and run :

curl -s https://ipinfo.io/ip

My IP has not changed at all.

I see that I have the error :

resolvconf: Error: Command not recognized

But when I launch (with or without sudo) :

sudo /etc/openvpn/update-resolv-conf tun0 1500 1584 10.20.0.8 255.255.0.0 init

it seems to work because I don't have any warning.

What did I forget ?

Score:1
ws flag

Openvpn creates a new interface on your machine (tun0) the "outside" part of this is connected to your existing interface. So any software running on your computer which wants to connect to the outside world has to decide whether to send the packets via the original interface or the openvpn one.....actually its the kernel which does the deciding part, and that uses the routing table. You can see the routes with:

sudo ip route -4

If you want all your internet traffic to use the VPN link, then you need to tell your computer to use a router on the VPN subnet as the default route. The openvpn client will handle the details for you when it has the right config. Your VPN provider should have given you this address.

user2178964 avatar
cn flag
Thank you, it seems that I have add a rule : "route-nopul" in my config file to not block the ssh connection to my vps, but it is not the right to do this, and it break everything else. Without this I assume it will be working. The problem is that it seems that if I want to redirect all trafic except my ssh connection to the VPS, I need to have a computer with a static IP, because I will need to add a specific IP rule based :/
Score:0
cn flag

Finally I just put a rule for the website I want with a script, and remove the route-no pull instruction in the openvpn config file.

#!/bin/bash

sudo pkill openvpn

website="www.targetedwebsite.com"
config_file="conf_vpn.ovpn"

# Start the OpenVPN client.
sudo openvpn --config $config_file --daemon

# Give OpenVPN a few seconds to establish the connection.
sleep 5

# Use `dig` to find the IP addresses for the website.
ip_addresses=$(dig +short $website)

# Loop over the IP addresses.
for ip_address in $ip_addresses; do
    # Check if the line is an IP address.
    if [[ $ip_address =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
        # Add a route for the IP address.
        sudo ip route add $ip_address/32 dev tun0
        echo "Added route for $ip_address"
    fi
done
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.