On 2013-12-18, Tethys <tet...@gmail.com> wrote:
> On Tue, Dec 17, 2013 at 7:51 PM, Jan Stary <h...@stare.cz> wrote:
>
>>> block in log
>>> block out log on $ext
>>
>> How could anyone help you knowing just these two lines?
>> Show your pf.conf
>
> I was trying to show that I only had two block lines and that they
> both should log when blocking packets. My rules are actually very
> simple:
>
> match out on $ext from $int_ip to any nat-to $loki_ext
>
> block in log
> block out log on $ext
>
> pass in quick on $int flags any
>
> pass out on $ext from $lokisafe
>
> pass in on $ext inet proto tcp to port 4334 rdr-to 127.0.0.1 port ssh
> pass in on $ext inet proto tcp from $mx to $loki_ext port smtp
> rdr-to $riva port smtp flags any
>
> pass out on $int inet proto tcp from $mx port smtp flags any
>
> $int and $ext are interfaces on the firewall (loki). $loki_ext is the
> external IP, $int_ip is the internal /24. $lokisafe is a selection of
> /24s that I've sometimes used, including the internal network. $riva
> is my home mail server. $mx is the IP addresses of my hosted MX
> servers.
>
> With tcpdump, I can see the response to the EHLO greeting leaving
> riva, arriving on $int, but never making it to $ext. Using HELO
> instead doesn't prompt the same behaviour.
>
> Tet
>
Most likely cause is that the firewall state is created by a packet
which is not a SYN. The TCP window-scaling options are *only* sent in
the SYN packet, any state created from a later packet will not have this
information, so the state tracking will reject packets as being "out of
window".
Most likely reason for this happening is that you don't have a general
"block" rule at the start of the ruleset, so some packets (in your case
outbound packets on any interface other than $ext) are passed by the
implicit default rule which is basically "pass flags any no state".
Change your ruleset to start with a rule which just says "block"
or "block log" to ensure that any packets which are passed, have a state
associated with them. Then test things, it may help to monitor output of
'tcpdump -nettipflog0' when doing this to help spot any missing rules.
If it still fails and you think you have sufficient "pass" rules, bump
up pf debug logging ("pfctl -x info" is probably enough) and look at the
console log or /var/log/messages. Return it to normal logging ("pfctl
-x error") afterwards (especially if it is a busy system, and that goes
double if you have the main console on a serial port ;)
