Tunnelblick looks for reauthorisation on the hour with problems

ymmij

unread,

Nov 15, 2014, 6:47:44 PM11/15/14

to

Running OpenVPN and client of VPN in Touch.

After 1 hour of running the info window displays “Waiting for password”

VPN appears to still be working, but the dialog box remains.

In the log there is a message at 10:03:21 that the TLS keys are out of sync.

Can this hourly check be overwritten, and is this TLS message a problem/

Thanks

*Tunnelblick: OS X 10.9.5; Tunnelblick 3.4.1 (build 4054); prior version 3.4.0 (build 4007); Admin user

"Sanitized" condensed configuration file for /Users/xxxxxxxxx/Library/Application Support/Tunnelblick/Configurations/VIT_US.tblk:

client

dev tun

proto udp

remote us.vpnintouch.biz 7168

resolv-retry infinite

nobind

persist-key

persist-tun

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

auth-user-pass

ns-cert-type server

comp-lzo

verb 3

auth-nocache

================================================================================

"Sanitized" full configuration file

##############################################

# Sample client-side OpenVPN 2.0 config file #

# for connecting to multi-client server. #

# #

# This configuration can be used by multiple #

# clients, however each client should have #

# its own cert and key files. #

# #

# On Windows, you might want to rename this #

# file so it has a .ovpn extension #

##############################################

# Specify that we are a client and that we

# will be pulling certain config file directives

# from the server.

client

# Use the same setting as you are using on

# the server.

# On most systems, the VPN will not function

# unless you partially or fully disable

# the firewall for the TUN/TAP interface.

;dev tap

dev tun

# Windows needs the TAP-Win32 adapter name

# from the Network Connections panel

# if you have more than one. On XP SP2,

# you may need to disable the firewall

# for the TAP adapter.

;dev-node MyTap

# Are we connecting to a TCP or

# UDP server? Use the same setting as

# on the server.

proto udp

;proto udp

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

remote us.vpnintouch.biz 7168

;remote my-server-2 1194

# Choose a random host from the remote

# list for load-balancing. Otherwise

# try hosts in the order specified.

;remote-random

# Keep trying indefinitely to resolve the

# host name of the OpenVPN server. Very useful

# on machines which are not permanently connected

# to the internet such as laptops.

resolv-retry infinite

#resolv-retry 2

# Most clients don't need to bind to

# a specific local port number.

nobind

# Downgrade privileges after initialization (non-Windows only)

;user nobody

;group nogroup

# Try to preserve some state across restarts.

persist-key

persist-tun

# If you are connecting through an

# HTTP proxy to reach the actual OpenVPN

# server, put the proxy server/IP and

# port number here. See the man page

# if your proxy server requires

# authentication.

# http-proxy-retry # retry on connection failures

; http-proxy 127.0.0.1 8080

; http-proxy 98.158.188.59 3128

;http-proxy 127.0.0.1 8080

;up.txt

; stdin

# Wireless networks often produce a lot

# of duplicate packets. Set this flag

# to silence duplicate packet warnings.

;mute-replay-warnings

# SSL/TLS parms.

# See the server config file for more

# description. It's best to use

# a separate .crt/.key file pair

# for each client. A single ca

# file can be used for all clients.

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

# Verify server certificate by checking

# that the certicate has the nsCertType

# field set to "server". This is an

# important precaution to protect against

# a potential attack discussed here:

# http://openvpn.net/howto.html#mitm

#

auth-user-pass

# To use this feature, you will need to generate

# your server certificates with the nsCertType

# field set to "server". The build-key-server

# script in the easy-rsa folder will do this.

ns-cert-type server

# If a tls-auth key is used on the server

# then every client must also have the key.

;tls-auth ta.key 1

# Select a cryptographic cipher.

# If the cipher option is used on the server

# then you must also specify it here.

;cipher x

# Enable compression on the VPN link.

# Don't enable this unless it is also

# enabled in the server config file.

comp-lzo

# Set log file verbosity.

verb 3

