Darrel <levitch%iglou.com@localhost> wrote:
If the problem still occurs, then can you describe the connection i.e.
what/where exactly is your source and destination?
Just to be sure -- when using "stateful", one should be aware that for
TCP connections the rule should apply for the initiating (SYN) packet.
If, for example, direction is confused and the rule is applied for the
reply (SYN-ACK) packet - connection tracking engine will not try to fix
it up and will eventually time out the state.
The particular server that I had login problems with is okay now, rather
I have been logged into it for a couple of days. Perhaps I had an extra
line in my npf.conf that was causing my problem, but am not certain.
Having just begun to use NPF, I made lots of rapid changes and was losing
sleep.
So to hopefully further clarify "stateful". What I am using now:
pass stateful out final family inet from $if_ext apply "rid"
pass stateful in family inet to $if_ext
should be changed to:
pass stateful out final family inet from $if_ext apply "rid"
pass in family inet to $if_ext
No, it would be the case I described. The second rule passes incoming
traffic without state creation and the outgoing reply packet (SYN-ACK)
from your machine would match the first rule, which would create the
state on a wrong direction. So your first case is correct. You can
also limit the first rule to TCP and SYN, e.g.:
pass stateful out final family inet proto tcp flags S/SA from $if_ext
or am I still missing something? I am particularly wondering about
logging- is this set up by the user or perhaps have some defaults that
might not need much tweaking?
npflog is just a virtual interface for BPF tap. You can tcpdump it.