Slightly off topic - VPN stability and 4D client-server
P. Lovejoy
I have been working on a 4D project which runs client-server over ADSL
on VPN. Everything works great, except the VPN connections are lost
several times a day between the "client" locations and the server
location. 4D Client quits with a -10002 when this happens, as would be
expected.
The locations (10 in all) are connected over dedicated VPN routers on
ADSL connections, all from the same ISP and all in a fairly close
geographical area with few hops between locations. We have been able to
verify that the ADSL connections are staying up the whole time, even
when the VPN falls.
My problem is another vendor is responsible for the VPN network. He
claims it is normal for the VPN to fall, then reconnect again a couple
of minutes later. I think this is bull... oney, but I'd like to know if
anyone else has this type of experience. I suspect a problem with the
routers or with the way they have been set up.
Any ideas would be appreciated.
Paul
David Lung
the TCP preferences, our users experienced very frequent -10002
disconnections. Since we have client TCP.OPT set at >3 minutes and on
the server > 1 hour, AND we entered allowable IP addresses (to prevent
garbage packages from coming in), we don't see -10002 anymore. We do
see an unexcpected quit every once in a while still, but that we still
observe on the local LAN too.
What I described here is 2003.8.
P. Lovejoy
The TCP timeout is at default. Thanks for the idea.
Actually, we're able to verify that VPN is down. The clients lose their
connections to shared volumes also. I have been thrown out of remote
access to the server with this also. I'm not sure if a longer timeout
will help, since I would suspect the sockets are closed automatically
by Windows when the network is lost on the client machine.
I will try changing the value to see if the client can remain
"connected" through one of these VPN hickups.
Thanks,
Paul
P. Lovejoy
Apparently, TCP.OPT isn't supported with 2004. Set Database Parameter
seems to have taken its place, or simply using the setting in
Preferences:Client-server:Configuration on server and client.
I tried setting client and server timeouts to 5 minutes each. I then
intentionally cut the VPN and turned it back on immediately. That
provokes a -10001 on the client, no matter how short the delay. It
looks like VPN going down causes the socket to be closed.
Any other ideas out there?
tia
Paul
David Lung
the client via the outside world (not VPN) does. The public IP address
at the Server's port in 4D Client and then port fowarding in the
router. We actually often see this work faster than VPN. You will not
be able to mount disk though.
David Lung
some of our client's router logs (Netgear FVS318) and see that VPN
practically never goes down.
P. Lovejoy
We tried connecting directly to the server's ip address without using
VPN. Yes, the connections were noticeably faster and they did not
suffer from the VPN falling. I thought this was pretty strong evidence
that the VPN disconnect problem was at the root of these
disconnections.
Interestingly, with 4D 2003, we were able to reboot the routers, which
takes a minute, and 4D Client was able to maintain the connection. This
ability seems to have been lost with 4D 2004.3.
It isn't clear to me whether TCP timeout and the 4D Client-server
timeouts are one and the same. I suspect not. But I can't find a way to
get 4D Client 2004.3 to use the TCP.OPT file. Am I missing something?
For my client, not using VPN is not an option. They are concerned with
security and don't want their server with a public ip address,
vulnerable to the outside world.
Thanks.
Paul
David Lung
database preferences. I presume that will be the same as TCP.OPT in
2003.
Remains the IP ranges. Where do you set what IP's packets are alloowed
to come in? When we had so many -10002 troubles, we heavily logged
all packets and noticed tons of stuff coming in with wrong IP origins.
All sort of attempts to break in all the time. We needed to defend
against that too, in order to protect 4D Client server communications
by precisely determining IP addresses that could go thru into 4D
Client & 4D Server on all machines.
David Lung
file. Am I missing something?
Are you talking Win or Mac? TCP.OPT on Win is invisible strangely
enough....Use "Serach" on invisibles on Windows to find it.
If you talk Mac, do you have a TCP.OPT at Librarry/Applications
support/4D?
David Lung
file. Am I missing something?
You can set the time out for clients via the 4D language.
P. Lovejoy
This problem is occuring on a PC-only network. Workstations are XP Pro
and server is 2003.
I customized the tcp.opt file in C:\Documents and
settings\Paul\Application data\4D\. I also tried All Users, Default
User etc. 4D Client 2004 does not recognize the port number change in
the tcp.opt files. I suspect it also ignores the timeout setting.
I saw on Monkeywerks that this file is apparently obsolete in version
2004.
Paul
David Lung
users\Application data\4D.
As I already said, the TCP.OPT (in our experience) is invisble. You
first do a regular FIND and then your expand the serach to include
invisibles.
P. Lovejoy
Yes, I found that file and edited it. It didn't work. I believe 4D
Client 2004 ignores it.
Paul
David Lung
Julio Carneiro
TCP.OPT is no longer used in 2004. The file you see is a legacy from
prior versions.
Settings in the old TCP.OPT are available either thru 4D Preferences
or SET DATABASE PARAMETER
Except for the parameter David indicated... TCP Timeout is not
available for customization.
FYI, the Client/Server Timeout settings is something else... it
controls time outs between Client x Server communication on a higher
layer. The old TCP.OPT timeout seemed to apply at a lower level on
the TCP communication layer. They were available in Preferences in
old 4D versions (since 6.5 I guess).
I guess you need to ask 4D to provide access to that preference
setting to be made available again.
cheers,
julio