[Previous: Network Address Translation] [Contents] [Next: Packet Filtering]

PF: Redirection (`rdr`)

Introduction
Redirection and Packet Filtering
Security Implications
Redirection and Reflection

Introduction

When you have NAT running in your office you have the entire Internet available to all your machines. What if you have a machine behind the NAT gateway that needs to be accessed from outside? This is where redirection comes in. Redirection allows incoming traffic to be sent to a machine behind the NAT gateway.

Let's look at an example:

rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20

This line redirects TCP port 80 (web server) traffic to a machine inside the network at 192.168.1.20. So, even though 192.168.1.20 is behind your gateway and inside your network, the outside world can access it.

The from any to any part of the above rdr line can be quite useful. If you know what addresses or subnets are supposed to have access to the web server at port 80, you can restrict them here:

rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \ 192.168.1.20

This will redirect only the specified subnet. Note this implies you can redirect different incoming hosts to different machines behind the gateway. This can be quite useful. For example, you could have users at remote sites access their own desktop computers using the same port and IP address on the gateway as long as you know the IP address they will be connecting from:

rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \ 192.168.1.20 rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \ 192.168.1.22 rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \ 192.168.1.23

Redirection and Packet Filtering

Be aware that packets matching an rdr rule still must pass through the filtering engine and will be blocked or passed based on the filter rules that have been defined. Also be aware that packets matching an rdr rule will have their destination IP address and/or destination port changed to match the redirection address/port specified in the rdr rule. Consider this scenario:

192.0.2.1 - host on the Internet
24.65.1.13 - external address of OpenBSD router
192.168.1.5 - internal IP address of web server

Redirection rule:

rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \ -> 192.168.1.5 8000

Packet before the rdr rule is processed:

Source address: 192.0.2.1
Source port: 4028 (arbitrarily chosen by the operating system)
Destination address: 24.65.1.13
Destination port: 80

Packet after the rdr rule is processed:

Source address: 192.0.2.1
Source port: 4028
Destination address: 192.168.1.5
Destination port: 8000

The filtering engine will see the IP packet as it looks after rdr rules have been processed.

Security Implications

Redirection does have security implications. Punching a hole in the firewall to allow traffic into the internal, protected network potentially opens up the internal machine to compromise. If traffic is forwarded to an internal web server for example, and a vulnerability is discovered in the web server daemon or in a CGI script run on the web server, then that machine can be compromised from an intruder on the Internet. From there, the intruder has a doorway to the internal network, one that is permitted to pass right through the firewall.

These risks can be minimized by keeping the externally accessed system tightly confined on a separate network. This network is often referred to as a Demilitarized Zone (DMZ) or a Private Service Network (PSN). This way, if the web server is compromised, the effects can be limited to the DMZ/PSN network by careful filtering of the traffic permitted to and from the DMZ/PSN.

Redirection and Reflection

Often, redirection rules are used to forward incoming connections from the Internet to a local server with a private address in the internal network or LAN, as in:

server = 192.168.1.40 rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \ port 80

But when the redirection rule is tested from a client on the LAN, it doesn't work. The reason is that redirection rules apply only to packets that pass through the specified interface ($ext_if, the external interface, in the example). Connecting to the external address of the firewall from a host on the LAN, however, does not mean the packets will actually pass through its external interface. The TCP/IP stack on the firewall compares the destination address of incoming packets with its own addresses and aliases and detects connections to itself as soon as they have passed the internal interface. Such packets do not physically pass through the external interface, and the stack does not simulate such a passage in any way. Thus, PF never sees these packets on the external interface, and the redirection rule, specifying the external interface, does not apply.

Adding a second redirection rule for the internal interface does not have the desired effect either. When the local client connects to the external address of the firewall, the initial packet of the TCP handshake reaches the firewall through the internal interface. The redirection rule does apply and the destination address gets replaced with that of the internal server. The packet gets forwarded back through the internal interface and reaches the internal server. But the source address has not been translated, and still contains the local client's address, so the server sends its replies directly to the client. The firewall never sees the reply and has no chance to properly reverse the translation. The client receives a reply from a source it never expected and drops it. The TCP handshake then fails and no connection can be established.

Still, it's often desirable for clients on the LAN to connect to the same internal server as external clients and to do so transparently. There are several solutions for this problem:

Split-Horizon DNS

It's possible to configure DNS servers to answer queries from local hosts differently than external queries so that local clients will receive the internal server's address during name resolution. They will then connect directly to the local server, and the firewall isn't involved at all. This reduces local traffic since packets don't have to be sent through the firewall.

Moving the Server Into a Separate Local Network

Adding an additional network interface to the firewall and moving the local server from the client's network into a dedicated network (DMZ) allows redirecting of connections from local clients in the same way as the redirection of external connections. Use of separate networks has several advantages, including improving security by isolating the server from the remaining local hosts. Should the server (which in our case is reachable from the Internet) ever become compromised, it can't access other local hosts directly as all connections have to pass through the firewall.

TCP Proxying

A generic TCP proxy can be setup on the firewall, either listening on the port to be forwarded or getting connections on the internal interface redirected to the port it's listening on. When a local client connects to the firewall, the proxy accepts the connection, establishes a second connection to the internal server, and forwards data between those two connections.

Simple proxies can be created using inetd(8) and nc(1). The following /etc/inetd.conf entry creates a listening socket bound to the loopback address (127.0.0.1) and port 5000. Connections are forwarded to port 80 on server 192.168.1.10.

127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \ 20 192.168.1.10 80

The following redirection rule forwards port 80 on the internal interface to the proxy:

rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \ 127.0.0.1 port 5000

RDR and NAT Combination

With an additional NAT rule on the internal interface, the lacking source address translation described above can be achieved.

rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \ $server no nat on $int_if proto tcp from $int_if to $int_net nat on $int_if proto tcp from $int_net to $server port 80 -> \ $int_if

This will cause the initial packet from the client to be translated again when it's forwarded back through the internal interface, replacing the client's source address with the firewall's internal address. The internal server will reply back to the firewall, which can reverse both NAT and RDR translations when forwarding to the local client. This construct is rather complex as it creates two separate states for each reflected connection. Care must be taken to prevent the NAT rule from applying to other traffic, for instance connections originating from external hosts (through other redirections) or the firewall itself. Note that the rdr rule above will cause the TCP/IP stack to see packets arriving on the internal interface with a destination address inside the internal network. To prevent the stack from issuing ICMP redirect messages (telling the client that its destination is reachable directly, breaking the reflection), disable redirects on the gateway, using

# sysctl -w net.inet.ip.redirect=0 # sysctl -w net.inet6.ip6.redirect=0 (if using IPv6)

In general, the previously mentioned solutions should be used instead.