On Tuesday, November 4, 2003, at 01:34 PM, Daniel Hartmeier wrote:
I can't access the web server in the dmz from the internal lan using the internet ip.
If so, you'll need a similar rdr rule on the lan interface. A connection
from the lan to an external address will first come in on the lan
interface, and (if not redirected to another address), will probably
pass out through the external interface, and the rdr rule _there_ does
not apply to outgoing connections.
I was doing that, but it didn't work...
http://www.openbsd.org/faq/pf/rdr.html
Redirection and Reflection
..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.
So the answer is at
http://www.openbsd.org/faq/pf/rdr.html
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.
The previously mentioned solutions are : Split-Horizon DNS, Moving the Server Into a Separate Local Network, TCP Proxying
Putting these three rules in my pf.conf
rdr on $int_if proto tcp from $local_net to $ext_if port 80 -> $www no nat on $int_if proto tcp from $int_if to $local_net nat on $int_if proto tcp from $local_net to $www port 80 -> $int_if
does get it to work. Is this overkill? Should there be a simpler way to do it? My server is in a 'Separate Local Network'. I will eventually want to add email support the same way.
Thank you for the nod in the right direction. I'm at least a step closer and I have a working example now.
-Fred
