Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Martijn van Duren]

On 05/07/18 23:51, Martin Gignac wrote:
>> It looks like 'received-on' would be a cleaner and shorter way to
>> achieve my goal by allowing me to specify inbound and outbound
>> interfaces in the same rule.
>>
> 
> I think I spoke to quickly; it would be an alternative way, but not a
> shorter one as I would still need the initial "pass in lab01" I guess. I
> just wouldn't have to tag it.
> 
>>
I usually do the filtering on the outbound interface and add a statement
like the following the pass in all to be forwarded packets:
pass in to !(self)

This way you don't have to add different rules for different tags.

martijn@

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Peter N. M. Hansteen]

On 05/07/18 18:40, Martin Gignac wrote:

> In an OpenBSD pf rule however, a rule only references a single
> interface and a direction (in, out).

This is not correct. It's perfectly valid and not unusual to have rules
like

pass from 10.2.3.0/24

(or 'pass to $somenet'). The default state-policy is 'floating' (as in
not tied to an interface) but you can set it to be if-bound if you like.

But for the use case you describe, tagging on ingress and filtering on
tagged later is certainly a potentially useful approach.

- Peter
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Martin Gignac]

> It looks like 'received-on' would be a cleaner and shorter way to
> achieve my goal by allowing me to specify inbound and outbound
> interfaces in the same rule.
>

I think I spoke to quickly; it would be an alternative way, but not a
shorter one as I would still need the initial "pass in lab01" I guess. I
just wouldn't have to tag it.

>

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Martin Gignac]

> You could also replace the above with "pass in on $lab02 received-on $lab01".

Oh, I completely missed the 'received-on' statement in the OpenBSD
pf.conf man page! (I have to support a pfSense for the moment so I'm
alternating between the OpenBSD and FreeBSD man pages [the latter does
not support 'received-on']).

It looks like 'received-on' would be a cleaner and shorter way to
achieve my goal by allowing me to specify inbound and outbound
interfaces in the same rule.

Thanks!
-Martin

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Martin Gignac]

> I imagine you meant "pass out on $lab02 tagged from_lab01".

You're absolutely right Ken!

Thanks,
-Martin

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Daniel Melameth]

On Mon, May 7, 2018 at 11:51 AM, Daniel Melameth  wrote:
> On Mon, May 7, 2018 at 10:40 AM, Martin Gignac  
> wrote:
>> In Juniper SRXes and Netscreen firewalls one defines security policies
>> (firewall rules) according to a "from" security zone, and a "to"
>> security zone. Rules within each "from-to" combo can then focus on
>> allowing or blocking individual IP subnets if required.
> ...
>
>> I am looking to define firewall policies on OpenBSD where I can
>> enforce something like "all traffic from lab01 to lab02 is allowed by
>> default, but all traffic from lab02 to to lab01 is denied by default".
>> In this case lab01 and lab02 are bound to different interfaces
>> (obviously), but behind each interface is another router to which are
>> attached a changing number of subnets, so I want to avoid having to
>> update subnet lists in my pf rules constantly. This situation would be
>> simple to deal with in Juniper/Netscreen or Linux, but I'm having a
>> hard time figuring out how to achieve a similar result in pf. I
>> thought about passing all traffic on ingress on the lab01 and lab02
>> interfaces, tagging that traffic with a "from_lab0x" tag, and then
>> having outbound rules take action based on the relevant interface and
>> tag, like so:
>>
>>   lab01 = em1
>>   lab02 = em2
>>
>>   set state-policy if-bound
>>
>>   block
>>
>>   pass in on $lab01 tag from_lab01
>>   pass in on $lab02 tag from_lab02
>>
>>   pass in on $lab02 tagged from_lab01
>
> You could also replace the above with "pass in on $lab02 received-on $lab01".

I meant "pass out on $lab02 received-on $lab01".  Obviously pass in
wouldn't work in your example and mine.

>>   block out on $lab01 tagged from_lab02
>>
>> Does this look like it makes sense? Is using an 'if-bound'
>> state-policy ill-advised? Are there any obvious problems with this
>> method? If so, is there a better way to achieve my goal?

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Daniel Melameth]

