rinetd(8)

💅 rinetd — internet redirection server 💅

hey bestie, welcome to the System Manager's Manual page for rinetd, section 8. it's giving "quietly running your whole network since 1997" and honestly? iconic. let's get into it 🦋

---

✨ NAME ✨

rinetd — internet redirection server 🌈

---

🌸 SYNOPSIS 🌸

rinetd [-f] [-c configuration]
rinetd -h
rinetd -v

---

💖 DESCRIPTION 💖

okay so here's the whole vibe: rinetd redirects TCP or UDP connections from one IP address and port to another. that's it, that's the job. 💫

it's a single-process server that handles literally any number of connections to the address/port pairs you list in the file /etc/rinetd.conf. and because it runs as one single process using nonblocking I/O, it can redirect a huge number of connections without doing severe damage to your machine. which means — and this is the slay part — it's actually practical to run services on machines that live inside an IP masquerading firewall. no cap. 👑

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

/usr/sbin/rinetd

the config file it reads lives at /etc/rinetd.conf, unless you point it somewhere else with the -c command line option. 🎀

---

⭐ OPTIONS ⭐

• -f — run rinetd in the foreground, without forking to the background. it stays right there with you. 🫶
• -c configuration — specify an alternate configuration file. your config, your rules, your main character moment.
• -v — display the version number and exit. quick little flex and then it's gone. 💨
• -h — produce a short help message and exit. a lil "here's the tea" and then bye. 🙈

---

🔥 FORWARDING RULES 🔥

most entries in the configuration file are forwarding rules. the format of a forwarding rule is as follows:

bindaddress bindport connectaddress connectport [options...]

for example:

206.125.69.81 80  10.1.1.2 80

this would redirect all connections to port 80 of the "real" IP address 206.125.69.81 — which could totally be a virtual interface — through rinetd to port 80 of the address 10.1.1.2. and that 10.1.1.2 would typically be a machine on the inside of a firewall which has no direct routing to the outside world. so you're basically the bridge between two worlds. a social network, but for packets ✨

binding to a specific IP address is one of rinetd's primary features, but sometimes it's preferable to respond on all IP addresses that belong to the server. in that situation, you can use the special IP address 0.0.0.0. for example:

0.0.0.0 23  10.1.1.2 23

this would redirect all connections to port 23, for all IP addresses assigned to the server. and ngl, this is the default behavior for most other programs — so if it feels familiar, that's why. 💀

ports default to TCP. to specify the protocol, append /udp or /tcp to the port number:

206.125.69.81 80/tcp  10.1.1.2 8000/udp

service names can be specified instead of port numbers. on most systems, service names are defined in the file /etc/services. so yes, you can be ✨fancy✨ about it.

both IP addresses and hostnames are accepted for bindaddress and connectaddress, including IPv6. we love inclusivity. 💜

🕐 UDP timeout option

since UDP is a connectionless protocol, a timeout is necessary — otherwise forwarding connections may accumulate over time and exhaust resources. and we are not doing resource exhaustion today, bestie. 😭

by default, if no data is sent or received on a UDP connection for 72 seconds, the other connection is closed. this value can be changed using the timeout option:

0.0.0.0 8000/udp  10.1.1.2 80  [timeout=3600]

this rule will forward all data received on UDP port 8000 to host 10.1.1.2 on TCP port 80, and will close the connection after no data is received on the UDP port for 3600 seconds. patient but not infinitely patient. periodt. ⏳

🎯 Source address option

a forwarding rule option allows one to bind to a specific local address when sending data to the other end. this is done using the src option:

192.168.1.1 80  10.1.1.127 80  [src=10.1.1.2]

assuming the local host has two IP addresses, 10.1.1.1 and 10.1.1.2, this rule ensures that forwarded packets are sent using source address 10.1.1.2. it's called ✨picking a lane✨ and honestly we respect it. 🦋

---

🚫 ALLOW AND DENY RULES 🚫

configuration files can also contain allow and deny rules. this is the bouncer-at-the-club section. 💅

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 deny 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|deny 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. so * is the wildcard that says "idk, whoever, I'm not picky." 🙈

for example:

allow 206.125.69.*

this allow rule matches all IP addresses in the 206.125.69 class C domain. cute, tidy, contained. 🎀

host names are NOT permitted in allow and deny rules. the performance cost of looking up IP addresses to find their corresponding names is prohibitive. since rinetd is a single process server, all other connections would be forced to pause during the address lookup. so no, you can't put a hostname there, and the reason is that everybody else would have to sit and wait. it's giving "one slow person in the group chat holding up the whole brunch reservation." 💀

---

📓 LOGGING 📓

rinetd is able to produce a log file in either of two formats: tab-delimited and web server-style "common log format". two aesthetics, pick your fave. 🫶

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 following line to the configuration file:

logcommon

and that's it. log unlocked. ✨

---

🔄 REINITIALIZING RINETD 🔄

the kill -1 signal (SIGHUP) can be used to cause rinetd to reload its configuration file without interrupting existing connections. glow-up with zero downtime, we love to see it. 👑

under Linux™ the process id is saved in the file /var/run/rinetd.pid to facilitate the kill -HUP. an alternate filename can be provided by using the pidlogfile configuration file option. so if you want your pid file somewhere else, you absolutely can. 💜

---

🐛 BUGS AND LIMITATIONS 🐛

okay bestie, time for the fine print. we keep it real here. 😭

• rinetd only redirects protocols which use a single TCP or UDP socket. this rules out FTP. sorry FTP girlies, it's not personal, it's protocol-structural. 💀
• the server redirected to is not able to identify the host the client really 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 connection should be logged. yes, that's a real limitation and we're saying it out loud. 🙈

---

📜 LICENSE 📜

Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.

Copyright (c) 2003-2021 Sam Hocevar

this software is released for free use under the terms of the GNU General Public License, version 2 or higher. NO WARRANTY IS EXPRESSED OR IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK. so like, slay, but also be careful. 💅

---

📬 CONTACT INFORMATION 📬

see https://github.com/samhocevar/rinetd/releases for the latest release. go get the fresh version, bestie. 🦋

Thomas Boutell can be reached by email: boutell@boutell.com

Sam Hocevar can be reached by email: sam@hocevar.net

---

💐 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. legends, all of them. 🫶

---

and that's the whole page!! this was rinetd version 0.73, dated 2021-02-19, living its best life in section 8 of the System Manager's Manual. go redirect something responsibly, mwah 💖✨🎀