The openvpn client suddenly disconnects
Open
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.6k
- Forks
- 3.4k
- PR merge metrics
- No merged PRs in 30d
Description
Apr 28 04:46:01 ubuntu openvpn[740]: SENT CONTROL [p-qcbj7-pe-cs-vpn-02]: 'PUSH_REQUEST' (status=1)
Apr 28 04:46:02 ubuntu openvpn[740]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.132.252.4,dhcp-option DNS 10.132.253.9,compress lz4-v2,route 10.0.0.0 255.0.0.0,route-gateway 172.31.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 172.31.5.35 255.255.0.0,peer-id 198,cipher AES-256-GCM'
Apr 28 04:46:02 ubuntu openvpn[740]: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: timers and/or timeouts modified
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: compression parms modified
Apr 28 04:46:02 ubuntu openvpn[740]: LZ4v2 compression initializing
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: --ifconfig/up options modified
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: route options modified
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: route-related options modified
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: peer-id set
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: adjusting link_mtu to 1625
Apr 28 04:46:02 ubuntu openvpn[740]: OPTIONS IMPORT: data channel crypto options modified
Apr 28 04:46:02 ubuntu openvpn[740]: Data Channel: using negotiated cipher 'AES-256-GCM'
Apr 28 04:46:02 ubuntu openvpn[740]: Data Channel MTU parms [ L:1553 D:1450 EF:53 EB:406 ET:0 EL:3 ]
Apr 28 04:46:02 ubuntu openvpn[740]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 28 04:46:02 ubuntu openvpn[740]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 28 04:46:02 ubuntu openvpn[740]: Preserving previous TUN/TAP instance: tun0
Apr 28 04:46:02 ubuntu openvpn[740]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Apr 28 04:46:02 ubuntu openvpn[740]: net_route_v4_del: 10.0.0.0/8 via 172.31.0.1 dev [NULL] table 0 metric -1
Apr 28 04:46:02 ubuntu openvpn[740]: sitnl_send: rtnl: generic error (-1): Operation not permitted
Apr 28 04:46:02 ubuntu openvpn[740]: ERROR: Linux route delete command failed
Apr 28 04:46:02 ubuntu openvpn[740]: Closing TUN/TAP interface
Apr 28 04:46:02 ubuntu openvpn[740]: net_addr_v4_del: 172.31.4.119 dev tun0
Apr 28 04:46:02 ubuntu openvpn[740]: sitnl_send: rtnl: generic error (-1): Operation not permitted
Apr 28 04:46:02 ubuntu openvpn[740]: Linux can't del IP from iface tun0
Apr 28 04:46:02 ubuntu systemd-networkd[644]: tun0: Link DOWN
Apr 28 04:46:02 ubuntu systemd-networkd[644]: tun0: Lost carrier
Apr 28 04:46:03 ubuntu openvpn[740]: net_route_v4_best_gw query: dst 0.0.0.0
Apr 28 04:46:03 ubuntu openvpn[740]: net_route_v4_best_gw result: via 192.168.1.1 dev eth0
Apr 28 04:46:03 ubuntu openvpn[740]: ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=d8:3a:dd:e6:d1:da
Apr 28 04:46:03 ubuntu openvpn[740]: ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Apr 28 04:46:03 ubuntu openvpn[740]: Exiting due to fatal error
Apr 28 04:46:03 ubuntu systemd[1]: openvpn-client@nio.service: Main process exited, code=exited, status=1/FAILURE
Apr 28 04:46:03 ubuntu systemd[1]: openvpn-client@nio.service: Failed with result 'exit-code'.
Apr 28 04:46:03 ubuntu systemd[1]: openvpn-client@nio.service: Consumed 10.331s CPU time.
This is my syslog,
power 735 1 0 16:52 ? 00:00:00 /usr/sbin/openvpn
this is Process user
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the OpenVPN client log for openvpn-client@nio.service, focusing on the failed route and TUN/TAP operations, especially TUNSETIFF and the tun0 interface. Reproduce the disconnect and determine whether the reported permission errors are caused by the client or its service environment; done means the client reconnects without those fatal errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100