Daniel; Thanks, I'll give each of these a try. I have already been playing with the tcpdump on the interfaces to watch the traffic but wasn't aware that the target servers needed to have the "test" firewall as their gateway. I would think I should be able to hit services on those boxes (such as a webserver which is the traffic I have been testing with) from anywhere in my DMZ and get a response.
Russell -----Original Message----- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 10:48 AM To: Russell Morrison Cc: [email protected] Subject: Re: PF Newbie at a loss On Thu, Jan 27, 2005 at 10:06:10AM -0700, Russell Morrison wrote: I can't spot anything obvious. > # The public services offered by AXYS to internet > pass in quick on em0 inet proto tcp from any to any port $tcp_ports flags > S/SA keep state Did you quote this rule verbatim? A common mistake is to restrict the destination address to the external interface's address. The rdr rules will apply first, so redirected packets will have 10.10.10.x destination addresses when they are filtered. If you really have 'to any' in this rule, that's not an issue, of course. Note that the state created by the above rule (incoming on external interface) will not automatically allow the connection to pass out on the internal interface with pf. But you have a dedicated rule that covers this, too. The second place where this matters is the section > # Block the crap to and from private networks, etc. > block drop in quick on em0 inet proto { udp, icmp } all > block drop in quick on em0 inet from <private> to any > block drop out quick on em0 inet from any to <private> > block return in quick on em0 inet proto tcp to port 113 None of these will block redirected connections, assuming you quoted verbatim and didn't leave something out. The general debug procedure is this: - add 'log' to all 'block' rules - watch pflog0 (see EXAMPLES in pflog(4)) - attempt a redirected connection - the output contains the number of the rule that blocked the packet as the first number before the '/', compare with pfctl -vvsr output - deduce why that block rule was the last matching rule (i.e. why it matched if you didn't expect it to, and why other rules didn't match that you expected would) If this doesn't help, run tcpdump on both external and internal interfaces. The initial TCP SYN packet of a redirected connection should first come in on the external interface. Next, you should see it leave on the internal interface, with the destination address replaced. Next, you should see a SYN+ACK coming in on the internal interface from the internal server to the external client. Finally, that SYN+ACK should leave out on the external interface with the source address replaced. Then there are the basic things that can go wrong outside of pf: - the pf box must have a route to the internal server, you must be able to connect to the servers from the pf box itself - the internal servers need to use the pf box (its internal address) as default gateway - the internal servers need to accept connections from external addresses. the connections are only forwarded by pf, they do not have local source addresses (unless you use nat, too). Daniel *********************************************************************** Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message plus any attachments. ***********************************************************************
