pfsync(4) man page patch to clarify requirements

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pfsync(4) man page patch to clarify requirements

Chad Gross
It isn't explicitly expressed in the man page that pfsync requires
identical interfaces to work properly so I've created a patch
clarifying that it won't work otherwise. A workaround is possible with
the use of trunk(4), or now possibly aggr(4), but I wasn't sure this
additional information was warranted in the man page.



--- share/man/man4/pfsync.4.orig 2020-01-29 14:33:39.000000000 -0700
+++ share/man/man4/pfsync.4 2020-01-29 15:55:17.000000000 -0700
@@ -24,7 +24,7 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: August 30 2016 $
+.Dd $Mdocdate: January 29 2020 $
 .Dt PFSYNC 4
 .Os
 .Sh NAME
@@ -105,6 +105,17 @@
 # ifconfig pfsync0 syncdev fxp0
 .Ed
 .Pp
+The receiving firewall will not insert the records into its local state
+table unless all interfaces are the same between both firewalls. For
+example, the process will not work if one firewall contains
+.Xr vr(4)
+interfaces and the other contains
+.Xr em(4)
+because pf rules are built around the interfaces on the firewall. The
+example below uses
+.Xr sis(4)
+drivers for all interfaces for this reason.
+.Pp
 By default, state change messages are sent out on the synchronisation
 interface using IP multicast packets to the 224.0.0.240 group address.
 An alternative destination address for



Thanks,

Chad

Reply | Threaded
Open this post in threaded view
|

Re: pfsync(4) man page patch to clarify requirements

Sebastian Benoit-3
Chad Gross([hidden email]) on 2020.01.29 16:22:52 -0700:
> It isn't explicitly expressed in the man page that pfsync requires
> identical interfaces to work properly so I've created a patch
> clarifying that it won't work otherwise. A workaround is possible with
> the use of trunk(4), or now possibly aggr(4), but I wasn't sure this
> additional information was warranted in the man page.

I dont think this is correct. How do you come to this conclusion?
If possible provide an example that shows what is not working.

If you do not have identical rulesets, the transfered states will have the
"rule number" reference removed, so you wont know what rule created a state
anymore if you look at the receiving system only, but the state will work
just fine.

Possible exceptions i can think of are if-bound states.

/Benno

Reply | Threaded
Open this post in threaded view
|

Re: pfsync(4) man page patch to clarify requirements

Stuart Henderson
On 2020/01/30 11:15, Sebastian Benoit wrote:

> Chad Gross([hidden email]) on 2020.01.29 16:22:52 -0700:
> > It isn't explicitly expressed in the man page that pfsync requires
> > identical interfaces to work properly so I've created a patch
> > clarifying that it won't work otherwise. A workaround is possible with
> > the use of trunk(4), or now possibly aggr(4), but I wasn't sure this
> > additional information was warranted in the man page.
>
> I dont think this is correct. How do you come to this conclusion?
> If possible provide an example that shows what is not working.
>
> If you do not have identical rulesets, the transfered states will have the
> "rule number" reference removed, so you wont know what rule created a state
> anymore if you look at the receiving system only, but the state will work
> just fine.
>
> Possible exceptions i can think of are if-bound states.

It's also needed for getting states assigned to the correct queues (if used).
Maybe something else too.

The usual workaround for this is to have rules reference interface groups
if the interface types differ.

Reply | Threaded
Open this post in threaded view
|

Re: pfsync(4) man page patch to clarify requirements

Chad Gross
On Thu, Jan 30, 2020 at 3:49 AM Stuart Henderson <[hidden email]> wrote:

>
> On 2020/01/30 11:15, Sebastian Benoit wrote:
> > Chad Gross([hidden email]) on 2020.01.29 16:22:52 -0700:
> > > It isn't explicitly expressed in the man page that pfsync requires
> > > identical interfaces to work properly so I've created a patch
> > > clarifying that it won't work otherwise. A workaround is possible with
> > > the use of trunk(4), or now possibly aggr(4), but I wasn't sure this
> > > additional information was warranted in the man page.
> >
> > I dont think this is correct. How do you come to this conclusion?
> > If possible provide an example that shows what is not working.
> >
> > If you do not have identical rulesets, the transfered states will have the
> > "rule number" reference removed, so you wont know what rule created a state
> > anymore if you look at the receiving system only, but the state will work
> > just fine.
> >
> > Possible exceptions i can think of are if-bound states.


