Service Proxy Commands

These commands instruct the NetNAT to create new mapping relationships between apparent external services and actual internal services. The mapping relationships may be port-and-protocol conscious, or port independent. In addition to these four modes, our NATs perform Dynamic Mapping of client IP Addresses into a single public IP Address. This is performed automatically between "private" interfaces and "public" ones, so no commands are shown.

Port Service Proxy

This service subcommand establishes a service-specific relationship between an apparent IP Address/Port Number/Protocol (UDP or TCP) combination on a public interface and an actual IP Address/Port Number combination on a private interface.

Any service request from the public area that is addressed to the apparent IP Address/Port Number combination is redirected to the actual service provider on the private network. Conversely, all reply messages from the actual IP Address/Port Number/Protocol combination are rewritten to appear to originate at the apparent public combination. All affected checksums are recalculated in the messages before they are transmitted.

A special wildcard for the apparent IP Address is provided, to simplify maintenance of the startup configuration as the public address changes. By specifying an asterisk (*) for the apparent IP Address, you are actually specifying the "natural" IP Address of the interface, which has been set either in an ifconfig command, or has been negotiated during a PPP session setup.

Command Syntax

  service [int] port [app IP|*] [app port] [TCP|UDP] [act IP] [act port] {flags}
Where:

Fixed Service Proxy

This service subcommand establishes a service-independent relationship between an apparent IP Address on a public interface, and an actual IP Address on the private side.

Any service request from the public area that is addressed to the apparent IP Address is redirected to the actual service provider on the private network. Conversely, all reply messages from the actual IP Address (the actual server) are rewritten to appear to originate at the apparent public address.

Service requests that originate at the designated private "actual" server, such as telnet, ftp, www, etc., are rewritten to appear to originate at the apparent public address, also.

All affected checksums are recalculated in the messages before they are transmitted.

Command Syntax

  service [int] fixed [app IP] [act IP] {flags}
Where:

Default Service Proxy

This service subcommand establishes a last-resort default for service requests that have not been handled otherwise. An organization that suspects that Internet Bad Guys (IBGs) may be attempting to invade their system wish to set up a highly-instrumented host, and point the NAT's Default Service Proxy filter at it. In this way, the NAT will not reject the connection attempts offhand, but will route them through to this instrumented internal machine for examination.

Because the NAT routes all undefined services to this default machine, the use of the Default Service Proxy facility must be considered carefully. If mistakenly configured to send to an unprotected machine, your Firewall functionality will be compromised.

Any service request from the public area that is addressed to the apparent IP Address, and that is not otherwise handled by a Service Port Proxy relationship, is redirected to the configured service provider on the private network. Conversely, all reply messages from the actual IP Address (the actual server) are rewritten to appear to originate at the apparent public address.

All affected checksums are recalculated in the messages before they are transmitted.

Command Syntax

  service [int] default [app IP] [act IP] {flags}
Where:

Subnet Address Mapping

This service subcommand designates a public "apparent" IP Address to be shared by all computers in a private subnet. This permits an ISP (for example) to assign a single public IP Address for use by all computers at a customer site.

Command Syntax

  service [int] subnet [subnet address/bits] [app IP]
  service [int] client [subnet address/bits] [app IP]
Where: When a client computer sends a message through the NAT to the outside world, the NAT must select an IP Address to use for that client, for this message. This command specifies that a certain IP Address will be used for everybody in the specified subnet. They may all be active at the same time, since we use port translation to permit them to share the IP Address simultaneously.

The two forms of the command are equivalent. The original name for the command was "service client" but is being changed to "service subnet" to make its meaning more clear. The subnet may be as restrictive as desired, allowing you to assign an apparent IP Address to a single computer if desired. For example: 

service en0 subnet 192.168.31.4/32 204.204.19.18
service en0 subnet 192.168.31.0/24 204.204.19.19
This instructs the NAT to use 204.204.19.18 for the single computer at 192.168.31.4, and use 204.204.19.19 for everybody else in that subnet. At present, you may have up to 32 subnet mapping definitions in your NAT configuration.

Local Service Proxy

This service subcommand designates that the specified service is processed by the NAT itself, rather than by a device on the private network. An example would be SNMP or FTP, if permitted by the NAT. The NAT code detects the inbound service request and, when it notices the "local proxy" entry in the proxy table, checks for local listeners on the specified port. If there are none, the service request is rejected.

Command Syntax

  service [int] local [app IP] [app port] [TCP|UDP] {flags}
Where:

Monitoring and Logging Flags

These flag bits control the logging (via syslog) of significant events and of data volumes. At present, all logging uses facility "LOCAL2" and priority "INFO," but these will become configurable in a future release.

Flag Bits

At present, only the two most-significant bits are used. 
  ---------------//---------------
  | E | V |          unused      |
  ---------------//---------------
Where:

Syslog Record Formats

Formats of log records are as follows. Your syslog daemon will add the date and time, and the name of the NAT (or IP Address, if not in your DNS) at the beginning of each log record. All fields are colon-delimited for easy processing off-line. IP Addresses are 32-bit hexadecimal, flags are 16-bit hexadecimal. All other numeric fields are in decimal.

Proxy Event

This logs initial inbound connection events for port-style service proxy facilities. One should be careful with this, as it could create a lot of log information. It is enabled by setting the msb of the flags field (0x8000 or 0xc000 both have this bit set, 0x0000 and 0x4000 don't). 
  pr:int:srcip:srcport:dstip:dstport:prot
Where:

Default Proxy Event

This logs initial inbound connection events for default-style service proxy facilities. While one should be careful with this, due to the possibility of a massive number of events logged, this one can be very interesting. It logs redirection of protocols that you didn't anticipate. Typical examples are the "Authentication Protocol," where telnet servers attempt to learn more about the client user. It is enabled by setting the msb of the flags field (0x8000 or 0xc000 both have this bit set, 0x0000 and 0x4000 don't). 
  df:int:srcip:srcport:dstip:dstport:prot
Where:

Reject Proxy Event

This logs initial inbound connection events that are rejected because they didn't match any of the pre-established Service Proxy relationships. In other words, this logs deflected queries for services that you did not intend to provide. Typical examples are the "Authentication Protocol," where telnet servers attempt to learn more about the client user. It is enabled by the Syslog Reject command. This logging mode can generate a lot of data, so use it with care. 
  rj:int:srcip:srcport:dstip:dstport:prot
Where:

Service Proxy Statistics

If enabled, this logs data volumes in and out for a service proxy relationship. The log record is sent only when actual data traffic has occurred. It is sent each minute when a non-zero value can be reported. It can generate a lot of data, so use it with care, or be thoughtful in selecting which proxies are monitored. 
  ps:int:appip:appport:actip:actport:prot:flags:bin:cin:bout:cout
Where:

NAT UP Message

If a syslog server is defined, all of our NATs will report "up" status via syslog approximately one minute after starting. The delay is to allow the various facilities to settle. The purpose of this is to track the number of reboots, without regard for the reason, since it's almost always too late to find out why. The common reasons for a reboot are: The format of the UP message is: 
  up:hostname
Where "hostname" is the hostname as specified in a hostname command.
This page was last modified on 14 March, 1997.

This information is proprietary to Network Safety Corporation. Network Safety, WebElite, DialNAT and NetNAT are trademarks of Network Safety Corporation. For information on our products and services, please contact our sales department.

This page was prepared using WebElite, our professional editor for the Web.