On 5/4/05, Jon Hart <[EMAIL PROTECTED]> wrote: > 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.
Thanks. > > > 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. Both block-policy and state-policy are the default: "drop" and "floating." I really would prefer floating, since it keeps the rules more concise. > 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. Your suggestion worked! Thanks. But that's really confusing. Why didn't the floating policy work - especially since it's been working just fine for all my other rules? Normally I just keep state on the inbound packet, and leave it at that. I have around 150 filter rules written with that approach, and everything else is working fine. I'm in business now, but would appreciate further insight anyone might have. - jc > -jon >