#auth-user-pass

auth-nocache

#fast-io

#pull

#route-delay 2

#redirect-gateway

# Silence repeating messages

;mute 20

================================================================================

There are no unusual files in VIT_US.tblk

================================================================================

Configuration preferences:

useDNS = 2

-routeAllTrafficThroughVpn = 1

-keychainHasUsernameAndPassword = 1

-keepConnected = 1

-lastConnectionSucceeded = 1

-tunnelDownSoundName = Speak

-doNotShowOnTunnelblickMenu = 0

================================================================================

Wildcard preferences:

================================================================================

Program preferences:

inhibitOutboundTunneblickTraffic = 1

placeIconInStandardPositionInStatusBar = 0

launchAtNextLogin = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

"3.4.1 (build 4054)",

"3.4.0 (build 4007)",

"3.4beta38 (build 4002)",

"3.4beta36 (build 3945)",

"3.4beta34 (build 3935)"

)

statusDisplayNumber = 69501177

lastLaunchTime = 437704252.4753

showConnectedDurations = 0

connectionWindowDisplayCriteria = showWhenChanges

maxLogDisplaySize = 102400

lastConnectedDisplayName = VIT_US

installationUID (not shown)

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateCheckBetas = 1

updateSendProfileInfo = 1

NSWindow Frame SettingsSheetWindow = 996 308 829 424 0 0 2560 1418

NSWindow Frame ConnectingWindow = 1085 924 389 187 0 0 2560 1418

NSWindow Frame SUStatusFrame = 1088 967 384 129 0 0 2560 1418

detailsWindowFrameVersion = 4054

detailsWindowFrame = {{505, 159}, {1860, 990}}

detailsWindowLeftFrame = {{0, 0}, {349, 872}}

leftNavSelectedDisplayName = VIT_US

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

haveDealtWithOldLoginItem = 1

SUEnableAutomaticChecks = 0

SUFeedURL = https://www.tunnelblick.net/appcast-b.rss

SUScheduledCheckInterval = 86400

SUSendProfileInfo = 1

SULastCheckTime = 2014-11-15 00:30:51 +0000

SULastProfileSubmissionDate = 2014-11-08 23:46:01 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 11

WebKitStandardFont = Lucida Grande

================================================================================

Tunnelblick Log:

2014-11-16 09:33:14 *Tunnelblick: openvpnstart starting OpenVPN

2014-11-16 09:33:14 *Tunnelblick: OS X 10.9.5; Tunnelblick 3.4.1 (build 4054); prior version 3.4.0 (build 4007)

2014-11-16 09:33:14 *Tunnelblick: Attempting connection with VIT_US using shadow copy; Set nameserver = 5; monitoring connection

2014-11-16 09:33:14 *Tunnelblick: openvpnstart start VIT_US.tblk 1337 5 0 1 0 17200 -ptADGNWradsgnw 2.3.4

2014-11-16 09:33:15 *Tunnelblick: openvpnstart log:

Tunnelblick:

OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.4/openvpn

--daemon

--log

/Library/Application Support/Tunnelblick/Logs/-SUsers-Sxxxxxxxxx-SLibrary-SApplication Support-STunnelblick-SConfigurations-SVIT_US.tblk-SContents-SResources-Sconfig.ovpn.5_0_1_0_17200.1337.openvpn.log

--cd

/Library/Application Support/Tunnelblick/Users/xxxxxxxxx/VIT_US.tblk/Contents/Resources

--config

/Library/Application Support/Tunnelblick/Users/xxxxxxxxx/VIT_US.tblk/Contents/Resources/config.ovpn

--cd

/Library/Application Support/Tunnelblick/Users/xxxxxxxxx/VIT_US.tblk/Contents/Resources

--management

127.0.0.1

1337

--management-query-passwords

--management-hold

--redirect-gateway

def1

--script-security

2

--up

/Applications/Tunnelblick.app/Contents/Resources/client.1.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw

--down

/Applications/Tunnelblick.app/Contents/Resources/client.1.down.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw

