Re: pf state-policy floating to if-bound

2023-06-15 Thread Kapetanakis Giannis
On 15/06/2023 19:07, Peter Nicolai Mathias Hansteen wrote:
>> On 15 Jun 2023, at 16:26, Kapetanakis Giannis  
>> wrote:
>> After applying some keep state (if-bound) on major rules, I 've already 
>> found a problem.
>>
>> pfsync.
>>
>> It copies the interface. The interfaces are different on the backup firewall 
>> so the states will not match if I demote master.
>>
>> Anyway to overcome this? Maybe filtering with same group name that is the 
>> same on both firewalls?
> Yes, I was going to suggest creating interface groups and referencing those 
> in your rules instead of interfaces.
>
> - P


I believe that will only work for rule copying between the firewalls and not 
state copying with pfsync.

State has an interface (or "all" for floating states) and that is copied 
between pfsync hosts.

For example when filtering with egress group, pfsync copies the egress state's 
interface from primary firewall to backup (different interface names).

It would be nice to add some kind of translation/mapping on the pfsync 
interface, to translate incoming remote states to local interface names.
Don't know how difficult that would be.

G



Re: pf state-policy floating to if-bound

2023-06-15 Thread Peter Nicolai Mathias Hansteen


> On 15 Jun 2023, at 16:26, Kapetanakis Giannis  
> wrote:
> After applying some keep state (if-bound) on major rules, I 've already found 
> a problem.
> 
> pfsync.
> 
> It copies the interface. The interfaces are different on the backup firewall 
> so the states will not match if I demote master.
> 
> Anyway to overcome this? Maybe filtering with same group name that is the 
> same on both firewalls?

Yes, I was going to suggest creating interface groups and referencing those in 
your rules instead of interfaces.

- P

--
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: pf state-policy floating to if-bound

2023-06-15 Thread Kapetanakis Giannis
On 15/06/2023 17:17, Kapetanakis Giannis wrote:
> Hello,
>
> I'd like to make a change to my firewall/router from the default state-policy 
> floating to if-bound
>
> I believe the way my pf.conf is configured it will not do any harm but I'm 
> being cautious here and I'd like some info.
>
> The way I see it, I have two states for each packet traveling either 
> direction of the firewall.
> One on the incoming interface and one on the outgoing interface for each 
> packet.
> Each state is floating (pfctl -ss gives all)
>
> I filter always on the incoming interface, apply a tag and pass on the 
> outgoing interface everything that matches the tag.
> One tag for packets coming from internet and a different tag for packets 
> coming from my internal network to the internet.
>
> I believe that if all my filtering is like above then changing the default 
> policy will work without any further changes in pf.conf
>
> I don't understand why floating is the default.
> I mean, even with floating states, each state has a direction in/out, thus 
> the same state cannot be applied to multiple interfaces (incoming/outgoing) 
> and a different (floating) state is created on each interface.
>
> There must be a case I'm missing here. Maybe multipath routing?
>
> regards,
>
> Giannis


After applying some keep state (if-bound) on major rules, I 've already found a 
problem.

pfsync.

It copies the interface. The interfaces are different on the backup firewall so 
the states will not match if I demote master.

Anyway to overcome this? Maybe filtering with same group name that is the same 
on both firewalls?

G



pf state-policy floating to if-bound

2023-06-15 Thread Kapetanakis Giannis
Hello,

I'd like to make a change to my firewall/router from the default state-policy 
floating to if-bound

I believe the way my pf.conf is configured it will not do any harm but I'm 
being cautious here and I'd like some info.

The way I see it, I have two states for each packet traveling either direction 
of the firewall.
One on the incoming interface and one on the outgoing interface for each packet.
Each state is floating (pfctl -ss gives all)

I filter always on the incoming interface, apply a tag and pass on the outgoing 
interface everything that matches the tag.
One tag for packets coming from internet and a different tag for packets coming 
from my internal network to the internet.

I believe that if all my filtering is like above then changing the default 
policy will work without any further changes in pf.conf

I don't understand why floating is the default.
I mean, even with floating states, each state has a direction in/out, thus the 
same state cannot be applied to multiple interfaces (incoming/outgoing) and a 
different (floating) state is created on each interface.

There must be a case I'm missing here. Maybe multipath routing?

regards,

Giannis




explanation of pf state-policy floating vs if-bound?

2007-07-14 Thread Bohdan Tashchuk

I'm running OpenBSD 4.1 release.

Does anyone have a definitive explanation of the difference between pf 
state being floating vs if-bound, and when one or the other should / 
must be used?


The rest of this email is just explaining why I'm asking the question.

I've seen Henning Brauer say use floating unless you absolutely need to 
use if-bound.


http://archive.openbsd.nu/?ml=openbsd-pfa=2005-08t=1255924

Claudio Jaker's paper on multipath routing specifically shows if-bound 
as part of the mimimum rule set.


http://cvs.openbsd.org/papers/opencon06-network/mgp9.html

Also, recently I had a question about multihoming. People pointed out 
the pf reply-to feature and the route command -mpath feature and I was 
able to make multihoming work for me using those techniques. Thanks for 
your help.


But then I realized I don't want to be multihomed in the sense that my 
cable modem interface is so much faster than my DSL inteface that I want 
to ignore DSL except for limited circumstances.


All I wanted to do was to allow limited inbound access to my DSL 
interface. In my case, just SSH. Also by DSL ISP blocks inbound SSH so I 
needed to move the port.


So I didn't need to say: route xxx -mpath

I also didn't need to set: net.inet.ip.multipath=1

I wound up with these rules, which seem to work:



set state-policy if-bound

pass in quick on $cable_interface \
reply-to ( $cable_interface $cable_gateway ) \
proto tcp from any to any port { $cable_sshd } \
keep state ( floating )

pass in quick on $dsl_interface \
reply-to ( $dsl_interface $dsl_gateway ) \
proto tcp from any to any port { $dsl_sshd } \
keep state ( floating )



But here's the trick: If my entire pf.conf rule set is if-bound then it 
fails. Packets inbound on DSL are routed outbound on CABLE (which is my 
one-and-only default route). It's only when I added keep state 
(floating) to the above two rules that things started working the way I 
expected them to, e.g. inbound on DSL caused replies to be sent back out 
to DSL.


So state-policy is a magic, magic thing with non-obvious (to me at 
least) side effects. It's counter-intuitive to me that a floating 
policy allows packets to go back out the interface they arrived at.


I'm hoping someone will reply with a more detailed explanation of what's 
going on here.