On Mon, May 7, 2018 at 10:40 AM, Martin Gignac  wrote:
> In Juniper SRXes and Netscreen firewalls one defines security policies
> (firewall rules) according to a "from" security zone, and a "to"
> security zone. Rules within each "from-to" combo can then focus on
> allowing or blocking individual IP subnets if required.
...

> I am looking to define firewall policies on OpenBSD where I can
> enforce something like "all traffic from lab01 to lab02 is allowed by
> default, but all traffic from lab02 to to lab01 is denied by default".
> In this case lab01 and lab02 are bound to different interfaces
> (obviously), but behind each interface is another router to which are
> attached a changing number of subnets, so I want to avoid having to
> update subnet lists in my pf rules constantly. This situation would be
> simple to deal with in Juniper/Netscreen or Linux, but I'm having a
> hard time figuring out how to achieve a similar result in pf. I
> thought about passing all traffic on ingress on the lab01 and lab02
> interfaces, tagging that traffic with a "from_lab0x" tag, and then
> having outbound rules take action based on the relevant interface and
> tag, like so:
>
>   lab01 = em1
>   lab02 = em2
>
>   set state-policy if-bound
>
>   block
>
>   pass in on $lab01 tag from_lab01
>   pass in on $lab02 tag from_lab02
>
>   pass in on $lab02 tagged from_lab01

You could also replace the above with "pass in on $lab02 received-on $lab01".

>   block out on $lab01 tagged from_lab02
>
> Does this look like it makes sense? Is using an 'if-bound'
> state-policy ill-advised? Are there any obvious problems with this
> method? If so, is there a better way to achieve my goal?

Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Kenneth Gober]

On Mon, May 7, 2018 at 12:40 PM, Martin Gignac  wrote:
>   set state-policy if-bound
>
>   block
>
>   pass in on $lab01 tag from_lab01
>   pass in on $lab02 tag from_lab02
>
>   pass in on $lab02 tagged from_lab01
>   block out on $lab01 tagged from_lab02
>
> Does this look like it makes sense? Is using an 'if-bound'
> state-policy ill-advised? Are there any obvious problems with this
> method? If so, is there a better way to achieve my goal?

I imagine you meant "pass out on $lab02 tagged from_lab01".

Yes, this makes sense and I don't see any reason you can't do it this
way if you want to.  It seems like a perfect use-case for tags.

-ken

How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?

[Martin Gignac]

Hello,

In Juniper SRXes and Netscreen firewalls one defines security policies
(firewall rules) according to a "from" security zone, and a "to"
security zone. Rules within each "from-to" combo can then focus on
allowing or blocking individual IP subnets if required.

In Linux, the FORWARD chain is used for all traffic traversing the
firewall and not destined for it. The firewall chain allows the
administrator to filter based on incoming interface *and* outgoing
interface.

In an OpenBSD pf rule however, a rule only references a single
interface and a direction (in, out).

I am looking to define firewall policies on OpenBSD where I can
enforce something like "all traffic from lab01 to lab02 is allowed by
default, but all traffic from lab02 to to lab01 is denied by default".
In this case lab01 and lab02 are bound to different interfaces
(obviously), but behind each interface is another router to which are
attached a changing number of subnets, so I want to avoid having to
update subnet lists in my pf rules constantly. This situation would be
simple to deal with in Juniper/Netscreen or Linux, but I'm having a
hard time figuring out how to achieve a similar result in pf. I
thought about passing all traffic on ingress on the lab01 and lab02
interfaces, tagging that traffic with a "from_lab0x" tag, and then
having outbound rules take action based on the relevant interface and
tag, like so:

  lab01 = em1
  lab02 = em2

  set state-policy if-bound

  block

  pass in on $lab01 tag from_lab01
  pass in on $lab02 tag from_lab02

  pass in on $lab02 tagged from_lab01
  block out on $lab01 tagged from_lab02

Does this look like it makes sense? Is using an 'if-bound'
state-policy ill-advised? Are there any obvious problems with this
method? If so, is there a better way to achieve my goal?