2014-11-16 09:33:15 *Tunnelblick: Established communication with OpenVPN

2014-11-16 09:33:15 *Tunnelblick: Obtained VPN username and password from the Keychain

2014-11-16 09:33:15 OpenVPN 2.3.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Oct 15 2014

2014-11-16 09:33:15 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08

2014-11-16 09:33:15 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2014-11-16 09:33:15 Need hold release from management interface, waiting...

2014-11-16 09:33:15 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2014-11-16 09:33:15 MANAGEMENT: CMD 'pid'

2014-11-16 09:33:15 MANAGEMENT: CMD 'state on'

2014-11-16 09:33:15 MANAGEMENT: CMD 'state'

2014-11-16 09:33:15 MANAGEMENT: CMD 'bytecount 1'

2014-11-16 09:33:15 MANAGEMENT: CMD 'hold release'

2014-11-16 09:33:15 MANAGEMENT: CMD 'username "Auth" “xx...@xxxxx.com"'

2014-11-16 09:33:15 MANAGEMENT: CMD 'password [...]'

2014-11-16 09:33:15 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2014-11-16 09:33:15 Socket Buffers: R=[196724->65536] S=[9216->65536]

2014-11-16 09:33:15 MANAGEMENT: >STATE:1416090795,RESOLVE,,,

2014-11-16 09:33:15 UDPv4 link local: [undef]

2014-11-16 09:33:15 UDPv4 link remote: [AF_INET]206.217.196.129:7168

2014-11-16 09:33:15 MANAGEMENT: >STATE:1416090795,WAIT,,,

2014-11-16 09:33:15 MANAGEMENT: >STATE:1416090795,AUTH,,,

2014-11-16 09:33:15 TLS: Initial packet from [AF_INET]206.217.196.129:7168, sid=f797654c 8cb531d0

2014-11-16 09:33:17 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=shadi, name=changeme, emailAddress=ma...@host.domain

2014-11-16 09:33:17 VERIFY OK: nsCertType=SERVER

2014-11-16 09:33:17 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=server, name=changeme, emailAddress=ma...@host.domain

2014-11-16 09:33:17 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

2014-11-16 09:33:17 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-11-16 09:33:17 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

2014-11-16 09:33:17 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-11-16 09:33:17 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

2014-11-16 09:33:17 [server] Peer Connection Initiated with [AF_INET]206.217.196.129:7168

2014-11-16 09:33:19 MANAGEMENT: >STATE:1416090799,GET_CONFIG,,,

2014-11-16 09:33:20 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

2014-11-16 09:33:20 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.15.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.15.62.186 10.15.62.185'

2014-11-16 09:33:20 OPTIONS IMPORT: timers and/or timeouts modified

2014-11-16 09:33:20 OPTIONS IMPORT: --ifconfig/up options modified

2014-11-16 09:33:20 OPTIONS IMPORT: route options modified

2014-11-16 09:33:20 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2014-11-16 09:33:20 Opened utun device utun0

2014-11-16 09:33:20 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

2014-11-16 09:33:20 MANAGEMENT: >STATE:1416090800,ASSIGN_IP,,10.15.62.186,

2014-11-16 09:33:20 /sbin/ifconfig utun0 delete

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2014-11-16 09:33:20 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2014-11-16 09:33:20 /sbin/ifconfig utun0 10.15.62.186 10.15.62.185 mtu 1500 netmask 255.255.255.255 up

2014-11-16 09:33:20 /Applications/Tunnelblick.app/Contents/Resources/client.1.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw utun0 1500 1542 10.15.62.186 10.15.62.185 init

2014-11-16 09:33:20 *Tunnelblick: No 'connected.sh' script to execute

2014-11-16 09:33:20 /sbin/route add -net 206.217.196.129 10.1.1.1 255.255.255.255

add net 206.217.196.129: gateway 10.1.1.1

2014-11-16 09:33:20 /sbin/route add -net 0.0.0.0 10.15.62.185 128.0.0.0

