[win 7 x64 client] Ping required after location is changed

petka82

Hello,

I've got the following problem with my client. VPN connection works allright until I put my laptop asleep, and change my location. When I am in a new location I reconnect my VPN client and even if it says that "the client is connected", my samba drives won't work until I will go to the command line and ping the internal VPN server.

After I run the ping, I can access my mapped drives on my computer.

Why it is like that?

Peter

george

I'm guessing this is due to inactivity on the VPN tunnel. Try disconnecting before putting your laptop to sleep, and reconnecting after you are at the new location.

hamzen

When will be this error corrected in OpenVPN client / service?
Whenever a win7 user clicks sleep or hibernate or simply closing down the laptop, or because the laptop runs from battery and goes to sleep mode automatically >
the client does not connect back properly when waking up !

The Users do not have admin privileges, (to restart the service,) so:
I have to force every each user every each time to close and save everything manually, and restart the whole laptop, whenever this happens ! (and this can happen every 5 minutes a laptop isn't plugged in and not used, because of the advanced energy saving mode of Win7).

Very annoying getting 5-10 phone calls pro day because of this 🙁

Mimiko

Use "keepalive" option in clients config file, to keep the channel up, or restart it when the ping fails.

hamzen

Mimiko wroteUse "keepalive" option in clients config file, to keep the channel up, or restart it when the ping fails.

Thanks, I will try that !
is it possible to change/force this on server side too? (it would take too much work to edit hundreds of clients one by one...)

Mimiko

Use

push "ping x"
push "ping-restart y"

in your server's config, where x and y are number of seconds.
But first try

push "keepalive x y"

I am not sure if this is pushed in new versions of OpenVPN.

hamzen

keepalive 10 120

is already set up to the server.
It seems there are many similar topics and an unsolved ticket about this problem:
http://forums.openvpn.net/topic7622.html

Mimiko

keepalive 10 120
is already set up to the server.

This parameter set on server affects only server, not the clients.

The link you provided adresses different question.

hamzen

keepalive 10 120

this wonder-code helped me a lot. MANY THANKS ! Much better reconnection after W7 sleep mode. I've tested this in the last couple month.

So if I understand it right...
on the server >

keepalive 10 120

forced to reconnect on the server side and it should be :

push "keepalive 10 120"

. So it will "push" that setup down to the client?

Mimiko

Yes, but Im not sure if push keepalive works, so add keepalive option to client's config file.

janjust

from the manual page:

keepalive 10 60

translates to

if mode server:
   ping 10
   ping-restart 120
   push "ping 10"
   push "ping-restart 60"
 else
   ping 10
   ping-restart 60

nothing more, nothing less; so there's no need to do a 'push keepalive'

hamzen

Sadly I have to take back everything about "it works now" ... 🙁
The problem still exists.

I was able to get a log from a machine that stopped connecting. And this is a perfect example about the "randomity" of the case it happens. (Because there are 2, exactly same machines on that same subnet, and one was still connected, but the other not.)

Thu Nov 10 06:26:36 2011 NOTE: --user option is not implemented on Windows
Thu Nov 10 06:26:36 2011 NOTE: --group option is not implemented on Windows
Thu Nov 10 06:26:36 2011 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov  8 2010
Thu Nov 10 06:26:36 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Nov 10 06:26:36 2011 Control Channel Authentication: using 'Manuel_ta.key' as a OpenVPN static key file
Thu Nov 10 06:26:36 2011 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 06:26:36 2011 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 06:26:36 2011 LZO compression initialized
Thu Nov 10 06:26:36 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Nov 10 06:26:36 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Nov 10 06:26:36 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 06:26:36 2011 Local Options hash (VER=V4): '504e774e'
Thu Nov 10 06:26:36 2011 Expected Remote Options hash (VER=V4): '14168603'
Thu Nov 10 06:26:36 2011 UDPv4 link local: [undef]
Thu Nov 10 06:26:36 2011 UDPv4 link remote: 88.151.100.226:1247
Thu Nov 10 06:26:36 2011 TLS: Initial packet from 88.151.100.226:1247, sid=9e2deabc 05ca55f8
Thu Nov 10 06:26:36 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 06:26:36 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 06:26:36 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 06:26:36 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 06:26:36 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 06:26:36 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 06:26:36 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 06:26:36 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 06:26:36 2011 [vpn1247.viponline.choma.hu] Peer Connection Initiated with 88.151.100.226:1247
Thu Nov 10 06:26:39 2011 SENT CONTROL [vpn1247.viponline.choma.hu]: 'PUSH_REQUEST' (status=1)
Thu Nov 10 06:26:39 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.8.52.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.52.14 10.8.52.13'
Thu Nov 10 06:26:39 2011 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 10 06:26:39 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 10 06:26:39 2011 OPTIONS IMPORT: route options modified
Thu Nov 10 06:26:39 2011 ROUTE default_gateway=192.168.0.1
Thu Nov 10 06:26:39 2011 TAP-WIN32 device [VPN_pcpincer] opened: \\.\Global\{E66402D5-7612-4D0F-AE13-5809F8E7FA48}.tap
Thu Nov 10 06:26:39 2011 TAP-Win32 Driver Version 9.7 
Thu Nov 10 06:26:39 2011 TAP-Win32 MTU=1500
Thu Nov 10 06:26:39 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.52.14/255.255.255.252 on interface {E66402D5-7612-4D0F-AE13-5809F8E7FA48} [DHCP-serv: 10.8.52.13, lease-time: 31536000]
Thu Nov 10 06:26:39 2011 Successful ARP Flush on interface [14] {E66402D5-7612-4D0F-AE13-5809F8E7FA48}
Thu Nov 10 06:26:44 2011 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Thu Nov 10 06:26:44 2011 C:\WINDOWS\system32\route.exe ADD 10.8.52.0 MASK 255.255.255.0 10.8.52.13
Thu Nov 10 06:26:44 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu Nov 10 06:26:44 2011 Route addition via IPAPI succeeded [adaptive]
Thu Nov 10 06:26:44 2011 Initialization Sequence Completed
Thu Nov 10 07:06:40 2011 [vpn1247.viponline.choma.hu] Inactivity timeout (--ping-restart), restarting
Thu Nov 10 07:06:40 2011 TCP/UDP: Closing socket
Thu Nov 10 07:06:40 2011 SIGUSR1[soft,ping-restart] received, process restarting
Thu Nov 10 07:06:40 2011 Restart pause, 2 second(s)
Thu Nov 10 07:06:42 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Nov 10 07:06:42 2011 Re-using SSL/TLS context
Thu Nov 10 07:06:43 2011 LZO compression initialized
Thu Nov 10 07:06:43 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Nov 10 07:06:43 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Nov 10 07:06:46 2011 RESOLVE: Cannot resolve host address: vpn.pcpincer.hu: [NO_DATA] The requested name is valid but does not have an IP address.
Thu Nov 10 07:06:46 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 07:06:46 2011 Local Options hash (VER=V4): '504e774e'
Thu Nov 10 07:06:46 2011 Expected Remote Options hash (VER=V4): '14168603'
Thu Nov 10 07:06:48 2011 RESOLVE: Cannot resolve host address: vpn.pcpincer.hu: [NO_DATA] The requested name is valid but does not have an IP address.
Thu Nov 10 07:06:48 2011 TCP/UDP: Closing socket
Thu Nov 10 07:06:48 2011 SIGUSR1[soft,init_instance] received, process restarting
Thu Nov 10 07:06:48 2011 Restart pause, 2 second(s)
Thu Nov 10 07:06:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Nov 10 07:06:50 2011 Re-using SSL/TLS context
Thu Nov 10 07:06:50 2011 LZO compression initialized
Thu Nov 10 07:06:50 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Nov 10 07:06:50 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Nov 10 07:06:50 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 07:06:50 2011 Local Options hash (VER=V4): '504e774e'
Thu Nov 10 07:06:50 2011 Expected Remote Options hash (VER=V4): '14168603'
Thu Nov 10 07:06:50 2011 UDPv4 link local: [undef]
Thu Nov 10 07:06:50 2011 UDPv4 link remote: 88.151.100.226:1247
Thu Nov 10 07:06:50 2011 TLS: Initial packet from 88.151.100.226:1247, sid=8855cf1b 3c82c55f
Thu Nov 10 07:06:50 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 07:06:50 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 07:06:50 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 07:06:50 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 07:06:50 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 07:06:50 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 07:06:50 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 07:06:50 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 07:06:50 2011 [vpn1247.viponline.choma.hu] Peer Connection Initiated with 88.151.100.226:1247
Thu Nov 10 07:06:52 2011 SENT CONTROL [vpn1247.viponline.choma.hu]: 'PUSH_REQUEST' (status=1)
Thu Nov 10 07:06:52 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.8.52.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.52.14 10.8.52.13'
Thu Nov 10 07:06:52 2011 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 10 07:06:52 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 10 07:06:52 2011 OPTIONS IMPORT: route options modified
Thu Nov 10 07:06:52 2011 Preserving previous TUN/TAP instance: VPN_pcpincer
Thu Nov 10 07:06:52 2011 Initialization Sequence Completed
Thu Nov 10 08:06:50 2011 TLS: soft reset sec=0 bytes=37380/0 pkts=712/0
Thu Nov 10 08:06:50 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 08:06:50 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 08:06:50 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 08:06:50 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 08:06:50 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 08:06:50 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 08:06:50 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 08:06:50 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 08:48:02 2011 [vpn1247.viponline.choma.hu] Inactivity timeout (--ping-restart), restarting
Thu Nov 10 08:48:02 2011 TCP/UDP: Closing socket
Thu Nov 10 08:48:09 2011 SIGUSR1[soft,ping-restart] received, process restarting
Thu Nov 10 08:48:09 2011 Restart pause, 2 second(s)
Thu Nov 10 08:48:11 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Nov 10 08:48:11 2011 Re-using SSL/TLS context
Thu Nov 10 08:48:11 2011 LZO compression initialized
Thu Nov 10 08:48:11 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Nov 10 08:48:11 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Nov 10 08:48:12 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 08:48:12 2011 Local Options hash (VER=V4): '504e774e'
Thu Nov 10 08:48:12 2011 Expected Remote Options hash (VER=V4): '14168603'
Thu Nov 10 08:48:12 2011 UDPv4 link local: [undef]
Thu Nov 10 08:48:12 2011 UDPv4 link remote: 88.151.100.226:1247
Thu Nov 10 08:48:12 2011 TLS: Initial packet from 88.151.100.226:1247, sid=4cb2eccc 31f14777
Thu Nov 10 08:48:12 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 08:48:12 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 08:48:12 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 08:48:12 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 08:48:12 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 08:48:12 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 08:48:12 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 08:48:12 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 08:48:12 2011 [vpn1247.viponline.choma.hu] Peer Connection Initiated with 88.151.100.226:1247
Thu Nov 10 08:48:15 2011 SENT CONTROL [vpn1247.viponline.choma.hu]: 'PUSH_REQUEST' (status=1)
Thu Nov 10 08:48:15 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.8.52.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.52.14 10.8.52.13'
Thu Nov 10 08:48:15 2011 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 10 08:48:15 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 10 08:48:15 2011 OPTIONS IMPORT: route options modified
Thu Nov 10 08:48:15 2011 Preserving previous TUN/TAP instance: VPN_pcpincer
Thu Nov 10 08:48:15 2011 Initialization Sequence Completed
Thu Nov 10 09:48:12 2011 TLS: soft reset sec=0 bytes=37326/0 pkts=711/0
Thu Nov 10 09:48:13 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 09:48:13 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 09:48:13 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 09:48:13 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 09:48:13 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 09:48:13 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 09:48:13 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 09:48:13 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 10:48:13 2011 VERIFY OK: depth=1, /C=HU/ST=Budapest/L=BUDAPEST/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 10:48:13 2011 VERIFY OK: nsCertType=SERVER
Thu Nov 10 10:48:13 2011 VERIFY OK: depth=0, /C=HU/ST=Budapest/O=Choma_Co./CN=vpn1247.viponline.choma.hu/emailAddress=info@choma.hu
Thu Nov 10 10:48:13 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 10:48:13 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 10:48:13 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 10 10:48:13 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 10:48:13 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

... and the log stops here. The file modification time was Thu Nov 10 10:48:13 2011
The TAP did not get an IP address (169. ...)
Theoretically all energy-saving policy is turned off.

Thanks for all the help !

Mimiko

On the problem system check for antivurus or firewalls that interfere with the connection. Disable them for testing purposes. Also reinstall OpenVPN.

janjust

this actually looks like a DNS issue:

RESOLVE: Cannot resolve host address: vpn.pcpincer.hu: [NO_DATA] The requested name is valid but does not have an IP address.

what are the DNS settings on the working and non-working client?

hamzen

janjust wrotethis actually looks like a DNS issue:
RESOLVE: Cannot resolve host address: vpn.pcpincer.hu: [NO_DATA] The requested name is valid but does not have an IP address.
what are the DNS settings on the working and non-working client?

I'm afraid you may missed something... a few lines later it connected well, what means it was only a small internet break > and that proves too, that everything is set up well.

The DNS settings are the same on both machines. DHCP got from a router. Internet works, TeamViewer works, OpenVPN is working and working for hours... and suddenly it stops working after a 1-hour soft reset. (As you can see it from logs.)

Here is the client .ovpn file:

client
dev tun
proto udp
remote vpn.pcpincer.hu 1247
remote viponline.choma.hu 1247

resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca Manuel_ca.crt
cert Manuel_c4.crt
key Manuel_c4.key
ns-cert-type server
tls-auth Manuel_ta.key 1
comp-lzo
verb 3

janjust

after about 1 hour the VPN client detects 'inactivity" and decides to do a restart; during the restart the DNS name resolution does not work properly; this could be a DNS caching issue where the VPN client tries to query a DNS server via the (now dead) VPN tunnel.

Can you try using an IP address for the remote end, just to see if that solves the DNS resolving issue?

gork

I am having this same issue with the "name is valid but..." error. I can confirm, at least for me, that using the IP address on the remote end solves the problem. I am using OpenVPN v2.2.1.

EDIT
Fwiw, I've tested this from four different locations using Google's DNS servers, Comcast's and I have no idea what the other two were. And I'm unable to compare my findings to "how it used to be" because I am a new OpenVPN user. I only share this information to indicate this is not simply an issue of DNS entries being blocked, or the like.

gork

I use the redirect-gateway option, so at least in my case, this seems to be the problem (from the HOWTO):

"Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease."

It seems odd this would be by design. I would have assumed an exception would have been built in for when the DCHP address on the client machine is renewed (or in my case gets disconnected.) If I understand correctly, if we're using the redirect-gateway option we will not be able to use a URL, only an IP address, to connect the OpenVPN client to the OpenVPN server. I think the issue I'm having is more of a problem than with some because my client connects over wifi.

Mimiko

It seems odd this would be by design. I would have assumed an exception would have been built in for when the DCHP address on the client machine is renewed (or in my case gets disconnected.)

In the OpenVPN server config add "float" option.

gork

Thank you! It would probably have been a long time (if ever) before I found that gem in the manual... Even had I run across it I probably wouldn't have recognized it as a solution to this issue.

EDIT:
After about an hour of testing, as expected, adding the FLOAT option to the server's configuration file did the trick.