Abstract:
A network communication system for communicating data from a source network location to a destination network location is disclosed. The system comprises a source network device and a destination network device. The source network device has a source control packet manager that detects a source data packet when the source data packet is received at the source network device from a remote network device, generates a forged response control packet in response to detection of the source data packet, and sends the forged response control packet to the remote network device. The destination network device detects a destination response packet sent from the destination location in response to reception of the source control packet at the destination location, and prevents sending of the destination response packet to the remote location.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to a network communication system, and in particular to a communication system for improving network bandwidth in Internet communications. 
       BACKGROUND 
       [0002]    The Internet is a very large scale internet protocol (TCP/IP) based data network that is used to communicate information between computing devices, including personal computers, tablet computers and smartphones. Such information may be time critical or non-time critical. 
         [0003]    Non-time critical information is typically communicated through the Internet using TCP protocol, which includes quality of service measures that operate to guarantee delivery of accurate data. If any data packets do not arrive safely at a destination, the packets are resent. TCP is for example typically used for Internet browsing, email and file transfer applications. 
         [0004]    Time critical information is typically communicated through the Internet using UDP protocol, which does not include quality of service measures such as guarantee of delivery and as such any packets that do not arrive on time are lost. UDP is for example typically used for real-time audio/visual communications. 
         [0005]    When information is passed to a user computing device from a remote server, the information typically passes from the remote server through several networks and routing devices to the user computing device, and typically a significant determining factor in the overall bandwidth available between the server and user computing device is the bandwidth available through a section of the communication path that is adjacent the user computing device. This section of the communication path is referred to in this specification as the ‘last mile’ of the communication path. 
         [0006]    In typical Internet communications, such as TCP communications, when a packet is received at a destination device from a source device, the destination device sends a response control packet to the source device. However, since the response control packets are used by the source device to determine the appropriate packet send rate to use, the effect is that the speed of communications through the entire communication path is dependent on the speed of communications across the last mile. 
       SUMMARY 
       [0007]    In accordance with a first aspect of the present invention, there is provided a network communication system for communicating data from a source network location to a destination network location, the system comprising: 
         [0008]    a source network device comprising a source control packet manager for managing control packets that pass between the source and destination locations; 
         [0009]    the source network device arranged to detect a source data packet when the source data packet is received at the source network device from a remote network device, and the source control packet manager generating a forged response control packet in response to detection of the source data packet; 
         [0010]    the source network device arranged to send the forged response control packet to the remote network device; 
         [0011]    a destination network device arranged to detect a destination response packet sent from the destination location in response to reception of the source data packet at the destination location, and to prevent sending of the destination response packet to the remote location; 
         [0012]    wherein the forged response control packet emulates the destination response packet. 
         [0013]    In an embodiment, the source network device is arranged to add a custom packet header to the source data packet, the custom packet header including a forged packet flag, the destination network device detecting the forged packet flag and in response preventing sending of the destination response packet to the remote location when the destination response packet sent from the destination location is detected by the destination network device. 
         [0014]    In an embodiment, the source network device comprises at least one source application arranged to implement at least generation of a forged response control packet in response to detection of the source data packet. 
         [0015]    In an embodiment, the source network device comprises a source TUN interface arranged to provide an interface between a kernel of the source network device and the source application. 
         [0016]    In an embodiment, the source application is downloadable and installable on a source computing device so as to at least partially implement the source network device on the source computing device. 
         [0017]    In an embodiment, the destination network device comprises at least one destination application arranged to implement at least detection of a destination response packet sent from the destination location in response to reception of the source data packet at the destination location, and prevention of sending of the destination response packet to the remote location. 
         [0018]    In an embodiment, the destination network device comprises a destination TUN interface arranged to provide an interface between a kernel of the destination network device and the destination application. 
         [0019]    In an embodiment, the destination application is downloadable and installable on a destination computing device so as to at least partially implement the destination network device on the destination computing device. 
         [0020]    In an embodiment, the source network device comprises a source VPN network interface and the destination network device comprises a destination VPN network interface, the source and destination VPN network interfaces creating a VPN tunnel between the source and destination network devices. The VPN tunnel may be arranged to use a base SSL connection. 
         [0021]    In an embodiment, payload data of the source packet is compressed using ASCII compression. In response to compression of source packet payload data using ASCII compression, the source network device may be arranged to add an ASCII compression flag to the custom packet header. 
         [0022]    In an embodiment, the destination network device is arranged to detect the ASCII compression flag in the custom packet header, and in response to decompress the associated ASCII compressed payload data. 
         [0023]    In an embodiment, the source network device is arranged to compress the payload data using a data compression algorithm. A plurality of data compression algorithms may be available and the source network device may be arranged to select a data compression algorithm based on defined criteria. The data compression algorithms may include a ZLib compression algorithm and a Brotli compression algorithm. 
         [0024]    In an embodiment, the custom header includes data indicative of the type of custom packet. 
         [0025]    In accordance with a second aspect of the present invention, there is provided a source network device for communicating data to a destination network device, the source network device comprising: 
         [0026]    a source control packet manager for managing control packets that pass between the source and destination locations; 
         [0027]    the source network device arranged to detect a source data packet when the source data packet is received at the source network device from a remote network device, and to generate a forged response control packet in response to detection of the source data packet; and 
         [0028]    the source network device arranged to send the source data packet to the destination location and to send the forged response control packet to the remote network device. 
         [0029]    In accordance with a third aspect of the present invention, there is provided a server computing device comprising a source network device according to the second aspect of the present invention. The source network device may be implemented at least partially by a server application that may be downloaded and installed on the server computing device. 
         [0030]    In accordance with a fourth aspect of the present invention, there is provided a destination network device for receiving data communicated from a source network device, the destination network device arranged to detect a destination response packet sent from a destination location in response to reception of the source control packet at the destination location, and to prevent sending of the destination response packet to the remote location, wherein the forged response control packet emulates the destination response packet. 
         [0031]    In accordance with a fifth aspect of the present invention, there is provided a client computing device comprising a destination network device according to the fourth aspect of the present invention. The destination network device may be implemented at least partially by a client application that may be downloaded and installed on the client computing device. 
         [0032]    In the above embodiments, the source network device may be arranged to implement functionality associated with the destination network device, and the destination network device may be arranged to implement functionality associated with the source network device. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0033]    The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: 
           [0034]      FIG. 1  is a diagrammatic representation of a typical Internet network arrangement that supports TCP/IP communications; 
           [0035]      FIG. 2  is a conceptual overview block diagram of a network communication system in accordance with an embodiment of the present invention; 
           [0036]      FIG. 3  is a block diagram of the network communication system shown in  FIG. 2  illustrating components of the system; 
           [0037]      FIG. 4  is a block diagram of a packet buffer manager of the system shown in  FIG. 3 ; 
           [0038]      FIG. 5  is a block diagram of a control packet manager of the system shown in  FIG. 3 ; 
           [0039]      FIG. 6  is a flow diagram illustrating processing packets at a VPN server end of a VPN tunnel of the system shown in  FIG. 3 ; 
           [0040]      FIG. 7  is a flow diagram illustrating a method of processing packets at a client end of the VPN tunnel of the system shown in  FIG. 3 ; and 
           [0041]      FIG. 8  is a block diagram of reliability components of the system shown in  FIG. 3 . 
       
    
    
     DETAILED DESCRIPTION 
       [0042]    For the purpose of this specification the term ‘inbound’ refers to data that travels to the client device  14  from a remote server, and the term ‘outbound’ refers to data that travels from the client device  14  to the remote server. 
         [0043]    Referring to  FIG. 1  of the drawings, an arrangement is shown that represents a typical communications arrangement across the Internet wherein a remote server  12  communicates with a client computing device  14 , such as a personal computer, tablet computer or smartphone. In this example, a communication from the remote server  12  passes through a cloud gateway  16  and a VPN server  18  that is arranged to connect with the client device  14  through a virtual private network (VPN). The VPN establishes a network tunnel  19  between the VPN server  18  and the client device  14  that facilitates secure communications to and from the client device  14  across the tunnel  19 . In the present specification, the terms ‘VPN connection’ and ‘tunnel’ are used interchangeably. 
         [0044]    The present system provides a degree of optimisation of communications between the client device  14  and the VPN server  18  in order to avoid throttling of the packet transmission rate through the ‘first mile’ and ‘middle mile’ of the communication path because of low bandwidth at the ‘last mile’ of the communication path adjacent the client device  14 . 
         [0045]    The VPN server  18  and the client device  14  are shown conceptually in  FIG. 2 . The client device  14  includes a client kernel  20   c , a client application  22   c  and a TUN interface  24   c  arranged to provide a virtual interface for network data between the kernel  20   c  and the client application  22   c . Similarly, the VPN server includes a VPN server kernel  20   s , a server application  22   s  and a TUN interface  24   s  arranged to provide a virtual interface for network data between the kernel  20   s  and the server application  22   s.    
         [0046]    During use, data that is desired to be sent over the network through the tunnel  19  is passed to the client/server application  22   c ,  22   s  through the relevant TUN interface  24   c ,  24   s  by the relevant kernel  20   c ,  20   s , and the client/server application processes the network data and passes the data back to the kernel through the TUN interface  24   c ,  24   s  for transmission. 
         [0047]    At the opposite side of the tunnel  19 , the relevant kernel  20   c ,  20   s  passes the custom packets through the relevant TUN interface  24   c ,  24   s  to the relevant client or server application  22   c ,  22   s  which processes the custom packets, and passes the packets back to the relevant kernel through the relevant TUN interface  24   c ,  24   s  for onward transmission to the relevant remote server  12  or client device  14 . 
         [0048]    Processing of the data at the VPN server  18  involves creating a forged response packet in response to reception at a server side of the VPN tunnel  19  of a packet from the server  12 , and sending the forged response packet back to the server  12 . The forged response packet mirrors a response packet that would be sent to the server  12  from the client  14  when a packet from the server  12  is received at the client  14 . In this way, the server  12  receives a response control packet in respect of a packet before the packet has passed over the tunnel  19  to the client device  14 , and the packet send rate from the server  12  is determined by the bandwidth across the first mile and middle mile and not the last mile of the communication path. 
         [0049]    After sending the forged response packet, a custom packet header is created for the associated received packet and added to the packet to create a custom packet. The custom header includes information to indicate to other components of the system that a forged packet has been sent in respect of the packet. 
         [0050]    The custom packets may be buffered at the VPN server  18  and individually compressed prior to communication through the tunnel  19 . 
         [0051]    Referring to  FIG. 3 , components of a network communication system  30  are shown in more detail. Like and similar features are indicated with like reference numerals. 
         [0052]    The system  10  includes a client device  14  that communicates with a VPN server  18  through a VPN tunnel  19  that has been established by the client device  14  and VPN server  18 . As indicated above, the VPN tunnel  19  extends across the ‘last mile’ of the communication path between the client device  14  and a remote server (not shown) that for example is in communication with the client device  14  through a WAN  32 . 
         [0053]    As indicated, the client device  14  may take the form of a personal computer  36 , tablet computer  38  or smartphone  40 , although it will be understood that any suitable computing device is envisaged. It will be understood that the client device is shown conceptually in  FIG. 3  and while the client device  14  may for example be a personal computer  36 , tablet computer  38  or smartphone  40 , the components of the client device  14  illustrated in  FIG. 3  would be incorporated in and form part of the personal computer  36 , tablet computer  38  or smartphone  40 . 
         [0054]    The client device  14  includes an inbound packet manager  44  and an outbound packet manager  46  that are arranged to perform complimentary functions for data that travels in different directions across the tunnel  19 . The packet managers  44 ,  46  in this example are implemented using a client application that is installed on the client device  14 , and the packet managers  44 ,  46  are arranged to process data that is sent across the tunnel  19 , including creating custom packet headers, generating forged control packets, compressing the packets before entry into to the tunnel  19 , decompressing packets that are received from the tunnel  19 , and managing control aspects of packet transfer across the network. 
         [0055]    Each of the packet managers  44 ,  46  communicates with a VPN driver that serves as a TUN interface  24   c  arranged to facilitate passage of data packets between the client device kernel  20   c  and the client application represented in this example by the packet managers  44 ,  46 . Data packets that are passed to the client device kernel  20   c  by the TUN interface  24   c  are transferred to the physical network (and thereby the VPN tunnel  19 ) through a network interface  48  if the data packets are outbound data packets, or to a device application running on the client device  14 , such as an Internet browser, that is in communication with the remote server  12  and receiving data packets from the remote server  12 . 
         [0056]    The VPN server  18  may take the form of a personal computer or dedicated computer server, although it will be understood that any suitable computing device is envisaged. 
         [0057]    The VPN server  18  includes an inbound packet manager  50  and an outbound packet manager  52  that are arranged to perform complimentary functions for data that travels in different directions across the tunnel  19 . The packet managers  50 ,  52  in this example are implemented using a server application that is installed on the VPN server  12 , and, in a similar way to the packet managers  44 ,  46  of the client device  14 , the packet managers  50 ,  52  are arranged to process network data that is sent across the tunnel  19 , including creating custom packets, generating forged control packets, compressing the custom packets, decompressing custom packets that are received from the tunnel  19 , and managing control aspects of packet transfer across the network. 
         [0058]    Each of the packet managers  50 ,  52  communicates with a TUN interface  54  arranged to facilitate passage of data packets between the VPN server kernel  20   s  and the server application represented in this example by the packet managers  50 ,  52 . Data packets that are passed to the VPN server kernel  20   s  by the TUN interface  24   s  are transferred to the physical network and the VPN tunnel  19  through a tunnel network interface  56 , or to the physical network and the WAN and ultimately the remote server  12  through a WAN network interface  58 . 
         [0059]    The VPN server  18  also includes routing devices  60  arranged to carry out appropriate IP routing as required. 
         [0060]    Each of the packet managers  44 ,  46 ,  50 ,  52  includes a packet scanner  68 , in this example implemented using an ASCII processor, that analyses each incoming original source packet and determines the most appropriate action to carry out in respect of the packet, for example whether to compress using ASCII compression, or whether to apply other compression methodologies described in more detail below. The packet scanner  68  also analyses the incoming source packet to determine packet type, for example whether the source packet is a TCP type packet, a UDP type packet, a control packet, or a packet that is latency sensitive and therefore should be passed over the network without delay. 
         [0061]    Each packet manager  44 ,  46 ,  50 ,  52  also includes a packet buffer manager  70  arranged to build custom packets, compress the payload data in the custom packets according to the compression regime determined by the packet scanner  68 , trigger generation of a forged control packet, rebuild original source packets, and decompress payload data in the custom packets. 
         [0062]    Components of the packet buffer manager  70  are shown in more detail in  FIG. 4 . The packet buffer manager  70  includes a buffer  72  arranged to receive and temporarily store source packets; a memory  74  arranged to store information indicative of several compression regimes  76 , including ASCII compression, ZLib compression and Brotli compression; and a control unit  78  arranged to control and coordinate operations in the packet buffer manager  70 . 
         [0063]    The control unit  78  in this example is arranged to implement several functions and for this purpose the control unit includes or otherwise implements a compressor/decompressor  82  arranged to apply ASCII and other compression and decompression regimes to the source packet payload data, a packet builder  84  arranged to construct custom packets that include compressed payload data and a custom header, and a forged packet trigger generator  85  arranged to send a signal to cause generation of a forged control packet to be sent to the remote server  12  when a packet is received in the packet buffer  70  from the server  12 . 
         [0064]    The custom header in this example includes the following header fields:
       ProtocolID   CodecFlags   ProtocolFlags       
 
         [0068]    The ProtocolID field provides an indication as to the type of packet, and in this example the packet type may be any one of the following:
         111 : Error/Reconnect     200 : Authenticate/Handshake     201 : Control packet     202 : Compressed buffer     203 : Cache hit/Duplicate     204 : Untouched/Raw UDP packet     205 : Untouched/Raw TCP packet       
 
         [0076]    The CodecFlags field contains flags indicative of the compression/decompression regime that has been used in relation to the payload. 
         [0077]    In the present example, the CodecFlags field includes the following bits:
       PacketCodec (ASCII)   BufferCodec (LZ)   BufferCodec (Brotli)       
 
         [0081]    A ‘1’ in a PacketCodec flag indicates that the respective source payload has been compressed with ASCII compression; a ‘1’ in a BufferCodec field indicates that the respective codec has been used to compress the payload data. 
         [0082]    The ProtocolFlags field contains flags indicative of special packet types and/or features that relate to network functionality, and in this example the ProtocolFlags field includes a ResponseForged flag indicative of whether a forged control packet has been generated and sent by the VPN server  18  to the remote server  12 . A ‘1’ in a ResponseForged flag indicates that the forged control packet has been sent. 
         [0083]    Other fields may be included in the custom header as appropriate for operation of a packet network such as the Internet. 
         [0084]    Each packet manager  44 ,  46 ,  50 ,  52  also includes a control packet manager  132  that manages control packets passing between the client device  14  and the remote server  12 , the control packets containing control, routing and scheduling information required for correct operation of a packet network; and that generates forged control packets in response to a trigger signal received from the packet buffer  70 . 
         [0085]    The control packet manager  132  is shown in more detail in  FIG. 5 . The control packet manager  132  communicates with the packet scanner  68  and the packet buffer manager and includes a control unit  134  arranged to control and coordinate operations in the control packet manager  132 . The control unit  134  includes or is arranged to implement a forged packet builder  136  arranged to create a forged control packet that simulates a control packet that would be received at the remote server  12  in response to receipt from the remote server  12  of a packet at the client device  14 . The control unit  134  also includes or is arranged to implement a packet analyser  138  arranged to determine, in this example at the client side of the tunnel  19 , whether a ResponseForged flag is present in the packet header and therefore whether a forged control response has been sent for the packet. 
         [0086]    Each packet manager  44 ,  46 ,  50 ,  52  also includes a packet cache manager  134  arranged to avoid duplication of transmission of data when the same data previously sent to the client device  14  or VPN server  18  is required at a subsequent time by the client device  14  or VPN server  18 . 
         [0087]    Referring to  FIG. 6 , a flow diagram  140  is shown that illustrates a method of processing packets as source packets arrive from the remote server  12  for transmission through the tunnel  19  to the client device  14 . 
         [0088]    On arrival at the relevant server kernel  20   s  of the VPN server  20   s , the source packets are passed  142  to the application layer through the server TUN interface  24   s  for processing by the server application  22   s . During processing, the received source packets are identified as packets containing payload data by the packet scanner  68  and added  144  to the buffer  72  of the packet buffer manager  70 . In response to receipt of a packet containing payload data at the buffer  72 , the forged packet trigger generator  85  of the packet buffer manager  70  generates and sends  146  a trigger signal to the control packet manager  132  to cause the control packet manager  132  to send  148  a forged control packet to the remote server  12 . 
         [0089]    As indicated at steps  150  and  152 , if any of the source packets are suitable for ASCII compression, as identified by the packet scanner  68 , ASCII compression is applied to the source packets and an appropriate flag added to the CodecFlags field of the custom header. 
         [0090]    As indicated at step  154 , the packet scanner  68  analyses the incoming source packets and determines the most appropriate compression algorithm to use to compress the data in a data packet. In this example, two compression algorithms are available: Broth compression, that is used as the primary compression algorithm, and ZLib compression, that is used for particular versions of client/VPN server applications  22   c ,  22   s , JAVA versions of the client/VPN server applications  22   c ,  22   s , and when the load on the VPN server  18  is approaching an upper limit threshold. After selection of the most appropriate compression algorithm, the selected algorithm is applied  156  to the packet payload data by the compressor/decompressor  82  to produce compressed payload data. A custom packet is then created  158  that includes the compressed data and a custom header with the appropriate codec flag added to the CodecFlags field and a TRUE flag added to the ResponseForged flag. The created custom packets are passed to the server kernel  20   s  through the server TUN interface  24   s  for transmission through the tunnel  19  to the client device  14 . 
         [0091]    Referring to  FIG. 7 , a flow diagram  170  is shown that illustrates a method of processing custom packets as the custom packets pass out of the tunnel  19  and are received at the client device  14 . 
         [0092]    After passing through the tunnel  19  and arriving at the client kernel  20   c  of the client device  14 , the packet is passed  172  to the application layer through the client TUN interface  24   c  for processing by the client application  22   c . The received custom packet is decompressed  174  by the compressor/decompressor  82  using the selected compression algorithm and, as indicated at steps  178  and  180 , if the packet was compressed using ASCII compression, the packet is decompressed. 
         [0093]    The packet is then analysed  182  by the packet buffer manager  70  and if a TRUE ResponseForged flag is detected, a call  184  is made to the control packet manager  132  to cause the control packet manager  132  to block the associated control packet that will issue from the client device  14  in response to receipt of the packet from the remote server  12 . The decompressed packet is then passed  186  to the relevant client kernel  20   c  through the client TUN interface  24   c  for transmission to the client device  14 . 
         [0094]    When the actual control packet issues from the client device in response to receipt of the packet from the remote server  12  and is received  188  at the buffer  72  of the packet buffer manager  70 , the control packet manager  132  discards  190  the actual control packet. 
         [0095]    A similar process occurs when a packet is sent from the client device  14  through the tunnel  19  to the remote server  12 . 
         [0096]    It will be appreciated that by sending forged control packets to the remote server  12  from a location before the tunnel  19  in response to receipt of packets from the remote server  12 , the maximum amount of data is transmitted from the remote server across the first mile and middle mile of the communication path between the remote server  12  and the client device  14 . This allows the buffer  70  at the entry side of the tunnel  19  to be filled at a maximum rate without regard to the speed on the last mile. This also allows much of the control associated with TCP to be limited at the client device  14 . 
         [0097]    It will be understood that the packet scanner  68  is responsible for making decisions in relation to the actions to carry out on a source packet or custom packet  90 . 
         [0098]    For example, for custom packets that exit the tunnel  19 , the packet scanner uses the ProtocolID field in the custom header to determine routing/handling actions to be carried out on the packet: 
         [0000]    
       
         
               
               
             
           
               
                   
               
             
             
               
                 111: Error/Reconnect 
                 Drop packet—handled by VPN layer 
               
               
                 200: Authenticate/Handshake 
                 Drop packet—handled by VPN layer 
               
               
                 201: Control packet 
                 Pass packet to control packet manager  
               
               
                   
                 132 
               
               
                 202: Compressed buffer 
                 Pass packet to packet buffer manager 
               
               
                 203: Cache hit/Duplicate 
                 Pass packet to cache/deduplication  
               
               
                   
                 manager 
               
               
                 204: Untouched/Raw UDP  
                 Bypas—send directly to TUN  
               
               
                 packet 
                 interface 
               
               
                 205: Untouched/Raw TCP  
                 Bypas—send directly to TUN  
               
               
                 packet 
                 interface 
               
               
                   
               
             
          
         
       
     
         [0099]    Packets that are considered to be latency sensitive prior to entry into the tunnel  19  are cached and sent directly to the TUN interface  24   c ,  24   s . Such latency sensitive packets are typically associated with RPC traffic, including traffic associated with gaming that would significantly affect user experience if latency were introduced through buffering and compression. Latency sensitive packets are identified when codecs  204  and  205  exist in the custom packet header. 
         [0100]    Packets that are identified as control packets are not cached or compressed; they are routed to the control packet manager  132  for processing. Control packets are identified using protocol headers in the source packet header. For example, a TCP header includes ACK, SYN and FIN features. A high performance database is maintained in the packet scanner  68  and is used to facilitate quick identification of control packets and improved system performance. 
         [0101]    Referring to  FIG. 8 , a block diagram of reliability and congestion control components  200  for packet transmissions through the tunnel  19  is shown. The components  200  are implemented at the tunnel layer. 
         [0102]    The components  200  include a client packet sender and receiver  202  and a server packet sender and receiver  204 . Each packet sender and receiver  202 ,  204  includes a packet transmission manager  206   c ,  206   s  arranged to control and coordinate sending and receiving of custom packets through the tunnel  19  when the custom packets are passed to the relevant kernel  20   c ,  20   s  by the relevant TUN interface  24   c ,  24   s ; and a packet failure determiner  208   c ,  208   s  arranged to handle errors in transmission of the custom packets and in particular to make determinations as to whether retransmission of a custom packet is required. 
         [0103]    The components also include a client sent packets buffer  210   c  and a server packet sent buffer  210   s , each of which is arranged to cache sent packets in a respective packet data buffer  212   c ,  212   s . The packet data buffers  212   c ,  212   s  are used when packets are required to be resent across the tunnel  19 . 
         [0104]    According to conventional VPN regimes, the system  30  also encrypts the custom packets  90  prior to sending across the tunnel  19  and decrypts the packets as they are received at the other side of the tunnel  19 . In the present example, all key exchanges required for encryption occur over a base SSL connection. If no SSL certificates are in place, the VPN service will prevent connection to the VPN and prompt the user to open the client or server application  22   c ,  22   s.    
         [0105]    Modifications and variations as would be apparent to a skilled addressee are deemed to be within the scope of the present invention.