add net 0.0.0.0: gateway 10.15.62.185

2014-11-16 09:33:20 /sbin/route add -net 128.0.0.0 10.15.62.185 128.0.0.0

add net 128.0.0.0: gateway 10.15.62.185

2014-11-16 09:33:20 MANAGEMENT: >STATE:1416090800,ADD_ROUTES,,,

2014-11-16 09:33:20 /sbin/route add -net 10.15.0.1 10.15.62.185 255.255.255.255

add net 10.15.0.1: gateway 10.15.62.185

2014-11-16 09:33:20 Initialization Sequence Completed

2014-11-16 09:33:20 MANAGEMENT: >STATE:1416090800,CONNECTED,SUCCESS,10.15.62.186,206.217.196.129

2014-11-16 10:03:21 TLS Error: local/remote TLS keys are out of sync: [AF_INET]206.217.196.129:7168 [2]

2014-11-16 10:33:17 TLS: soft reset sec=0 bytes=162523173/0 pkts=193620/0

2014-11-16 10:33:17 MANAGEMENT: CMD 'username "Auth" “xx...@xxxx.com"'

2014-11-16 10:33:17 MANAGEMENT: CMD 'password [...]'

2014-11-16 10:33:19 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=shadi, name=changeme, emailAddress=ma...@host.domain

2014-11-16 10:33:19 VERIFY OK: nsCertType=SERVER

2014-11-16 10:33:19 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=server, name=changeme, emailAddress=ma...@host.domain

2014-11-16 10:33:19 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

2014-11-16 10:33:19 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-11-16 10:33:19 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

2014-11-16 10:33:19 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-11-16 10:33:19 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

================================================================================

Console Log:

2014-11-16 04:35:09 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 04:35:09 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 05:35:11 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 05:35:11 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 06:35:13 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 06:35:13 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 07:35:16 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 07:35:16 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 08:35:18 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 08:35:18 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 09:33:15 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 09:33:15 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

2014-11-16 10:33:17 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'username'

2014-11-16 10:33:17 Tunnelblick[738] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-VIT_US' account = 'password'

================================================================================

Non-Apple kexts that are loaded:

Index Refs Address Size Wired Name (Version) <Linked Against>

56 0 0xffffff7f80dc4000 0x48000 0x48000 at.obdev.nke.LittleSnitch (4228) <5 4 3 1>

84 0 0xffffff7f80f56000 0x7000 0x7000 com.AmbrosiaSW.AudioSupport (4.1.2) <83 5 4 3 1>

103 1 0xffffff7f819b7000 0x8000 0x8000 com.avatron.AVExVideo (1.7) <85 5 4 3>

118 0 0xffffff7f81aee000 0x5000 0x5000 com.logmein.driver.LogMeInSoundDriver (4.1.46f67) <83 5 4 3>

119 0 0xffffff7f81af3000 0x5000 0x5000 com.Cycling74.driver.Soundflower (1.5.3) <83 5 4 3>

120 0 0xffffff7f81af8000 0x5000 0x5000 net.telestream.driver.TelestreamAudio (1.0.5) <83 5 4 3 1>

121 0 0xffffff7f81afd000 0x4000 0x4000 com.vara.driver.VaraAudio (1.0.3) <83 5 4 3 1>

122 0 0xffffff7f81b01000 0x5000 0x5000 com.wavtap.driver.WavTap (0.4.0) <83 5 4 3>

123 0 0xffffff7f81b06000 0x5000 0x5000 com.avatron.AVExFramebuffer (1.7) <103 85 5 4 3>

jkbull...gmail.com

unread,

Nov 16, 2014, 12:38:51 AM11/16/14

to tunnelbli...@googlegroups.com

You should contact "VP In Touch". They are your VPN service provider -- the organization which gave you your configuration files, and perhaps a username and password. For more information, please see Getting VPN Service.

Tunnelblick is just the free software that many VPN service providers recommend or supply to their customers. We do not provide VPN service, just software.

