|
Introduction
Because
Sybergen's technology is based on Network Address Translation
(NAT) and also because Sybergen Access Server and SyGate
offer firewall
security, you must specify to our software a set of parameters
on what ports to use and how to use them for certain applications.
This configurability known as Apprules give
configurability far beyond what other products on the
market today offer.
For
most Internet applications, a client machine makes a request
that opens a channel (port) on the server machine and a
response is returned from the intended party on the Internet
through that same channel - communication is established.
For some Internet applications, a client machine makes a
request that opens one port and the intended party then
responds through a different port (which is closed).
Sybergen Access Server or SyGate then protects your network by not allowing information to come
into your network on ports that are closed. Therefore, the
returning information is dropped - and communication is
broken. There are 65613 ports available in which to communicate.
Note:
The Apprule.cfg file ONLY applies to the networked client computers
and does not apply to the server or gateway computer. The
server computer's Internet abilities are not affected
by our server software being installed on it unless "enhanced security
mode" is enabled - which will block incoming connections
to that computer. Sybergen's "enhanced security mode" only
applies to the server computer and does not apply
to the networked client computers.
If
you would like updated settings for the Apprule.cfg file. We
keep updated information online at Application
Rules for Sybergen Access Server or SyGate.
Considerations
If
you wish to setup an application such as a web page server,
file server or email server, we've defined several sets
of apprules already that you can enable to make this work.
Another consideration to take into effect is that when you
enable an apprule, you're essentially opening ports for
the Internet to get into your network - which can be a potential
security risk. Apprules can be specified to open certain
ports only for a specified period of time after a client
computer has initiated an application that is defined within
an apprule - and then to close the specified port so that
it can't be access from the Internet. The Apprule.cfg file
is located in the same directory that the server software is
installed in.
Modifying this file can configure our software to open certain
ports so that special applications can run through the
server to the networked clients.
The Apprule.cfg file enables our software to support FTP in active
mode, Net2Phone, NetMeeting, InternetPhone, StarCraft, Quake
II, Kali, DCC of IRC, hosting FTP and web server on SyGate
client, hosting pcANYWHERE server on networked clients.
Below
is an example apprule that is defined in the default Apprule.cfg
file.
#
Net2Phone
:INIT "NetPhone2"
OUT UDP 6801 6801 0.0.0.0 0 -
:SUB
IN UDP 6613 6613 0.0.0.0 0 0 AD
IN TCP 6613 6613 0.0.0.0 0 0 AD
:END
#
Net2Phone
This
is a comment line. Any line starting with '#' makes it a
comment line which is used only for notation and remarks
and not actually a part of the apprule.
:INIT
"NetPhone2
OUT UDP 6801 6801 0.0.0.0 0 -
The
first line tells the server software to initiate a new Apprule and designates
a name for it. The next line indicates the "triggering"
transaction. For the example above, this rule will be effetive
when a client sends OUT a UDP packet with the destination
port as 6801 - the TCP/IP address of 0.0.0.0 means it can
be any networked client on the network.
:SUB
IN UDP 6613 6613 0.0.0.0 0 0 AD
IN TCP 6613 6613 0.0.0.0 0 0 AD
:END
This
indicates the Sub-transaction - what to do after the triggering
transaction is performed. For the example above, the
server software will create a dynamic tunnel for IN coming UDP packets at
port 6613 and IN coming TCP packets for 6613. Since 0.0.0.0
is also specified here, the incoming packets will be passed
back to the client which initiated the transaction.
Formal
Syntax
Apprule.cfg
defines a list of rules for the server software to follow when processing
packets. According to each rule, the server software will dynamically
create a series of tunnels to provide a path for packets
to flow through.
An
application rule consists of:
:INIT
<Rule Name>
Triggering Transaction
:SUB
Sub-trans-1
Sub-trans-2
:END
Where:
-
<Rule
Name> is the name of the application. It could be
any name. See example for detail.
-
Triggering
Transaction is the first traffic the application generates
-
Sub-trans-x
and Triggering Transaction could be "Inbound Trans"
and "Outbound Trans" defined below respectively.
Inbound
Trans Syntax:
Direction
ProtocolType DestinationPortLow DestinationPortHigh
ClientIP ClientPort MaxIdleTime Options
Description:
|
Direction: |
IN |
| ProtcolType: |
TCP
or UDP |
| DestinationPortHigh: |
The
upper bound of the destination port range |
| DestinationPortLow: |
The
lower bound of the destination port range |
| Note:
INIT Trans can have only one designated port at this
time. Both DestinationPortHigh and DestinationPortLow
above should be the same. |
| ClientIp: |
This
field tells the server where to pass the incoming packets
with the destination port in the range defined by
DestinationPortHigh and DestinationPortLow. This field
has to be set to 0.0.0.0 for Sub-trans-x. For Triggering
Transaction, this field must be set to the IP of one
of the clients. |
| ClientPort: |
This
field tells the server which port of the ClientIp to send
the incoming packet with the destination port in the
range defined by DestinationPortHigh and DestinationPortLow.
If this value is 0, the packet will be sent to the
same port as the destination port of the incoming
packet. If this value is not zero, the packet will
be sent to the defined port instead of the original
destination port. Example - by doing this we can redirect
the packets sent to port 8080 of the server to port 80
of the networked client computer (192.168.0.2) by using IN TCP
8080 8080 192.168.0.2 80 0 - |
| MaxIdleTime:
|
This
field tells the server to close the tunnel after certain
idle miniseconds. Set to 0 for the server to use the default
idle timeout value. |
|
Options:
|
|
| - |
None |
| M |
This
value tells the server to close all Sub-tunnels if the
triggering connection no longer exists due to either
timeout or user application disconnect, etc. This
option is only valid in Triggering Transaction. |
| H |
H.323
specfic rule. The server will process the packets according
to H.323 protocol. Users should not use this option
to define new rules |
| A
|
This
option tells the server to pass packets from any remote
hosts to specific port defined in the rule.
If this option is not specified, only the packets
from the remote host that the Triggering Transaction
visited can be passed to the ClientPort of the
triggering client. See "StarCraft" rule for more details. |
| D |
This
option can only be used in Sub-Trans-x. It tells the
server to keep creating tunnels for each connection between
the triggering networked client and remote hosts. Without
this option, only one tunnel can be created for each
Sub-Trans-x rule. See "StarCraft" rule for more details. |
Outbound Trans Syntax:
Direction
ProtocolType DestinationPortLow DestinationPortHigh
ClientIp MaxIdleTime Options
Description:
| Direction:
|
OUT |
| ProtcolType: |
TCP
or UDP |
| DestinationPortHigh: |
The
upper bound of the destination port range |
| DestinationPortLow:
|
The
lower bound of the destination port range |
| ClientIp:
|
This
field tells the server which client can trigger the rule.
In Trigger Tansaction, 0.0.0.0 means any client can
trigger. In Sub-Trans-x, ClietnIP has to be 0.0.0.0
|
| MaxIdleTime: |
This
field tells the server to close the tunnel after certain
idle miniseconds. Set to 0 for the server to use the default
idle timeout value. |
| Options: |
|
|
-<
|
None |
| M |
This
value tells the server to close all Sub-tunnels if the
triggering connection no longer exists due to either
timeout or user application disconnect, etc. This
option is only valid in Triggering Transaction. |
| R |
This
option tells the server to use a different source port
to send the packet. See "StarCraft" rule for more
details. |
| H |
H.323
specfic rule. The server will process the packets according
to H.323 protocol. Users should not use this option
to define new rules. |
| F |
FTP
activity mode specfic. Users should not use this option
to define new rules. |
| I
|
IRC
DCC mode specifc. Users should not use this option
to define new rules. |
| D |
This
option can only be used in Sub-Trans-x. It tells the
server to keep creating tunnels for each connection between
the triggering networked client and remote hosts. Without
this option, only one tunnel can be created for each
Sub-Trans-x rule. The "StarCraft" rule below is an
example...
#
QuickTime 4 Server
Replace 192.168.0.3 with the IP address of
your QuickTime 4 Server
:INIT "QuickTime 4"
IN TCP 6970
6970 192.168.0.3
0 AD
SUB
IN UDP 6970
7000 0.0.0.0
0 AD
:END
|
|
Tools
Packet
Listener
Packet Listener is a utility you can use to identify
IN coming and OUT going packets that can help you
to create a custom apprule. To use this utility,
you MUST run BOTH the Packet Listener and your special
application on the machine running the server
software.
It will monitor the ports while your special application
is running and grab the first 500 packets. With
this information, you may be able to see what the
special application is trying to do - and
then build your own apprule to allow that application
to be run from the client computers on your network.
Note:
When you run the Packet Listener, it will
automatically stop the server software's service. After using
this utility, you should manually start the server
software's service using the start button in the
Manager program.
Download
SyPkt.exe to the desktop of the computer running
the server software.
Double click on SyPkt.exe on your desktop.>
Click on the Start button within Packet Listener.
Open your special application and start your
connection.
Watch the Packet Listener to make sure that
the buffer is grabbing packets - and keep using
your special application until either the buffer
is full or you've achieved the results you need
from your application.
Within the Packet Listener, if the
buffer isn't full in Packet Listener, click the
stop button.
Within the Packet Listener, click on the
details button. This should drop down a window to
show you all of the transactions that have taken
place as follows...
UDP:
192.168.0.1:4319 --> 200.202.298.160:53
UDP: 200.202.298.160:53 --> 192.168.0.1:4319
TCP: 192.168.0.1:4320 --> 200.202.298.160:80
TCP: 200.202.298.160:80 --> 192.168.0.1:4320
etc.
In
the example above, the computer running the server
software initiated
a transaction - assigned a random port (4319) and
attempted an OUT going UDP connection at port 53
to 200.202.298.160. That IP address then returned
to SyGate IN on the same port 53. The next transaction
assigned a random port (4320) and attempted an OUT
going TCP connection at port 80 to 200.202.298.160.
That IP address then returned to the server IN on the
same port 80. This example is a DNS connection followed
by an HTTP connection.
|
|
|
| 
