Connection Redirection

Many networks lurk behind a single IP address; their mail server lives on one machine behind the NAT, their web server is on another machine, and so on. You can use connection redirection to aim incoming TCP/IP connection requests to the appropriate machines, allowing an IP address the global DNS calls "www.mycompany.com" to handle any incoming service. Connection redirection is useful for situations other than just NAT, but NAT is the first place it's needed. You need to know the port number and the IP address that you want to show to the world, and the port number and IP address of the daemon on the hidden machine that you want the connection to go to.

 rdr on external-interface proto protocol from source-ip to public-ip port public- port -> destination-port port real-destination-port 

For example, we might have a NAT firewall with an external IP address of 209.69.178.18, with an SSH server lurking behind it on 192.168.1.200. We want incoming TCP requests on port 2022 to be redirected to this SSH server. I'm not using the standard SSH port, 22, because the OpenBSD firewall also runs sshd. PF will intercept incoming connection requests before they ever reach the local SSH daemon, which means I wouldn't be able to log in remotely.

 1 rdr 2 on fxp0 3 proto tcp from 4 any to 5 209.69.178.18 6 port 2022 -> 7 192.168.1.200 8 port 22 

All redirection rules start with the 1 rdr keyword.

Then we have 2 the interface that the redirection applies to. Any packets that cross this interface and that match the rest of the packet description will be redirected as the rule says. Including the interface in a redirection rule is optional if you have only one interface doing NAT. If you're doing different sorts of NAT on different interfaces, you'll need to include this. If I didn't include this rule, however, any packet from anywhere would be redirected to the internal SSH server. I'd like to be able to SSH into my firewall from the inside network, so I specify the outside interface.

Every redirection rule must include a 3 protocol statement. You can use braces to include multiple protocols, which is useful for applications such as DNS, but most applications run over a single network protocol.

Just as with packet-filtering rules, redirections allow you to specify a 4 source address and/or port. You can choose different servers to redirect to based on source IP address.

The destination 5 IP and 6 port are actually the IP address visible to the outside world. The IP address is bound to the external network card. Then we have the actual destination IP and port. In this example, connections to port 6 2022 of the IP address 5 209.69.178.18 are forwarded on to port 8 22 on the IP address 7 192.168.1.200.

Put redirection rules after NAT rules.

Redirecting Ranges of Ports

PF can also redirect entire ranges of ports to a single port or a range of ports, as you desire. The configuration is done entirely by changing how you specify the public port and the real destination port.

To specify a range of public ports, list the lowest and highest ports, separated by a colon. For example, many Microsoft RPC-based network services require access to random ports above 1024. To redirect the entire range of network ports from 1024 to 65535 to an internal host, use a public port statement like this:

 1024:65535 

On the destination side, if you want all of the redirections to arrive at a single port, just list the port number as usual. Here, we redirect the entire range of ports from 1024 to 65535, inclusive, to a single machine:

 rdr on fxp0 proto tcp from any to 209.69.178.18 port 1024:65535 -> 192.168.1.200 port 1024 

Much more likely is that you would need to redirect a range of ports to another range of ports, e.g., port 1024 on your public IP goes to port 1024 on your private IP, port 1025 on the public IP goes to port 1025 on the private IP, and so on. Do this by specifying the start port, a colon, and an asterisk, like this:

 1024:* 

For a working Microsoft RPC service, you would redirect the entire range of ports like this:

 rdr on fxp0 proto tcp from any to 209.69.178.18 port 1024:65535 -> 192.168.1.200 port 1024:* 

This, of course, provides a whole wide variety of holes for an intruder to gleefully exploit. It will provide you with a solid background in intrusion response and recovery, however.

Redirection and Proxies

You can use redirection to provide transparent proxy services. One common application proxy is the Squid HTTP cache (/usr/ports/www/squid). You could run around from desktop to desktop and reconfigure all the web browsers to point at the proxy server, or you could just do this redirection at the firewall. For example, if you want to send all of the web requests from 192.168.1.0/24 to the Squid proxy running on port 8080 of the firewall, you would just do this:

 rdr on 1 fxp1 proto tcp from 192.168.1.0/24 to any port 80 -> 127.0.0.1 port 8080 

The first tricky thing here is that we need to specify the 1 internal interface rather than the external interface. Requests that should be proxied will only be coming in on the internal interface. This will also prevent things such as some clever user installing a port 80 sshd(8) on his home machine just to bypass the packet-filtering firewall.

This works well if your proxy server is on your firewall, but what if you have a separate cache machine? The cache machine must be able to make outbound requests to port 80, but you almost certainly want to protect it behind your firewall. You can specifically exclude one machine from this redirection by using a "no" rule. In the following example, 192.168.1.12 is our Squid machine. As the first rule matches, this machine can go out to the Internet and browse web pages directly. Other machines that attempt to access the Web are instead redirected to the Squid machine's cache on TCP port 3128.

 no rdr on fxp1 proto tcp from 192.168.1.12 to any port 80 rdr on fxp1 proto tcp from 192.168.1.0/24 to any port 80 -> 192.168.1.12 port 3128 

You can use a similar technique to allow particular machines to bypass the Web proxy. At times, allowing a single machine to bypass the proxy can be useful for troubleshooting purposes.

Redirection and Packet Filtering

You might need a packet-filtering rule to allow traffic to a redirected port. Use the port number visible to the world in these rules, not the redirected port number. For example, if you are redirecting all traffic on port 80 to port 8081 on a different machine, your packet filtering rules must allow access to port 80, not port 8081.