tao...@gmail.com

unread,

Nov 28, 2014, 8:53:36 PM11/28/14

to tunnelbli...@googlegroups.com

I'm having the same problem. My VPN service provider has so far been useless on this issue. I had a perfectly good working version, then I got the "upgrade", and now my system gets twitchy every hour. The latest email from them contained an offer of a refund (!). That was not acceptable. I paid for your service, you worked fine, you send me an upgrade, and now it doesn't work so well.

Any suggestions as to where I might look to solve my own problem would be appreciated.

...

jkbull...gmail.com

unread,

Nov 28, 2014, 11:11:18 PM11/28/14

to tunnelbli...@googlegroups.com, tao...@gmail.com

On Friday, November 28, 2014 8:53:36 PM UTC-5, tao...@gmail.com wrote:

I'm having the same problem.

It may or may not be "the same problem". It's impossible to know because you didn't provide any diagnostic information (see Read Before You Post).

My VPN service provider has so far been useless on this issue.

Who is your VPN service provider? Name them and shame them!

I had a perfectly good working version, then I got the "upgrade", and now my system gets twitchy every hour. The latest email from them contained an offer of a refund (!). That was not acceptable.

What upgrade do you mean? An upgrade to OS X? An upgrade from your VPN service provider? An upgrade of Tunnelblick?

What does "gets twitchy" mean?

I paid for your service, you worked fine, you send me an upgrade, and now it doesn't work so well.

Let's be clear. The "you" you are referring to is your VPN service provider, not the Tunnelblick project. The Tunnelblick project has nothing to do with VPN service providers other than

Doing consulting work for some VPN service providers;
Accepting donations from some VPN service providers (and anyone else);
Listing many of them on Tunnelblick's Getting VPN Service page; and
Having our software used or recommended by them.

Any suggestions as to where I might look to solve my own problem would be appreciated.

Can't help much without diagnostic information.

...

moonli...@gmail.com

unread,

Aug 12, 2015, 2:36:37 PM8/12/15

to tunnelblick-discuss

I have recently joined tigerVPN and started experiencing a similar issue. After being connected for one hour the traffic stops and about two minutes after that the VPN does a full disconnect/connect sequence.

tigerVPN believes the issue is caused by the regen-sync parameter. They set regen-sync = 0, which they say means never disconnect, and believe tunnelblick is misinterpreting the parameter to reconnect every hour.

tigerVPNs fix is to change regen-sync = 10 days, but if they are correct about the cause I believe it can and should be fixed in an upcoming tunnelblick release.

jkbull...gmail.com

unread,

Aug 12, 2015, 3:16:21 PM8/12/15

to tunnelblick-discuss, moonli...@gmail.com

It isn't Tunnelblick doing the renegotiation, it's OpenVPN. Tunnelblick is a GUI for OpenVPN.
"regen-sync" is not an OpenVPN parameter (or a Tunnelblick parameter, for that matter). A quick Internet search did not reveal any references to "regen-sync" that had anything to do with OpenVPN.
The renegotiations are controlled by the OpenVPN "--reneg-bytes", "--reneg-pkts", and/or "--reneg-sec" options, so I assume that is what TigerVPN is referring to.
However, what TigerVPN describes as the solution will only work if their server is set up with a --reneg-sec of 0. The OpenVPN man page (see below) says that that setting it to 0 on the client (your computer) has no practical effect if they are not set to 0 on the server.
From your description, I would guess that the VPN is configured incorrectly; the "traffic stop" after one hour is not normal, even if a renegotiation is taking place. However, since you did not follow the instructions in Read Before You Post, I can't be more precise.

From the OpenVPN 2.3 man page:

--reneg-bytes n
Renegotiate data channel key after n bytes sent or received (disabled by default). OpenVPN allows the lifetime of a key to be expressed as a number of bytes encrypted/decrypted, a number of packets, or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer.

--reneg-pkts n
Renegotiate data channel key after n packets sent and received (disabled by default).

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

Reply all

Reply to author

Forward