Thanks,
-Martin

Re: frequent SeaMonkey crashes

[Dumitru Mișu Moldovan]

On 05/06/18 22:53, Riccardo Mottola wrote:
> Hi,
> 
> after 6.3 upgade (with associated packages) I experience very frequent
> crashes of the SeaMonkey browser.
> I checked RAM consumption and it crashes even if it is not very hight,
> around 400MB, for example.
> 
> I tried starting it from a terminal and see this message after a crash:
> 
> seamonkey: Fatal IO error 12 (Cannot allocate memory) on X server :0.
> 
> Is it a bug perhaps_ or some limit i can extend?


Add your user to the "staff" login class and increase "datasize-cur" to
3072M (which corresponds to the value in the SIZE column in top for the
SeaMonkey process, not with the smaller RES).

Unfortunately, latest SeaMonkey consumes considerably more RAM…  And
it's not their fault, this is something that comes with the rendering
engine in Firefox 52 ESR.  So now you'll need a machine with 2GB of RAM
to run it smoothly on amd64 ( I think, have kept my oldest hardware on
6.2 because of this, among others).  But with the increased limit you'll
get a VERY stable SeaMonkey, have used it intensively since the RC days
with no crashes on two machines.  It's the browser I  use daily for
work-related stuff.

> 
> I tried FireFox and it seems a little bit better: strange though,
> because usually it is has always been the other way and I am a long-time
> seamonkey fan.

I don't know what version of Firefox you use.  I have 59 here and it
definitely uses more RAM compared to SeaMonkey when opening lots of tabs
(20-30).  Of course, it's not the same Mozilla profile, and the sessions
are also different, but I use more or less the same settings and
extensions.  However, Firefox has multiple processes per launched
instance, so it probably hits the "datasize-cur" limit later for your
use case.

Also, these Firefox Quantum releases are really nice, anyone still using
Firefox ESR 52 should check them out, as they are considerably snappier.
 Beware of incompatible extensions, so save your profile before trying
Firefox Quantum, just in case.  Maybe worth starting from scratch or
with the settings saved through the Firefox account in Mozilla's cloud…
Also, relevant for people running -stable:
https://undeadly.org/cgi?action=article=20170425173917.



signature.asc
Description: OpenPGP digital signature

Re: frequent SeaMonkey crashes

[Martijn van Duren]

Hello Riccardo,

On 05/06/18 21:53, Riccardo Mottola wrote:
> Hi,
> 
> after 6.3 upgade (with associated packages) I experience very frequent 
> crashes of the SeaMonkey browser.
> I checked RAM consumption and it crashes even if it is not very hight, around 
> 400MB, for example.
> 
> I tried starting it from a terminal and see this message after a crash:
> 
> seamonkey: Fatal IO error 12 (Cannot allocate memory) on X server :0.

You can try to extend your data area size via ulimit -d.
See ksh(1) for more information. Don't forget to start SeaMonkey via
that same shell as well, changing the data area only works for child-
programs, not the entire X login session.

If this works for you you can increase the limit permanent via
/etc/login.conf (which will increase the limit for all applications) or
by creating a wrapper-script which will increase the limit before
executing SeaMonkey.

Hope this helps.
> 
> Is it a bug perhaps_ or some limit i can extend?
> 
> I tried FireFox and it seems a little bit better: strange though, because 
> usually it is has always been the other way and I am a long-time seamonkey 
> fan.
> 
> Riccardo
> 

martijn@

Re: frequent SeaMonkey crashes

[Roderick]

On Sun, 6 May 2018, Riccardo Mottola wrote:

after 6.3 upgade (with associated packages) I experience very frequent 
crashes of the SeaMonkey browser.


I think, the problem is the upgrade of seamonkey, not of OpenBSD.

I had and have the same problem with firefox, I did a lot of things
that I do not remember exactly, and it got better.

Perhaps the best to do is, to save what you want to save
(bookmars), deleete the .mozila directory and beginn from 0.

BTW, I also deactivated the only plugin automatically installed
by firefox.

Rodrigo.