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
