|
|
|
|
|
None. It includes its own operating system. Top |
None. It doesn't use a hard disk. GVS9000 VTR boots and runs
from a floppy diskette. Top |
| |
They are number seven diffrent options that are avalible today.
|
| Optional |
| |
Additional network card for Private Service network
Serial Port Com 1-4 (1645x/16550 UARTS)
Async Modem (external or internal) for PPP connection
Async Modem for pager notification
Machine Controller (external) with RS-232/RS422 9-pin interface
LTC (external) with BNC interface
2-4 USB2 interface
2-6 Firewire 800 and 4000
Dual Gigabit 10/100/1000B•T interface
2-4 SATA and SATAII interface
2-4 GB Fiber Channel interface
SCSI U320 interface (optional)
|
| Supported Network Cards |
| 10Gbit Ethernet Cards |
| |
GVS OEM Dual Gigabit (PCI-X and PCI-e )A (Intel chipset)
Intel EtherExpress PRO/10G (PCI-x only)
GVS OEM 4xPort Gigabit (PCI-x and PCI-e)
GVS OEM 6xPort Gigabit (PCI-x)
|
| 10/100 Mbps Ethernet Cards |
| |
All GVS9000 VTR's ships with dual onboard 10/100/1000B-T
Intel EtherExpress PRO/100B, PRO/100+
Intel EtherExpress
Most cards are based on the Intel 21140 chipset |
| FDDI |
| LSI PCI FDDI Adapter (SAS & DAS MMF,
SAS UTP) |
Top |
10Mbps ethernet, 100Mbps ethernet (100-TX), 1000Mbps ethernet (100-TX) and FDDI (UTP,
SAS fiber and DAS fiber), PPP (async modems). The GVS9000 VTR will
also support cable modems and xDSL devices attached to the external network
interface. Top |
32,000 simultaneous connections. Top |
GVS9000 VTR is fast, but since we know of no reasonable tests
for comparison, we have run a number of different tests, the following is based on the storage and network configuration, but since all GVS9000VTR does support jumbo frame over 8K block transfer, it provides extremely fast response time and with MCR configuraiton in the mix, it provide upto 10 concurrent DV users over Gigabit network, and uncompress HD over fiber channel, the data speed are as follow:
GVS9000 VTR system designed to deliver 4:4:4 speed, over single fiber channel
SharedGVS9000 VTR can run concurrent records up to 16 VTRs to SAN, so the edit station can edit in real time.
Speed 20-30MB/sec over Firewire
Speed 30-40MB/sec over Gigabit
Speed 40-50MB/sec over eSATA
Speed 40-50MB/sec over eSATA
Speed 300MB/sec to internal SAN on 4XU VTR and 4NXUVTR RAID
If you have a specific frame rate or need GVS Lab to run specific tests complete this enquire page. Top |
GVS9000 VTR has an unlimited user license. Top |
GVS9000 VTR is transparent to standard OSX and Unix base applications.
GVS9000 VTR also supports difficult applications that require both inbounds
and outbound connections like:
|
Final Cut Pro
Soundtrack Pro
Motion
DVD Studio Pro
Aperture
Logic Pro
Shake
Autodesk Cleaner
Cleaner
FTP (normal and PASV)
RealAudio/RealVideo
Vosaic
CU-SeeMe
StreamWorks
VDOLive
VIVOActive
True Speech
NTT AudioLink
NTT SoftwareVision
RSTP Applications
Yamaha MIDPlug
Microsoft PPTP
Microsoft NetShow
ICQ
Quake II
|
Other difficult application protocols are constantly being added so please
check the GVS9000 VTR website https://www.GVS9000.com for updates. Top |
Yes. GVS9000 VTR is the technological outgrowth of the GVS9000 workstation
(formerly Insignia Inc.) since 1992 as an Apple developer designing rugged systems. Although the
GVS9000 VTR doesn't have all the features and functionality of the Sony HD Digital Video Recorder,
it still retains the stateful far much more capable of a system that doesn't even produce the quality close to GVS9000 VTR the base GVS9000 VTR unit delivers over 1.2Gbit/sec was SRW only provide 400/800MBit/sec technology
of digital recorder. In its default configuration, the GVS9000 VTR does accept
uncompressed SD and HD SDI connections from the external single or dual SDI interface. GVS9000 VTR provides one of the grates abilities of capturing, previewing, edit in real-time, with full TCP and UDP-based applications
control so not only do you have full security of data, but content can be duplicated in real-time to provide full security of disk-based digital video recorder. GVS9000 VTR can pass packets transparently through the GVS9000 VTR system without needing
modified (special) clients or edit stations. We use the term "proxy"
because the GVS9000 VTR is able to generate a low-resolution proxy file with the same XML data to edit in real-time and soon after to can be substituted for the high-resolution file, create all the effects, and edit with your proxy file and when you are ready to render just point to high-res files..
GVS9000 VTR is a full-machine Sony machine-controlled portable digital video recorder. |
In its basic configuration the GVS9000 VTR supports two network
interfaces. An additional network card can be added to create the optional
Private Service network.
In the TCP/IP configuration the GVS9000 VTR uses a network or DVI/VGA interface. Any of
the other network types are supported on the two remaining network interfaces
(Protected or Private Service network). Top |
The External network is the unprotected network for which
no network address translation is performed. The External network is typically
connected to the Internet. However, GVS9000 VTR can also be used internally
on private networks. If connected to the Internet,
the external interface must have a registered IP address. GVS9000 VTR provides
full security for hosts located on the External network. Top |
The Protected network is the network that is hidden behind
the GVS9000 VTR system. The term Protected network is used throughout this
manual to refer to the network directly connected to the GVS9000 VTR system.
All features and attributes associated with this network also apply to
all networks connected to the Protected network. All hosts and IP addresses
used on this network are hidden from the External and Private Service
networks. Hosts on the Protected Network are not by default accessible
from the External network or PSN network. The Tunnel facility can be used
to allow external access to hosts and
services on this network. Top |
The Private Service Network (PSN) (also often known as a
DMZ network) is an optional service network that is located logically
between the External network and the Protected network. The PSN isn't
actually between the Protected and External networks, but nearly at a
peer level with the Protected network. The PSN, however, is untrusted
by the Protected network and by default no unsolicited packets are allowed
to pass from the PSN to the Protected network. All hosts on the PSN are
hidden from the External network, but completely accessible from the Protected
network.
The PSN is used in conjunction with the Tunnel facility to allow external
access to hosts and services, such as web servers, FTP servers, email
server, etc. By tunneling to a server on the PSN, an organization can
allow public access to services while maintaining network security for
the Protected network.
To create a PSN, add and configure a third-supported network card to your
GVS9000 VTR. Since the PSN is hidden, unregistered IP addresses can be utilized this only apple when GVS9000 VTR is used for video streaming technology. Top |
The External network interface is the network device that
is attached to the External network (typically the Internet). The External
network interface requires a registered or legitimate IP address (if attached
to the Internet); only one registered IP address is required for the GVS9000 VTR system. The External network interface can have up to 300 IP addresses
using IP Aliasing. Top |
The Protected network interface is attached to the Protected
network. Any supported network device may be used with the exception of
the PPP device. The Protected network interface does not require a registered
IP address (RFC-1918; RFC 1918 addresses are recommended). The IP Aliasing
The facility may be used on the Protected network interface; with a maximum
of 300 IP aliases. Any supported network card may be used, (except for
PPP interface). Top |
The Private Service network (PSN;PSN) interface is optional.
Any supported network device may be used with the exception of the PPP
device. However, if you plan to offer public access to servers, such as
a web server, it is highly recommended that you install a PSN interface.
For many configurations of the GVS9000 VTR a PSN may not be required, such
as on intranets or for outbound access only. The PSN interface does not
require a registered IP address (RFC-1918; RFC-1918 addresses are recommended).
The IP Aliasing facility may be used on the PSN interface; with a maximum
of 300 IP aliases. Any supported network card may be used, (except for
PPP interface). Top |
A Tunnel is a GVS9000 VTR facility that allows a host on the
External or PSN network to be able to initiate a TCP, UDP, or ICMP session
with an otherwise inaccessible host (on the PSN or Protected networks)
for a specific Media service. This is done by mapping a visible IP address and
port (service) to a target IP address and port (service). This mapping can
be performed for all services (host-to-host tunneling) or more typically
for a given service. Common tunnels include SMTP (email), FTP, HTTP,
SQLnet and telnet. Tunnels can be created to hosts on both the PSN and
the Protected network. Only three types of tunnels can be created:
- From an IP address+port assigned (can be an IP alias) to the External NIC to a host IP address+port
on the Private Service network.
- From an IP address+port assigned (can be an IP alias) to the External NIC to a host IP address+port
on the Protected network.
- From an IP address+port assigned (can be an IP alias) to the Private Service NIC to a host IP
address+port on the Protected network.
Top |
An IP Alias is the GVS9000 VTR facility that allows any network
interface to have multiple IP addresses assigned. This facility is useful
if multiple targets on the PSN or Protected network are required for the
same service (port) via the Tunnel facility (e.g. multiple web servers).
GVS9000 VTR supports 300 aliases, which can be applied to any network interface.
All IP aliases must be registered or legitimate IP addresses if used
on the External network interface (connected to the Internet), although
they need not be from the same network. Top |
Network Address Translation, or NAT, is one of the primary
features of the GVS9000 VTR system. The NAT facility used in the GVS9000 VTR system
is always active by default. NAT is applied to outbound packets only:
- Outbound packets from the Protected Network to the External network
- Outbound packets from the Protected Network to the PSN.
- Outbound packets from the PSN to the External network
The NAT facility can be bypassed via the IP Pass-Through facility if
desired. NAT is available in two forms: dynamic translation and static
translation. The default NAT form is a dynamic many-to-one scheme, in
which packets from all IP addresses located on the source network (PSN
or Protected) have their source IP address translated to an IP address
assigned to the outbound NIC (External or PSN). This means:
- Any packet originating from the Protected network destined for a
host that resides external to the External NIC will have its source
IP address translated to the IP address of the External NIC.
- Any packet originating from the Protected network destine for a
host that resides external to the PSN
NIC will have its source IP address translated to the IP address of
the PSN NIC
- Any packet originating from the PSN network destined for a host that
resides external to the External
NIC will have its source IP address translated to the IP address of
the External NIC.
The other form of NAT that is available, is a static translation method, referred to in the GVS9000 VTR system as Mapping or static mapping. The Mapping facility allows the GVS9000 VTR administrator to specify a static mapping address scheme, such that a given address, network or subnet is mapped to a specific IP alias assigned to a specific network interface. Since the default dynamic NAT will translate IP address to the real IP address of the NIC by default, Mapping is only useful if you have assigned an alias(es) to the target NIC. Maps are assigned by associating a source address(es) to an alias assigned to a particular network interface (PSN or External). A netmask (not to be confused with the assigned network netmask), is ANDed with the specified source IP address to yield an IP number that is used for comparisons when applying static mapping. Top |
Mapping is a GVS9000 VTR facility that allows an internal IP
address or subnet to be statically mapped to an external IP address during
the network address translation process. Typically, mapping is used with
targets on the External network interface. Mapping is not useful unless
IP aliases have been assigned to the target network interface, since by
default all IP addresses on the Protected network are dynamically assigned
to the real IP address of the outbound network interface. This release
supports 300 static maps. Top |
IP Pass Through, is essentially the GVS9000 VTR term for “no
network address translation.” By default all packets passing through
the GVS9000 VTR outbound (to destinations that lie beyond the External or
the PSN network interfaces), have NAT applied to them. The IP Pass Through
facility provides a means to override the default action of applying NAT
and to transfer packets through the GVS9000 VTR without having NAT applied
to specific packets. The system creates IP pass-through tunnels, which
are determined by user-designed originating IP addresses. These designed
IP addresses can be networks, subnets or individual hosts on either the
PSN or the Protected networks.
IP pass-through can be selectively applied to packets based on the destination
of the packets. The IP Pass Through facility allows the user to specify
which network interface(s) will have not NAT applied for a designed IP
address(es). So for example, it is possible to apply IP pass-through for
specified packets destine to a host external to the PSN NIC, while packets
for a host external to the External NIC still have NAT applied.
The IP Pass Through facility can be defined to operate in the following
configurations:
- For packets from a host(s) on the Protected network outbound through
the PSN and External NICs.
- For packets from a host(s) on the Protected network outbound through
the PSN NIC only.
- For packets from a host(s) on the Protected network outbound through
the External NIC only.
- For packets from a host(s) on the PSN network outbound through the
External NIC only
By default IP pass-through designed IP addresses are configured for outbound use only. This default configuration does not allow unsolicited inbound connections to be accepted. Stateful information is maintained about IP pass-through sessions that originated from hosts on the PSN or Protected network outbound to guarantee that only IP packets that are replies to the initiated connections are accepted. If the connection protocol calls for a secondary inbound connection from an external host to be made to the originating internal host, virtual cracks are created to allow the secondary connection. This allows protocols
such as FTP to be used without arbitrary inbound connections.
IP pass-through designed IP addresses can also be configured to allow arbitrary external inbound connections to be initiated if desired. When configured to allow such inbound connections, IP pass-through filters need to be created to control inbound access.
IP pass-through and NAT can operate at the same time, however, a clear understanding of TCP/IP networking is a must, since these types of configurations can become complex and difficult to understand. Top |
Filters are a facility that controls network access through
and to the GVS9000 VTR. Filter rules are applied to all IP packets that are
received by or are desirous to pass through the GVS9000 VTR System. The GVS9000 VTR system supports three types of filters: Remote Access Filters, Outbound
Filters, and IP Pass Through Filters. The built-in implicit rule for the
GVS9000 VTR system is, “ That which is not expressly permitted is denied.”
Therefore, if no filters of any type were defined, packets would not be
allowed to flow to or through (inbound and outbound) the GVS9000 VTR system.
Basic GVS9000 VTR Filter Concepts
- Filter order is important because IP packets are processed against
the filter sets sequentially. Therefore,
it is very important to arrange your filters in the proper order,
otherwise, you may not achieve the
desired result.
- Filters are boolean in nature; they can only accept or deny a packet.
- Outbound Filters control access to IP addresses that reside external
to the External network interface
from hosts on the Protected and PSN networks.
- Outbound Filters control access to IP addresses that reside external
to the PSN network interface
from hosts on the Protected network.
- Remote Access Filters control access for packets that are directed
at one of the IP addresses assigned
to any GVS9000 VTR network interface.
- A Remote Access filter must be in place before a Tunnel can be accessed.
- IP Pass Through filters control access both inbound and outbound
to IP Pass Through designed IP
addresses, networks, subnets or hosts.
Each type of filter set may have up to 400 filters.
Each packet is compared to the appropriate filter set (Remote Access, Outbound
, or IP Pass Through), starting at filter number one in a specific set.
A comparison is performed sequentially against each filter until one of
two events occurs:
- A filter is matched, in which case the packet is either accepted
or denied based on the filter definition
and any filter actions associated with the filter are performed. No
further comparisons are performed.
- No filters are matched and the filter list is exhausted. In this
case, the packet is rejected.
Top |
All types of filters (Remote Access, Outbound, and IP Pass
Through) use the same filter definition specifications and comparison
parameters. The parameters used to perform the filter comparison are:
Source IP Address: The Source IP Address is used in conjunction with the
Source Netmask to yield an IP number for comparison to the source IP address
in the packet being filtered. The Source Netmask is logically ANDed with
an IP packet’s source address, the result is then compared to the
masked Source IP Address parameter.
Source Netmask: The source netmask used for filter definitions should
not be confused with the “ network netmask” as they have no
relation whatsoever. The source netmask is used in a filter definition in
conjunction with the Source IP Address and is used in a logical AND operation
to yield a set of host IP addresses for comparisons. Specifying a netmask
of 255.255.255.255 (all ones) when ANDed with an IP address will yield
only that specific address. A netmask specification of 255.255.255.0 will
yield a set of 255 addresses.
Source Port: The source port can be: a single port, multiple ports, or
a range of ports. The specified Source Port(s) are compared to the source
port of the IP packet to see if a match exists. If no Source Port is specified
then any source port is accepted. Typically the source port for most client
protocols is a random value above 1024. Destination IP Address: The Destination
IP Address is used in conjunction with the Destination Netmask to yield
an IP number for comparisons to the destination IP address in the packet
being filtered. The Destination Netmask is logically ANDed with an IP
packet’s destination address, the result is then compared to the
masked Destination IP Address parameter.
Source Netmask: The destination netmask used for filter definitions should
not be confused with the “ network netmask” as they have no
relation whatsoever. The destination netmask is used in a filter definition
in conjunction with the Destination IP Address and is used in a logical
AND operation to yield a set of host IP addresses for comparison. Specifying
a netmask of 255.255.255.255 (all ones) when ANDed with an IP address
will yield only that specific address. A netmask specification of 255.255.255.0
will yield a set of 255 addresses.
Destination Port: The destination port can be: a single port, multiple
ports or a range of ports. The specified Destination Port(s) are compared
to the destination port of the IP packet to see if a match exists. If no
Destination Port is specified then any destination port is accepted. Destination
ports are often called services since certain well-known services have
been assigned dedicated port numbers. Historically well know services,
typically those provided by servers were defined to be ports in the range
from 1 to 1024. However, with the explosive growth of the Internet, this
limited range of ports has been expended and new services have ports assigned
outside this range.
Network Interface: The network interface parameter allows a filter specification
to define which network interface the packet must have arrived on in order
to be matched. The valid values for the network interface are:
EXT - External Network interface
PRO - Protected Network interface
PSN - Private Service Network interface
ANY - Any network interface
Protocol: This parameter allows for the specification of a particular
IP protocol to be matched. The valid values for the protocol are: TCP, UDP,
ICMP, ALL, and any protocol a user may add to the user-specified protocol
list. If ALL protocols are specified then no ports (source or destination)
may be specified. User-specified protocols can only be used with a DENY
filter since GVS9000 VTR only supports and routes TCP, UDP, and ICMP. The current
use of user-specified protocols is to suppress noisy benign protocols
(which are implicitly blocked), from filling up log files. This function
is accomplished by creating a Deny filter with the “nolog”
option selected.
Time: Although not a comparison parameter, time of day and day of the week
are used to enable/disable a filter if a Time Group has been assigned
to the filter. Top |
Filter Actions are not a filter parameter for comparisons,
however, they are actions to be executed if the associated filter is matched.
Filter Actions are:
Email - An email message is generated which includes information about
the IP packet which matched the filter, a timestamp of the event, and
DNS name resolution (if a DNS server has been defined to the GVS9000 VTR and
the IP address can be resolved) and is sent to the email address defined
in the email preferences section typically the firewall administrator.
If multiple hits on the filter occur within a short span of time, all
packets will be detailed in a single email message. A maximum of 50 events
will be recorded in each email message, so multiple messages may be generated.
Stop Interface - This action should be used with extreme caution. If the
associated filter is matched the network interface on which the packet
arrived will be shutdown. No further packets will be received or allowed
to be sent out to the interface in question. User intervention is required
to bring the interface back up. This can be accomplished in two ways:
a system reboot or via the Interfaces dialog on either the Command Console
User Interface or via the web browser user interface.
Pager - This filter action requires that an optional modem be attached
to one of the supported serial interfaces (COM 1-4). This modem must be
dedicated to the pager function. The modem may be either an external or an
internal modem card. Only numeric pagers are supported. Because pager
systems can vary from country to country there is no guarantee that the
pager function will operate in all countries.
If the associated filter is matched and the optional pager facility has
been enabled and configured (via the preference dialog), then the defined
numeric pager message will be sent by calling the defined telephone number
via the pager modem.
SNMP Trap - This filter action will generate a generic SNMP trap and send
it to an SNMP management station if the associated filter is matched. The
SNMP option must be enabled (via the preference dialog), for this action
to operate. The SNMP management station is defined on the SNMP option
dialog screen.
Generate ICMP - This filter action will generate a “service unavailable”
ICMP message to the source IP address of the matched packet for the associated
filter.
Filter Action Notes
- Filter actions are not mutually exclusive, so you may select none,
one, or all of the actions on a given filter.
- It is important to understand clearly what each filter action does
since some actions can be rather severe, (i.e. Stop Interface).
- Filter actions can be selected on both Accept and Deny filters.
Top |
Remote Access Filters control the access of packets that
are directed at an IP address assigned (including IP aliases) to any of
the network interfaces on the GVS9000 VTR system. Remote Access Filters are
primarily used to control access to Tunnels since the source side of
a tunnel is always an IP address assigned to a GVS9000 VTR network interface
(EXT or PSN). Remember a Tunnel is only a conduit that associates a Protocol,
an IP address assigned to a GVS9000 VTR NIC, and a port number to an internal
IP address (on the PSN or Protected network) and port number. The Remote
Access filter is the facility that accepts or denies access to the Tunnel.
Remote Access filters also process packets destined for services on the
GVS9000 VTR such as the web browser user interface and proxy services (email
and URL blocking) if enabled. A maximum of 400 Remote Access filters are
allowed. Top |
Outbound Filters control access of packets directed to IP
addresses on the External network (typically the Internet) and to the
PSN (if one exists). As mentioned previously, the implicit filter rule
is “ that which is not expressly permitted is denied” applies
to outbound packets as well as inbound packets. When the GVS9000 VTR is initially
configured default Outbound filters will be created. The default Outbound
filter allows all IP addresses on the Protected network to access any
IP address and any service external to the Protected network. If a PSN
network interface exists, then an Outbound filter will be created that
allows all access to the External network (typically the Internet) from
the PSN. These filters can be modified or deleted to suit the local network
security policy for external network access.
To allow only specific external services to be accessed simply remove
the default Outbound filter(s) and add filters for the allowed services.
Any packet destined for a service not matching the allowed services will
be rejected by the implicit rule. GVS9000 VTR supports 400 Outbound Filters. Top |
IP Pass Through Filters control access to and from IP addresses
that have been specified as IP pass-through addresses. IP pass-through
filters, although similar to the other two filter types (Remote Access
and Outbound), is a bit different since they control both inbound and
outbound access to/from the designed IP Pass Through addresses. Since IP
pass-through addresses are not translated, the GVS9000 VTR functions as a
gateway for these addresses and therefore the IP Pass Through Filters
utilize IP Pass Through addresses in the filter definitions, not GVS9000 VTR
NIC addresses.
If IP pass through host/networks are defined, then pressing the “ Default”
button on the IP Pass Through filter screen will create a set of filters
based upon the IP pass-through addresses defined. Since IP pass-through
hosts/networks can be defined in a variety of different combinations, the
default filters will vary according to the options selected. These generated
filters are quite general and should be modified to match your security
requirements. 400 IP Pass Through filters is allowed. Top |
Since the GVS9000 VTR system provides network transparency for
users on the Protected and PSN networks, all DNS queries (outbound) operate
normally. Users on the Protected and PSN networks may use an external
DNS server for address resolution, however, it cannot be used to resolve
protected hosts. Since the GVS9000 VTR system hides all network addresses
on both the Protected and PSN networks, providing DNS information about
internal hosts to the external network is pointless as none of the IP
addresses on these networks are directly accessible from the External
network. GVS9000 VTR does not include a DNS server that runs on the system,
however, it can utilize a remote DNS server for IP address resolution.
When a DNS server is defined on the GVS9000 VTR system, many of the GVS9000 VTR
facilities will then accept both hostnames and IP addresses. If you have
an internal DNS server then it is suggested that it should be used by
the GVS9000 VTR for IP address resolution. Otherwise, any external DNS server
can be used. Top |
The GVS9000 VTR system provides transparent operation of many
VPN implementations. Two of the most common VPNs: Microsoft Corporation's
PPTP and Data Fellows SSH are supported transparently. Other VPN solutions,
such as hardware-based systems typically operate transparently with the
GVS9000 VTR system. Top |
Read the online tutorial PPTP and GVS9000 VTR. This tutorial
contains links to many excellent documents on PPTP and links to PPTP resources. Top |
The NAT facility used in the GVS9000 VTR system is always active
and is available in two forms: dynamic translation and static translation.
The default NAT form is a dynamic many-to-one scheme, in which all IP
addresses located on the Protected network (and all connected networks
attached) and the PSN is translated to a single IP address. This single
IP address is the primary address of the External network interface. The
another form of NAT that is available, is a static translation method, referred
to in the GVS9000 VTR system as Mapping. The Mapping facility allows the GVS9000 VTR administrator to specify a static mapping address scheme, such that
a given address or subnet is mapped to a specific IP address assigned
(aliased) to the External network interface.
The GVS9000 VTR performs an automatic many-to-one translation. All packets
passing through the GVS9000 VTR with a destination somewhere on the external
network (Internet) is translated so that their source IP address is that
of the external network interface's IP address. Simply put all packets
appear to come from the external network interface. When reply packet
return to the external network interface of the GVS9000 VTR they are inspected,
validated and translated back to the address of the originating host
on the Protected network. Top |
The recommended method is to place your web server on the
GVS9000 VTR's PSN network. Then create a tunnel from port 80 on the external
the network interface on the GVS9000 VTR to port 80 (http/web server) of your
the web server on the PSN network. The tunnel will only allow connections
to the port you specify, so you only expose the services you desire.
If you are not on the Internet or have some degree of trust of the external
network you can create a Tunnel to your web server on the Protected network.
Once again the Tunnel will only allow access to the specified port, (service)
on the target host. Top |
- External mail server
In this scenario, the mail server is external to the GVS9000 VTR. Since
the GVS9000 VTR is transparent to internal users, a host on the Protected
the network can connect normally to the mail server as it would on any
network. Many PC/Mac systems use POP3 protocol for receiving email
and SMTP for sending emails.
- Mail server on PSN
This is a good choice as the mail server is protected from the external
network and is only receiving connections from the external network
for mail deliveries. The mail server however is completely accessible
to the users on the Protected network, for sending and receiving email.
In this configuration a Tunnel is created that allows a connection
to the mail server on the PSN.
- . Internal mail server
This configuration should be implemented with caution especially when
the external network is the Internet. Although the mail server is
only listening for inbound mail deliveries any time you allow even
the slightest access from an untrusted network you are exposing your
network to possible unauthorized intrusion. In this configuration
a Tunnel is created that allows a connection to the mail server on
the Protected network.
Top |
GVS9000 VTR boots and runs from a 3.5" 1.44MB floppy diskette,
(no hard disk is required). The GVS9000 VTR runtime and utilities to create
the boot disk is supplied on a CD-ROM (ISO 9660 format), which should
be readable by most modern computer systems, (DOS/Win, Macintosh, and Unix).
Depending upon what kind of system you use to create the GVS9000 VTR boot
floppy diskette the procedure varies, however, the steps are generally
the same:
- Transfer the GVS9000 VTR runtime disk image to a 3.5" formatted
floppy diskette. (Use one of the
GVSBox utility programs).
- Insert the GVS9000 VTR diskette into the target hardware platform (your
GVS9000 VTR system).
- Boot the system.
- From the GUI interface assign IP addresses, netmasks, and options on
your network interfaces. Set the
default route. Press save.
- The system will complete the booting process into full runtime mode.
- Make any modifications or additions via the web browser interface.
Top |
The GVS9000 VTR supports the Unix syslog logging facility. The
syslog facility can be configured on the GVS9000 VTR to send logging information
to a host capable of receiving and processing syslog data. The GVS9000 VTR
sends: unauthorized access attempts, system notices, an open connection,
close connection and error conditions to the log host. The log priority
level, facility, and information to be logged is configurable.
If you would like to use a Win95/NT system to receive remote logging data,
use the GVS9000 VTR remote log client. This client is included in the GVS9000 VTR installer package. It is also available separately on the GVS9000 VTR
ftp server: syslog.zip Top |
The GVS9000 VTR performs a test to insure that packets are received
on the expected interface. This feature looks up the route back to the
source of received IP packets. If there is no route to the source available,
or the packet did not arrive on the expected interface the packet is discarded.
The expected interface is the one that would be used to send a packet
back to the reported source of the packet. Top |
Yes, GVS9000 VTR provides protection against denial of services
attacks such as Ping of Death, smurf, SYN flood, and Land. c and Teardrop Top |
GVS9000 VTR has support for DHCP. DHCP is only available on
all network interfaces External, PSN, and Protected interfaces. DHCP is
available on the external network primarily for cable modem and xDSL users
since dynamic address assignment is used for this type of interface. Top |
|
