Hi, Seeing the answer to my question I'm afraid I wasn't clear enough about the purpose of it. I'm aware that authpf/pf is behaving as intended, I was just wondering if any change on that is planned because I'm guessing that I'm not the only one who would find useful to be able to keep the non authpf related states for an IP address after logoff authpf.
My second question was more oriented to administrators who might want to share their thoughts about the question like Johan did (I'm going to have to test that one, thanks Johan). Sadly "System administrator" here seems to be willing to act in representation of all members of this list when he says: [...] do not expect anyone on this list to do your research for you. [...]. If everyone thought like him I think that the open source initiatives wouldn't exist anymore, anyway I don't want to start a discussion about this subject but keep it to the technical question which has been already asked, so if you are not "System Administrator" you can most likely ignore the coming lines on this email. On Tue, Dec 23, 2008 at 8:36 PM, System Administrator <ad...@bitwise.net> wrote: > This list tends to favor those who do at least some basic homework > before asking redundant questions. Completely agree with you, there is nothing more annoying that those purpose less messages which doesn't ask properly and/or doesn't really answer something. > Had you read the authpf man page or searched the list archives That's right, I knew I should have read some documentation. What lucky that my system is up and running by merely crazy guessing the content of the config files! >, you would have certainly realized that what you are describing is EXACTLY the intended > behavior, in other words, your system is working exactly as it was designed. Oh, really? Because I was just thinking that there was a problem in authpf.... No, wait, I haven''t said that, stop confusing me! > > Regarding your follow-up question: OpenBSD pf is a very powerful > firewall sub-system and supports a number of viable work-arounds to > accomplish what you want. However, unless you are offering to pay > market-rate consulting fees, do not expect anyone on this list to do > your research for you. Now is when I should send you a private message with my credit card number on it? > > > On 23 Dec 2008 at 8:12, Derek wrote: > >> Hello, >> >> Seeing that nobody is answering to the question below I'd add: Is there >> anybody who uses authpf in the same scenario? Does it behave like in my >> case? Any suggestion to keep the states for the user after he/she closes the >> session? >> >> Thank you. >> >> On Wed, Dec 17, 2008 at 1:46 PM, Derek <derekmail...@gmail.com> wrote: >> >> > Hi list, >> > >> > I'm using authpf to allow external users to access to certain restricted >> > services within our network. This network hosts public services as well, >> > this is services which are open to all internet. >> > >> > The thing is that after some tests I realized that a client who has an >> > authpf session opened and uses both, the autpf-protected service and the >> > public service, gets disconnected of all services when he/she closes the >> > authpf session. >> > >> > Looking a little bit closer I can see that all the states created by an IP >> > address are removed when the user from that IP closes the authpf session so >> > the states created by the authpf rules but also the ones created by the >> > "regular" pf.conf rules disappear from the table. >> > >> > I guess that this is because there is only one states table and it could be >> > difficult to know which states are genereated by which rules. >> > >> > The question is, is there any plan to label or mark the states so will be >> > possible in the future for the non-authpf states to survive the authpf >> > session? >> > >> > Thank you all. >> > >> > Derek. >> >> > > > On Tue, Dec 23, 2008 at 8:36 PM, System Administrator <ad...@bitwise.net>wrote: > This list tends to favor those who do at least some basic homework > before asking redundant questions. Had you read the authpf man page or > searched the list archives, you would have certainly realized that what > you are describing is EXACTLY the intended behavior, in other words, > your system is working exactly as it was designed. > > Regarding your follow-up question: OpenBSD pf is a very powerful > firewall sub-system and supports a number of viable work-arounds to > accomplish what you want. However, unless you are offering to pay > market-rate consulting fees, do not expect anyone on this list to do > your research for you. > > > On 23 Dec 2008 at 8:12, Derek wrote: > > > Hello, > > > > Seeing that nobody is answering to the question below I'd add: Is there > > anybody who uses authpf in the same scenario? Does it behave like in my > > case? Any suggestion to keep the states for the user after he/she closes > the > > session? > > > > Thank you. > > > > On Wed, Dec 17, 2008 at 1:46 PM, Derek <derekmail...@gmail.com> wrote: > > > > > Hi list, > > > > > > I'm using authpf to allow external users to access to certain > restricted > > > services within our network. This network hosts public services as > well, > > > this is services which are open to all internet. > > > > > > The thing is that after some tests I realized that a client who has an > > > authpf session opened and uses both, the autpf-protected service and > the > > > public service, gets disconnected of all services when he/she closes > the > > > authpf session. > > > > > > Looking a little bit closer I can see that all the states created by an > IP > > > address are removed when the user from that IP closes the authpf > session so > > > the states created by the authpf rules but also the ones created by the > > > "regular" pf.conf rules disappear from the table. > > > > > > I guess that this is because there is only one states table and it > could be > > > difficult to know which states are genereated by which rules. > > > > > > The question is, is there any plan to label or mark the states so will > be > > > possible in the future for the non-authpf states to survive the authpf > > > session? > > > > > > Thank you all. > > > > > > Derek.
