Closed
Bug 1121999
Opened 11 years ago
Closed 10 years ago
frequent, intermittent vpn drops
Categories
(Infrastructure & Operations :: Corporate VPN: Support requests, task)
Infrastructure & Operations
Corporate VPN: Support requests
x86_64
Linux
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: bhearsum, Assigned: jabba)
Details
I've been experiencing this for at least a couple of months now. It's not consistent, but it can happen anywhere from 1 to 10 times a day. The drops happen without any notification on my side. Ie, Network Manager still thinks it's connected. This generally shows up as being unable to resolve Mozilla sites (because I can no longer route to the DNS server). Disconnecting and reconnecting to the VPN fix it every time. Here's what little syslog info I have from this morning. The events at 9:30:22 appear to be when the drop happened. 9:37 is when i disconnected/reconnected manually. (Times are all in EST):
Jan 15 09:10:19 dib nm-openvpn[6728]: [openvpn.scl3.mozilla.com] Inactivity timeout (--ping-restart), restarting
Jan 15 09:10:19 dib nm-openvpn[6728]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 09:10:21 dib nm-openvpn[6728]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 15 09:10:21 dib nm-openvpn[6728]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 09:10:21 dib nm-openvpn[6728]: UDPv4 link local: [undef]
Jan 15 09:10:21 dib nm-openvpn[6728]: UDPv4 link remote: [AF_INET]63.245.214.137:1194
Jan 15 09:10:23 dib nm-openvpn[6728]: [openvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.137:1194
Jan 15 09:10:26 dib nm-openvpn[6728]: Preserving previous TUN/TAP instance: tun0
Jan 15 09:10:26 dib nm-openvpn[6728]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.46 10.22.248.45 restart
Jan 15 09:10:26 dib nm-openvpn[6728]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Jan 15 09:10:27 dib nm-openvpn[6728]: TUN/TAP device tun0 opened
Jan 15 09:10:27 dib nm-openvpn[6728]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.134 10.22.248.133 init
Jan 15 09:10:27 dib nm-openvpn[6728]: Initialization Sequence Completed
Jan 15 09:16:20 dib nm-openvpn[6728]: SIGTERM[hard,] received, process exiting
Jan 15 09:16:23 dib nm-openvpn[8458]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Jan 15 09:16:23 dib nm-openvpn[8458]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 15 09:16:23 dib nm-openvpn[8458]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 09:16:23 dib nm-openvpn[8458]: WARNING: file '/home/bhearsum/vpn/key.key' is group or others accessible
Jan 15 09:16:23 dib nm-openvpn[8458]: WARNING: file '/home/bhearsum/vpn/ta.key' is group or others accessible
Jan 15 09:16:23 dib nm-openvpn[8458]: Control Channel Authentication: using '/home/bhearsum/vpn/ta.key' as a OpenVPN static key file
Jan 15 09:16:23 dib nm-openvpn[8458]: UDPv4 link local: [undef]
Jan 15 09:16:23 dib nm-openvpn[8458]: UDPv4 link remote: [AF_INET]63.245.214.137:1194
Jan 15 09:16:25 dib nm-openvpn[8458]: [openvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.137:1194
Jan 15 09:16:28 dib nm-openvpn[8458]: TUN/TAP device tun0 opened
Jan 15 09:16:28 dib nm-openvpn[8458]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.138 10.22.248.137 init
Jan 15 09:16:28 dib nm-openvpn[8458]: Initialization Sequence Completed
Jan 15 09:30:22 dib nm-openvpn[8458]: [openvpn.scl3.mozilla.com] Inactivity timeout (--ping-restart), restarting
Jan 15 09:30:22 dib nm-openvpn[8458]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 09:30:24 dib nm-openvpn[8458]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 15 09:30:24 dib nm-openvpn[8458]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 09:30:24 dib nm-openvpn[8458]: UDPv4 link local: [undef]
Jan 15 09:30:24 dib nm-openvpn[8458]: UDPv4 link remote: [AF_INET]63.245.214.137:1194
Jan 15 09:30:26 dib nm-openvpn[8458]: [openvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.137:1194
Jan 15 09:30:28 dib nm-openvpn[8458]: Preserving previous TUN/TAP instance: tun0
Jan 15 09:30:28 dib nm-openvpn[8458]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.138 10.22.248.137 restart
Jan 15 09:30:28 dib nm-openvpn[8458]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Jan 15 09:30:29 dib nm-openvpn[8458]: TUN/TAP device tun0 opened
Jan 15 09:30:29 dib nm-openvpn[8458]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.14 10.22.248.13 init
Jan 15 09:30:29 dib nm-openvpn[8458]: Initialization Sequence Completed
Jan 15 09:37:18 dib nm-openvpn[8458]: SIGTERM[hard,] received, process exiting
Jan 15 09:37:20 dib nm-openvpn[8910]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Jan 15 09:37:21 dib nm-openvpn[8910]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 15 09:37:21 dib nm-openvpn[8910]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 09:37:21 dib nm-openvpn[8910]: WARNING: file '/home/bhearsum/vpn/key.key' is group or others accessible
Jan 15 09:37:21 dib nm-openvpn[8910]: WARNING: file '/home/bhearsum/vpn/ta.key' is group or others accessible
Jan 15 09:37:21 dib nm-openvpn[8910]: Control Channel Authentication: using '/home/bhearsum/vpn/ta.key' as a OpenVPN static key file
Jan 15 09:37:21 dib nm-openvpn[8910]: UDPv4 link local: [undef]
Jan 15 09:37:21 dib nm-openvpn[8910]: UDPv4 link remote: [AF_INET]63.245.214.137:1194
Jan 15 09:37:23 dib nm-openvpn[8910]: [openvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.137:1194
Jan 15 09:37:25 dib nm-openvpn[8910]: TUN/TAP device tun0 opened
Jan 15 09:37:25 dib nm-openvpn[8910]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1558 10.22.248.138 10.22.248.137 init
Jan 15 09:37:25 dib nm-openvpn[8910]: Initialization Sequence Completed
I know Chris and Rail have been hitting this as well.
| Reporter | ||
Comment 2•11 years ago
|
||
Here's what I get when I export it from NetworkManager:
client
remote 63.245.214.137
ca /home/bhearsum/vpn/ca.crt
cert /home/bhearsum/vpn/cert.crt
key /home/bhearsum/vpn/key.key
auth-user-pass
cipher AES-256-CBC
comp-lzo yes
dev tun
proto udp
tls-auth /home/bhearsum/vpn/ta.key 1
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nobody
group nogroup
Comment 3•11 years ago
|
||
Can you please try adding the following line to your config and retesting?:
reneg-sec 0
Also, change "comp-lzo" to "no" - I doubt it makes much of a difference in any regard, but my config has it set to no and I've seen "yes" cause bizarre problems before.
| Reporter | ||
Comment 4•11 years ago
|
||
(In reply to Dan Parsons [:lerxst] from comment #3)
> Can you please try adding the following line to your config and retesting?:
>
> reneg-sec 0
>
> Also, change "comp-lzo" to "no" - I doubt it makes much of a difference in
> any regard, but my config has it set to no and I've seen "yes" cause bizarre
> problems before.
I just added that, I'll see how it goes next week.
| Reporter | ||
Comment 5•11 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #4)
> (In reply to Dan Parsons [:lerxst] from comment #3)
> > Can you please try adding the following line to your config and retesting?:
> >
> > reneg-sec 0
> >
> > Also, change "comp-lzo" to "no" - I doubt it makes much of a difference in
> > any regard, but my config has it set to no and I've seen "yes" cause bizarre
> > problems before.
>
> I just added that, I'll see how it goes next week.
Unfortunately, it didn't help.
as per https://www.yammer.com/mozilla.com/#/Threads/show?threadId=486619113 switching to TCP seems to help. It looks like the UDP packets are dropped after some time, or too many are lost or something like that.
Looking at logs it seems like there has been no renegotiation started and the current session is the one that time out (detected by the keep-alive). In addition to that, Network Manager doesn't auto-reconnect (it doesn't support that feature for openvpn yet AFAIK).
There's some work-arounds when auto-reconnect is needed such as https://bbs.archlinux.org/viewtopic.php?id=107509 (albeit it's not all that useful when/if using MFA since it will ask for the 2nd authentication token upon reconnect)
| Reporter | ||
Comment 7•11 years ago
|
||
(In reply to Guillaume Destuynder [:kang] from comment #6)
> as per https://www.yammer.com/mozilla.com/#/Threads/show?threadId=486619113
> switching to TCP seems to help. It looks like the UDP packets are dropped
> after some time, or too many are lost or something like that.
I got my first drop with TCP today actually :(. I'm willing to write that off as a freak occurence if it doesn't happen again though.
| Assignee | ||
Comment 8•10 years ago
|
||
Is this still occurring? We've had a few changes and updates since the last comment on this bug. I personally cannot reproduce, as I regularly go 30 days on a single connection (and then only get dropped because I need to re-auth with MFA).
Assignee: dparsons → jdow
Flags: needinfo?(bhearsum)
QA Contact: dparsons → jdow
| Reporter | ||
Comment 9•10 years ago
|
||
I've been off for a bit so it's hard to say. I'll have a better idea in a few weeks time. Let's resolve for now and re-open if it continues to be an issue...
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(bhearsum)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•