Client disconnecting over a VPN connection - SCO

This is a discussion on Client disconnecting over a VPN connection - SCO ; Hi there. I know this is a rather complicated issue and honestly the box hosting the application is UnixWare7 and not OS5 but given the overall knowledge of the people contributing to this group, I'd like to know your opinions/views ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Client disconnecting over a VPN connection

  1. Client disconnecting over a VPN connection

    Hi there.

    I know this is a rather complicated issue and honestly the box hosting
    the application is UnixWare7 and not OS5 but given the overall knowledge
    of the people contributing to this group, I'd like to know your
    opinions/views about this problem.

    On a remote site we have som operators who, using Windows boxes, run an
    account package which is phisically located on a remote server. To do
    that, they:

    . cross a Multitech FW 650 Firewall which creates a VPN
    between their site and ours
    . traverse a Perle I/O Link Pro100 router
    . access the Internet using an ADL 2MB/s line
    . get to our CISCO router (dunno about that since it's not
    managed by us)
    . access the same Multitech FW 650 Firewall which "completes"
    the VPN connection
    . finally get to a UnixWare 7.1.1 server which runs the
    account package

    From a TCP/IP point of view, the VPN allows the clients to reach the
    server to run the accounting package.

    To run it, the remote clients connect to the account server using a
    Windows rlogin client (which gets to port 513 of the server); once at
    the shell prompt, there's a shell script which sets some env variables
    including one which is used by the package itself to connect back to the
    client itself. As far as I know, the package is written in 4JS's BDS
    version 3.53 which is similar to the Informix Dynamic Server.

    As far as I know, you can program this product and the same executable
    may depict in character and GUI (X11) mode by simply setting an
    environment variable; our management decided to adopt the GUI interface
    and so, on the clients, a little 4JS client (a simple X11 server) is
    operating to depict the remote package screens.

    So, in a nutshell, the clients fire up an X11 server (operating at port
    6400 if memory serves), rlogin into the UW7 box, set an environment
    variable and start the package which depicts back using the X11 protocol.

    The same account package is operated internally by using the same client
    but working on a LAN.

    During the last 2 months we've been told about a frequent number of
    "disconnections" reported on the remote site; by disconnection I mean
    the disappearing of the windows which depicts the package even while the
    operator is typing/clicking.

    These problems occurs approx every 10/15 minutes and have been reported
    by all the operators on the remote site (ie, this is not related to a
    single box) even if they occur at different times.

    During these periods, the internet connection is reported as functional
    since operators on the remote side can browse the 'Net without problems;
    the VPN link seems to work fine since (eg) while operator Bill reports
    the problem, operator Bob still works using the same VPN channel.

    The network stats on the server seem to be OK, apart from a number of
    connections dropped (3378). An excerpt from the "netstat -s" output follows:

    tcp:
    9021539 packets sent
    8951781 packets used fast path
    6040576 data packets (4046421491 bytes)
    6714 data packets (9448297 bytes) retransmitted
    403416 ack-only packets (11496 delayed)
    79 URG only packets
    911 window probe packets
    2422115 window update packets
    147728 control packets
    692 resets
    7043907 packets received
    1264108 acks (for 4046388309 bytes)
    12047 duplicate acks
    0 acks for unsent data
    5698389 packets (3350621751 bytes) received in-sequence
    0 completely duplicate packets (0 bytes)
    272 packets with some dup. data (2918 bytes duped)
    1788 out-of-order packets (12128 bytes)
    1 packet (0 bytes) of data after window
    0 window probes
    14703 window update packets
    159 packets received after close
    0 discarded for bad checksums
    0 discarded for bad header offset fields
    0 discarded because packet too short
    0 system errors encountered during processing
    145752 connection requests
    818 connection accepts
    4640 connections established (including accepts)
    147981 connections closed (including 3378 drops)
    141913 embryonic connections dropped
    0 failed connect and accept requests
    451 resets received while established
    1104692 segments updated rtt (of 1079544 attempts)
    4429 retransmit timeouts
    99 connections dropped by rexmit timeout
    529 persist timeouts
    0 alloc failures caused reschedule
    91 keepalive timeouts
    81 keepalive probes sent
    10 connections dropped by keepalive
    5599582 segments predicted
    219138 acks predicted
    0 segments dropped due to PAWS
    104 bogus SYN packets
    0 listen queue overflows


    The strange thing is that operators running on the local LAN never
    experieced a problem like this one.

    We've tried with a continuos ping from the server to a given client for
    a whole day; the client reported a number of disconnections but ping
    never failed.

    I had a look at the server's syslog file but nothing unusual is reported.

    The remote site is configured with the 192.168.0.x network class and a
    DHCP server is not operating.

    Again, this is getting a big problem for us since remote operators
    cannot afford being disconnected so frequently.

    Thanks for your time.

    Best,
    Roberto
    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  2. Re: Client disconnecting over a VPN connection

    On Wed, 21 Sep 2005 11:26:52 +0100, Rob wrote
    (in message ):


    > During the last 2 months we've been told about a frequent number of
    > "disconnections" reported on the remote site; by disconnection I mean
    > the disappearing of the windows which depicts the package even while the
    > operator is typing/clicking.
    >
    > These problems occurs approx every 10/15 minutes and have been reported
    > by all the operators on the remote site (ie, this is not related to a
    > single box) even if they occur at different times.
    >
    > During these periods, the internet connection is reported as functional
    > since operators on the remote side can browse the 'Net without problems;
    > the VPN link seems to work fine since (eg) while operator Bill reports
    > the problem, operator Bob still works using the same VPN channel.


    I know this isn't going to be very helpful, but at my last job we ran
    character sessions (telnet) to an OpenServer 5.0.6s box. We always had a low
    level of disconnections which we mostly at sites using a WAN link - they were
    reported to the user by the local telnet app popping up a notice that teh
    connection was reset by the peer.

    I alway put this down to a flaky bit of network programming, either in the
    TCP stack or the telnet daemon - I always assumed that there was a network
    error (dropped packet) or a delayed packet and some bit of the system simply
    didn't handle it correctly.

    Simon


  3. Re: Client disconnecting over a VPN connection

    Simon Hobson wrote:
    > On Wed, 21 Sep 2005 11:26:52 +0100, Rob wrote
    > (in message ):
    >
    >
    >
    >>During the last 2 months we've been told about a frequent number of
    >>"disconnections" reported on the remote site; by disconnection I mean
    >>the disappearing of the windows which depicts the package even while the
    >>operator is typing/clicking.
    >>
    >>These problems occurs approx every 10/15 minutes and have been reported
    >>by all the operators on the remote site (ie, this is not related to a
    >>single box) even if they occur at different times.
    >>
    >>During these periods, the internet connection is reported as functional
    >>since operators on the remote side can browse the 'Net without problems;
    >>the VPN link seems to work fine since (eg) while operator Bill reports
    >>the problem, operator Bob still works using the same VPN channel.

    >
    >
    > I know this isn't going to be very helpful, but at my last job we ran
    > character sessions (telnet) to an OpenServer 5.0.6s box. We always had a low
    > level of disconnections which we mostly at sites using a WAN link - they were
    > reported to the user by the local telnet app popping up a notice that teh
    > connection was reset by the peer.
    >
    > I alway put this down to a flaky bit of network programming, either in the
    > TCP stack or the telnet daemon - I always assumed that there was a network
    > error (dropped packet) or a delayed packet and some bit of the system simply
    > didn't handle it correctly.
    >
    > Simon
    >


    Simon,

    thanks for contributing.

    I've been told that we were able to solve (at least, we really hope so
    :-) this issue by replacing the firewall/VPN device with a newer one.

    Thanks,
    Rob

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  4. Re: Client disconnecting over a VPN connection

    On Tue, 27 Sep 2005 11:50:37 +0100, Rob wrote
    (in message ):

    > I've been told that we were able to solve (at least, we really hope so
    >> -) this issue by replacing the firewall/VPN device with a newer one.


    Possibly the newer one introduced less delay and so triggers the event
    causing a disconnection less frequently. That would also tie in with my
    observations that the slower the link (or the more congested), the worse the
    problem.

    Simon


+ Reply to Thread