On Tue, May 03, 2005 at 05:00:24PM -0500, Jonathan Camenisch wrote: > My firewall is set up and working for everything - almost. It's > running NAT and altq, neither of which should be relevant to my > problem (let me know if I'm wrong, and I'll post details) > > It has 3 relevant interfaces: > $ext_if - x.x.x.x (running NAT) > $dmz_if - 10.0.1/24 > $int_if - 10.0.0/24 > > I'll continue translating interface names into the above variables for > consistency. > > I have a web server on the dmz at 10.0.1.3, which I can't reach from > within the LAN (10.0.0.x). For troubleshooting, I inserted the > following as my first filter rule: > > pass in log quick inet proto tcp from any to 10.0.1.3 \ > port = www keep state
This probably is not the cause of the problem, but you should definitely be specifying which combination of TCP flags can create the initial state here. Try "flags S/SA" as a start. > Obviously, the request for the web page is getting to the web server, > and the ack packet is getting back to the firewall, but never through > the firewall back to my computer. So, I try listening to pflog0: > > $ sudo tcpdump -netti pflog0 host 10.0.1.3 > tcpdump: listening on pflog0 > > ##### ABBREVIATED ######### > rule 0/0(match): pass in on $int_if: 10.0.0.12.2519 > 10.0.1.3.80: S ... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.80 > 10.0.0.12.2519: > S ... ack... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.80 > 10.0.0.12.2519: . ack... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.80 > 10.0.0.12.2519: > S ... ack... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.80 > 10.0.0.12.2519: . ack... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.80 > 10.0.0.12.2519: > S ... ack... > rule 127/0(match): block in on $dmz_if: 10.0.1.3.138 > 10.0.1.255.138: udp > 208 > ##### END ABBREVIATED ######### > > Now, what's up with that!? The packet entering $int_if matched the > first rule - but only once. Subsequant packets going that direction > must have matched the state table, since they didn't show up (right?). > > But returning packets entering on $dmz_if got blocked. Why would they > even be filtered? They should be found in the state table. Or am I > missing something? > > I'm feeling pretty stumped. I hope someone has more insight on this > than I. Thanks in advance. Why the ACKs are being blocked depends on a number of things, but most importantly your block-policy and your state-policy. I'm going to assume that your block-policy is 'drop' or 'return'. Keep in mind how the packets traverse this setup: 1) SYN from 10.0.0.12 comes IN on $int_if and goes OUT on $dmz_if to 10.0.1.3 port 80 2) SYN/ACK from 10.0.1.3 port 80 comes IN on $dmz_if and OUT on $int_if to 10.0.0.12 3) Same as #1, but just an ACK So, at any point when packet is coming IN or OUT, the firewall can reject the packet. Not knowing more about your ruleset, I can only guess as to what your state-policy is set to. If it is set to 'if-bound', then this is a perfect example of it doing what it was designed to do. State was created on $int_if and the packet passed out on $dmz_if without creating state, and as a result the SYN/ACK is blocked because there is no state entry on $dmz_if. My suggestion is to use these two rules: pass in on $int_if inet proto tcp from $int_if:network to 10.0.1.3/32 \ port 80 flags S/SA modulate state pass out on $dmz_if inet proto tcp from $int_if:network to 10.0.1.3/32 \ port 80 flags S/SA modulate state ..And ensure that 'set state-policy if-bound' is somewhere in your rules. -jon
