openvpn client stopped working with 6.5.0 update
My Turris Omnia just got auto-updated from 6.4.4 to 6.5.0. The openvpn client configuration that I have for multiple years suddenly stopped working properly. The vpn connection shows as connected, but no traffic flows through the router anymore with the vpn on. I have to disable the vpn to get connectivity again.
Which logs can help debug this situation?
Activity
added Omnia Unconfirmed labels
added Plugins label
From notebook:
[XXX@XXX ~]$ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 _gateway (192.168.13.1) 0.509 ms 0.449 ms 0.526 ms 2 _gateway (192.168.13.1) 0.546 ms 0.546 ms * [XXX@XXX ~]$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56 (84) datových bajtů. Od 192.168.13.1 pořadí=1 Cílový port nedostupný Od 192.168.13.1 pořadí=2 Cílový port nedostupný Od 192.168.13.1 pořadí=3 Cílový port nedostupný Od 192.168.13.1 pořadí=4 Cílový port nedostupný Od 192.168.13.1 pořadí=5 Cílový port nedostupný ^C --- Statistika pingů na 8.8.8.8 --- 5 paketů odesláno, 0 přijato, +5 chyb, 100% packet loss, time 4110ms [XXX@XXX ~]$ route -n Směrovací tabulka v jádru pro IP Adresát Brána Maska Přízn Metrik Odkazů Užt Rozhraní 0.0.0.0 192.168.13.1 0.0.0.0 UG 20100 0 0 enp2s0 192.168.13.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0From the Shield (ovpn client):
root@shield:~# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 46 byte packets 1 10.111.111.1 (10.111.111.1) 29.094 ms 26.233 ms 27.172 ms 2 * * * 3 XXX 29.756 ms 28.054 ms 29.563 ms 4 XXX 31.463 ms XXX 31.977 ms XXX 79.604 ms 5 XXX 32.154 ms XXX (XXX) 31.574 ms 33.563 ms 6 google.peering.cz (185.0.20.170) 31.370 ms 32.817 ms 33.150 ms 7 192.178.98.35 (192.178.98.35) 33.108 ms 34.058 ms 192.178.98.171 (192.178.98.171) 30.855 ms 8 209.85.246.117 (209.85.246.117) 31.826 ms 142.251.224.229 (142.251.224.229) 38.097 ms 209.85.246.117 (209.85.246.117) 32.207 ms 9 dns.google (8.8.8.8) 36.761 ms 35.381 ms 36.374 ms root@shield:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=38.9 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=35.5 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=38.0 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=37.2 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 35.495/37.405/38.904/1.255 ms root@shield:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.111.111.1 128.0.0.0 UG 0 0 0 tun_turris 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 10.111.111.0 0.0.0.0 255.255.255.0 U 0 0 0 tun_turris XX.XX.XXX.XX 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0 128.0.0.0 10.111.111.1 128.0.0.0 UG 0 0 0 tun_turris 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 10.111.111.1 255.255.255.0 UG 0 0 0 tun_turris 192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lanRouting stuff from log:
Jan 24 16:17:32 shield openvpn(XXX)[24500]: net_route_v4_add: XX.XX.XX.XX/32 via 192.168.0.1 dev [NULL] table 0 metric -1 Jan 24 16:17:32 shield openvpn(XXX)[24500]: net_route_v4_add: 0.0.0.0/1 via 10.111.111.1 dev [NULL] table 0 metric -1 Jan 24 16:17:32 shield openvpn(XXX)[24500]: net_route_v4_add: 128.0.0.0/1 via 10.111.111.1 dev [NULL] table 0 metric -1 Jan 24 16:17:32 shield openvpn(XXX)[24500]: net_route_v4_add: 192.168.1.0/24 via 10.111.111.1 dev [NULL] table 0 metric -1Edited by Dan Matějka
Hi,
sorry for troubles. Look closer on the problem and I find the "bug". As temporary solution open on client's side openvpn under init.d folder with editor.
vim /etc/init.d/openvpn
go to the line 142, you should see here something like "local conf=$(basename "$3")" change it to:
local conf="$3"
and then edit few lines lower:
"local client=$(grep -qEx "client|tls-client" "$dir/$conf" && echo 1)" to local client=$(grep -qEx "client|tls-client" "$conf" && echo 1)then save the changes and restart openvpn service with command /etc/init.d/openvpn reload
Now should connection works.
Edited by Tomas Zakremoved Unconfirmed label
@tzak Nice, thank you. Confirmed this works.
-
@amit Happy to help if I can. Of course this is temp. solution working on fix. ;-)
