You are not logged in.
Pages: 1
My client.conf:
client
dev tun
proto tcp
ping 10
ping-restart 300
remote vpn-ip 501
auth-nocache
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
auth sha256
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 5
reneg-sec 0
crl-verify /home/archuser/.crl.rsa.4096.pem
ca /home/archuser/.ca.rsa.4096.crt
auth-user-pass /home/archuser/.password_pia.txt
mute 40
disable-occ
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.shwith openvpn-reconnect from aur installed:
Jul 09 16:17:06 arch openvpn[404]: AUTH: Received control message: AUTH_FAILED
Jul 09 16:17:06 arch openvpn[404]: TCP/UDP: Closing socket
Jul 09 16:17:06 arch openvpn[404]: SIGTERM[soft,auth-failure] received, process exitand openvpn can't be found on ps -a
(I've tried with the systemd service found on the wiki just below and it yielded the same result)
Last edited by leethaxor (2018-07-15 08:50:09)
Offline
Did you tried to connect from command line without all that stuff like openvpn-reconnect and auth-user-pass with file to be sure that you can connect?
Last edited by sincomil (2018-07-09 14:52:10)
Offline
Yes, I can connect after suspend in a terminal both with and without auth-user-pass and without openvpn-reconnect
Last edited by leethaxor (2018-07-09 15:39:25)
Offline
Can you try to run openvpn from terminal and then put you computer to the suspend state, then go back to wake it and check what it writes in terminal?
Offline
after suspend and without --allow-recursive-routing (like before):
Tue Jul 10 11:09:41 2018 us=327013 Recursive routing detected, drop tun packet to [AF_INET]37.226.237.139:501ected, drop tun packet to [ArWrW^CTue Jul 10 11:09:42 2018 us=852630 event_wait : Interrupted system call (code=4)after suspend and with --allow-recursive-routing:
WrWrWrWRwRwrWRwrWrWRwRwRwrWrWrWRwrWrWrWrWRwRwrWrWRwrWrWrWRwRwRwrWrWrWRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWrWRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWrWRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwrWRwrWrWRwRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwrWRwRwrWrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWrWRwRwrWrWRwrWrWRwrWRwRwrWRwrWrWRwrWrWrWRwRwRwrWrWRwRwrWRwrWRwrWrWrWRwRwRwRwrWrWrWrWRwRwrWRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWRwRwrWRwrWrWRwRwRwrWrWRwrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWTue Jul 10 11:23:09 2018 us=459333 [7w2ad1ae2e3377321a13784ef87257uk] Inactivity timeout (--ping-restart), restarting
Tue Jul 10 11:23:09 2018 us=459649 TCP/UDP: Closing socket
Tue Jul 10 11:23:09 2018 us=459734 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jul 10 11:23:09 2018 us=459782 Restart pause, 5 second(s)
Tue Jul 10 11:23:14 2018 us=459976 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul 10 11:23:14 2018 us=460068 Re-using SSL/TLS context
Tue Jul 10 11:23:14 2018 us=460238 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Tue Jul 10 11:23:14 2018 us=460288 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Tue Jul 10 11:23:14 2018 us=460354 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
Tue Jul 10 11:23:14 2018 us=460375 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
Tue Jul 10 11:23:14 2018 us=460410 TCP/UDP: Preserving recently used remote address: [AF_INET]37.226.237.139:501
Tue Jul 10 11:23:14 2018 us=460468 Socket Buffers: R=[87380->87380] S=[16384->16384]
Tue Jul 10 11:23:14 2018 us=460490 Attempting to establish TCP connection with [AF_INET]37.226.237.139:501 [nonblock]
Tue Jul 10 11:25:14 2018 us=480548 TCP: connect to [AF_INET]37.226.237.139:501 failed: Connection timed out
Tue Jul 10 11:25:14 2018 us=480795 SIGUSR1[connection failed(soft),init_instance] received, process restarting
Tue Jul 10 11:25:14 2018 us=480871 Restart pause, 5 second(s)
Tue Jul 10 11:25:19 2018 us=481071 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul 10 11:25:19 2018 us=481166 Re-using SSL/TLS context
Tue Jul 10 11:25:19 2018 us=481361 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Tue Jul 10 11:25:19 2018 us=481414 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Tue Jul 10 11:25:19 2018 us=481493 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
Tue Jul 10 11:25:19 2018 us=481517 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1572,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
Tue Jul 10 11:25:19 2018 us=481599 TCP/UDP: Preserving recently used remote address: [AF_INET]37.226.237.139:501
Tue Jul 10 11:25:19 2018 us=481668 Socket Buffers: R=[87380->87380] S=[16384->16384]
Tue Jul 10 11:25:19 2018 us=481696 Attempting to establish TCP connection with [AF_INET]37.226.237.139:501 [nonblock]Offline
It seems that something going wrong with routing table after exiting from suspend state.
can you check
$ ip ro shbefore suspend and then after wake up?
And also need to check what routes are pushed down from openvpn server side.
Last edited by sincomil (2018-07-10 11:53:22)
Offline
Before suspend:
0.0.0.0/1 via 10.30.1.13 dev tun0
default via 192.168.1.1 dev enp2s0 proto dhcp src 192.168.1.143 metric 302
10.30.1.1 via 10.30.1.13 dev tun0
10.30.1.13 dev tun0 proto kernel scope link src 10.30.1.14
128.0.0.0/1 via 10.30.1.13 dev tun0
185.230.125.53 via 192.168.1.1 dev enp2s0
192.168.1.0/24 dev enp2s0 proto dhcp scope link src 192.168.1.143 metric 302 After suspend:
0.0.0.0/1 via 10.30.1.13 dev tun0
10.30.1.1 via 10.30.1.13 dev tun0
10.30.1.13 dev tun0 proto kernel scope link src 10.30.1.14
128.0.0.0/1 via 10.30.1.13 dev tun0 It goes back to as it was before suspend after I kill the openvpn pid AFTER suspend. And it looks like this without any VPN service running:
default via 192.168.1.1 dev enp2s0 proto dhcp src 192.168.1.143 metric 302
192.168.1.0/24 dev enp2s0 proto dhcp scope link src 192.168.1.143 metric 302Edit: I don't know how to check which routes are being sent from server both because I'm not very familiar with openvpn and because I don't have access to the VPN server itself since I bought the service.
Last edited by leethaxor (2018-07-10 16:23:47)
Offline
Looks like your computer looses routes through network adapter after wake up. This is the main cause of the problem with openvpn connection.
Another question is: why network adapter routes are disappeared?
If your network adapter is configures with NetworkManager, then I offer you to try to temporarily configure network through netctl for that network adapter.
In your case you have to
1. copy /etc/netctl/examples/ethernet-dhcp to /etc/netctl/
2. disconnect your network adapter from network with NetworkManager applet
3. run
sudo netctl start ethernet-dhcpAfter that check that you network is working and then try to suspend/wake up procedure with and without openvpn running on backgroud. Each time watch you routes before and after suspend/wakeup
Last edited by sincomil (2018-07-11 07:16:30)
Offline
I am not using NetworkManager. I've got i3 as wm and broadcom as wireless card. I use broadcom-wl and I'm running arch linux on a Macbook.
Offline
Then you should check what prevents you network adapter to get up after suspend.
I think you should also check what network manager do you use:
https://wiki.archlinux.org/index.php/Ne … figuration
they are not so many:
ConnMan
Netctl
NetworkManager
Systemd-networkd
Wicd
and then check what happens on that side.
Offline
lspci -v
03:00.0 Network controller: Broadcom Limited BCM4360 802.11ac Wireless Network Adapter (rev 03)
Subsystem: Apple Inc. BCM4360 802.11ac Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at b0600000 (64-bit, non-prefetchable) [size=32K]
Memory at b0400000 (64-bit, non-prefetchable) [size=2M]
Capabilities: <access denied>
Kernel driver in use: wl
Kernel modules: bcma, wlonly network related from "dmesg":
[ 38.792289] wlan0: Broadcom BCM43a0 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)I am using Netctl with this configuration that starts automatically via systemd service:
Description='A simple WPA encrypted wireless connection'
Interface=enp2s0
Connection=wireless
Security=wpa
IP=dhcp
ESSID='network-ESSID'
# Prepend hexadecimal keys with \"
# If your key starts with ", write it as '""<key>"'
# See also: the section on special quoting rules in netctl.profile(5)
Key='secretKey'
# Uncomment this if your ssid is hidden
#Hidden=yes
# Set a priority for automatic profile selection
#Priority=10I enabled this network configuration with the command "netctl enable wireless-network" and I am using broadcom-wl 6.30.223.271-26 to get network access. My vpn method uses openvpn 2.4.6-1 and my system is fully updated. Restarting openvpn after suspend has never worked for me. I also use wpa_supplicant 1:2.6-11 to enable wpa network connection via Netctl.
Edit: not having openvpn started works fine, my computer starts and connects to the network just fine and there is no change to the router settings.
Last edited by leethaxor (2018-07-12 08:46:30)
Offline
I write another post because an edit might not be so obvious. The issue might be because of my Broadcom wireless card. I created another post for my issue about spoofing the mac address and conclution wise Broadcom wireless network drivers aren't exactly made for linux. I guess because of this my network makes changes that regular network cards and drivers don't, which results in me not being able to reconnect to my VPN properly.
Offline
I solved this issue by creating a python script that checks for difference in time. If the difference in time is greater than 1 second it kills the vpn, sleeps 15 seconds and then starts openvpn as a daemon again.
Offline
Pages: 1