The way I came to the conclusion is I have two systems with different
wan interfaces (vr0 and em0) and when I issued pfctl -ss on the
secondary, I only saw a few states from the host itself in the table.
There were none from the primary. When I added vr0 and em0 to trunk0
on each machine and updated the ruleset to reference trunk0 rather
than vr0 and em0 respectively, the state table on the secondary was
populated with states from the primary.


> It's also needed for getting states assigned to the correct queues (if used).
> Maybe something else too.
>
> The usual workaround for this is to have rules reference interface groups
> if the interface types differ.
>

I confirmed your suggested workaround also functions to get the
primary state table on the secondary, which would seem more efficient
than adding a single NIC as a port in a trunk. I noticed that pf
failed to load the ruleset when trying to reference the queue though,
which I think you were getting at with your first comment.  Are you
saying that, while the states may have transferred over to the
secondary, since the queues have to reference the interface explicitly
that they won't work correctly once the secondary takes control after
a failover? In other words, if you have queuing you need to use the
trunk0 workaround rather than the groups workaround? Either way, my
original premise stands that if the interfaces aren't the same as
referenced in the ruleset (I can clarify that it's the ruleset
referencing part that is the requirement in the patch) they won't load
on the secondary.

Reply | Threaded
Open this post in threaded view
|

Re: pfsync(4) man page patch to clarify requirements

Chad Gross
On Thu, Jan 30, 2020 at 8:11 AM Chad Gross <[hidden email]> wrote:

>
> On Thu, Jan 30, 2020 at 3:49 AM Stuart Henderson <[hidden email]> wrote:
> >
> > On 2020/01/30 11:15, Sebastian Benoit wrote:
> > > Chad Gross([hidden email]) on 2020.01.29 16:22:52 -0700:
> > > > It isn't explicitly expressed in the man page that pfsync requires
> > > > identical interfaces to work properly so I've created a patch
> > > > clarifying that it won't work otherwise. A workaround is possible with
> > > > the use of trunk(4), or now possibly aggr(4), but I wasn't sure this
> > > > additional information was warranted in the man page.
> > >
> > > I dont think this is correct. How do you come to this conclusion?
> > > If possible provide an example that shows what is not working.
> > >
> > > If you do not have identical rulesets, the transfered states will have the
> > > "rule number" reference removed, so you wont know what rule created a state
> > > anymore if you look at the receiving system only, but the state will work
> > > just fine.
> > >
> > > Possible exceptions i can think of are if-bound states.
>
>
> The way I came to the conclusion is I have two systems with different
> wan interfaces (vr0 and em0) and when I issued pfctl -ss on the
> secondary, I only saw a few states from the host itself in the table.
> There were none from the primary. When I added vr0 and em0 to trunk0
> on each machine and updated the ruleset to reference trunk0 rather
> than vr0 and em0 respectively, the state table on the secondary was
> populated with states from the primary.
>
>
> > It's also needed for getting states assigned to the correct queues (if used).
> > Maybe something else too.
> >
> > The usual workaround for this is to have rules reference interface groups
> > if the interface types differ.
> >
>
> I confirmed your suggested workaround also functions to get the
> primary state table on the secondary, which would seem more efficient
> than adding a single NIC as a port in a trunk. I noticed that pf
> failed to load the ruleset when trying to reference the queue though,
> which I think you were getting at with your first comment.  Are you
> saying that, while the states may have transferred over to the
> secondary, since the queues have to reference the interface explicitly
> that they won't work correctly once the secondary takes control after
> a failover? In other words, if you have queuing you need to use the
> trunk0 workaround rather than the groups workaround? Either way, my
> original premise stands that if the interfaces aren't the same as
> referenced in the ruleset (I can clarify that it's the ruleset
> referencing part that is the requirement in the patch) they won't load
> on the secondary.

Benno,

You were right, I was able to get it to work as you indicated. The
same NIC is not required for states to transfer. I was missing
persistence in the config that prevented it from working.

Thanks,

Chad