Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
RINETD(8)		  BSD System Manager's Manual		     RINETD(8)

NAME
     rinetd -- internet	"redirection server"

SYNOPSIS
     /usr/local/sbin/rinetd

VERSION
     Version 0.62, 04/14/2003.

DESCRIPTION
     rinetd redirects TCP connections from one IP address and port to another.
     rinetd is a single-process	server which handles any number	of connections
     to	the address/port pairs specified in the	file /usr/lo-
     cal/etc/rinetd.conf.  Since rinetd	runs as	a single process using non-
     blocking I/O, it is able to redirect a large number of connections	with-
     out a severe impact on the	machine. This makes it practical to run	TCP
     services on machines inside an IP masquerading firewall. rinetd does not
     redirect FTP, because FTP requires	more than one socket.

     rinetd is typically launched at boot time,	using the following syntax:

     /usr/local/sbin/rinetd

     The configuration file is found in	the file /usr/local/etc/rinetd.conf,
     unless another file is specified using the	-c command line	option.

FORWARDING RULES
     Most entries in the configuration file are	forwarding rules. The format
     of	a forwarding rule is as	follows:

     bindaddress bindport connectaddress connectport

     For example:

     206.125.69.81 80 10.1.1.2 80

     Would redirect all	connections to port 80 of the "real" IP	address
     206.125.69.81, which could	be a virtual interface,	through	rinetd to port
     80	of the address 10.1.1.2, which would typically be a machine on the in-
     side of a firewall	which has no direct routing to the outside world.

     Although responding on individual interfaces rather than on all inter-
     faces is one of rinetd's primary features,	sometimes it is	preferable to
     respond on	all IP addresses that belong to	the server.  In	this situa-
     tion, the special IP address 0.0.0.0 can be used. For example:

     0.0.0.0 23	10.1.1.2 23

     Would redirect all	connections to port 23,	for all	IP addresses assigned
     to	the server. This is the	default	behavior for most other	programs.

     Service names can be specified instead of port numbers. On	most systems,
     service names are defined in the file /etc/services.

     Both IP addresses and hostnames are accepted for bindaddress and connec-
     taddress.

ALLOW AND DENY RULES
     Configuration files can also contain allow	and deny rules.

     Allow rules which appear before the first forwarding rule are applied
     globally: if at least one global allow rule exists, and the address of a
     new connection does not satisfy at	least one of the global	allow rules,
     that connection is	immediately rejected, regardless of any	other rules.

     Allow rules which appear after a specific forwarding rule apply to	that
     forwarding	rule only. If at least one allow rule exists for a particular
     forwarding	rule, and the address of a new connection does not satisfy at
     least one of the allow rules for that forwarding rule, that connection is
     immediately rejected, regardless of any other rules.

     Deny rules	which appear before the	first forwarding rule are applied
     globally: if the address of a new connection satisfies any	of the global
     allow rules, that connection is immediately rejected, regardless of any
     other rules.

     Deny rules	which appear after a specific forwarding rule apply to that
     forwarding	rule only. If the address of a new connection satisfies	any of
     the deny rules for	that forwarding	rule, that connection is immediately
     rejected, regardless of any other rules.

     The format	of an allow rule is as follows:

     allow pattern

     Patterns can contain the following	characters: 0, 1, 2, 3,	4, 5, 6, 7, 8,
     9,	. (period), ?, and *. The ? wildcard matches any one character.	The *
     wildcard matches any number of characters,	including zero.

     For example:

     allow 206.125.69.*

     This allow	rule matches all IP addresses in the 206.125.69	class C	do-
     main.

     Host names	are NOT	permitted in allow and deny rules. The performance
     cost of looking up	IP addresses to	find their corresponding names is pro-
     hibitive. Since rinetd is a single	process	server,	all other connections
     would be forced to	pause during the address lookup.

LOGGING
     rinetd is able to produce a log file in either of two formats: tab-delim-
     ited and web server-style "common log format."

     By	default, rinetd	does not produce a log file. To	activate logging, add
     the following line	to the configuration file:

     logfile log-file-location

     Example: logfile /var/log/rinetd.log

     By	default, rinetd	logs in	a simple tab-delimited format containing the
     following information:

     Date and time

     Client address

     Listening host

     Listening port

     Forwarded-to host

     Forwarded-to port

     Bytes received from client

     Bytes sent	to client

     Result message

     To	activate web server-style "common log format" logging, add the follow-
     ing line to the configuration file:

     logcommon

COMMAND	LINE OPTIONS
     The -c command line option	is used	to specify an alternate	configuration
     file.

     The -h command line option	produces a short help message.

     The -v command line option	displays the version number.

REINITIALIZING RINETD
     The kill -1 signal	(SIGHUP) can be	used to	cause rinetd to	reload its
     configuration file	without	interrupting existing connections.  Under
     Linuxtm the process id is saved in	the file /var/run/rinetd.pid to	facil-
     itate the kill -HUP. An alternate filename	can be provided	by using the
     <code>pidlogfile</code> configuration file	option.

LIMITATIONS
     rinetd redirects TCP connections only. There is no	support	for UDP.
     rinetd only redirects protocols which use a single	TCP socket. This rules
     out FTP.

BUGS
     The server	redirected to is not able to identify the host the client re-
     ally came from. This cannot be corrected; however,	the log	produced by
     rinetd provides a way to obtain this information. Under Unix, Sockets
     would theoretically lose data when	closed with SO_LINGER turned off, but
     in	Linux this is not the case (kernel source comments support this	belief
     on	my part). On non-Linux Unix platforms, alternate code which uses a
     different trick to	work around blocking close() is	provided, but this
     code is untested. The logging is inadequate.  The duration	of each	con-
     nection should be logged.

LICENSE
     Copyright (c) 1997, 1998, 1999, Thomas Boutell and	Boutell.Com, Inc.
     This software is released for free	use under the terms of the GNU Public
     License, version 2	or higher. NO WARRANTY IS EXPRESSED OR IMPLIED.	USE
     THIS SOFTWARE AT YOUR OWN RISK.

CONTACT	INFORMATION
     See http://www.boutell.com/rinetd/	for the	latest release.	 Thomas
     Boutell can be reached by email: boutell@boutell.com

THANKS
     Thanks are	due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, the
     Apache Group, and many others who have contributed	advice and/or source
     code to this and other free software projects.

LINUX			       February	18, 1999			 LINUX

NAME | SYNOPSIS | VERSION | DESCRIPTION | FORWARDING RULES | ALLOW AND DENY RULES | LOGGING | COMMAND LINE OPTIONS | REINITIALIZING RINETD | LIMITATIONS | BUGS | LICENSE | CONTACT INFORMATION | THANKS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=rinetd&sektion=8&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help