On 2022/03/12 01:04, Ian Chilton wrote: > Hi, > > The pfsync manual page is a bit vague on the technical aspects. > > It recommends a direct connection between machines, but this isn't easy > /possible if the hosts are in different sites. > > Is it fine to use a vlan interface?
Yes. > If so, is it better to use a dedicated VLAN, or is it fine to use an > existing linknet VLAN, which is already doing other traffic - including > things like CARP and OSPF? Unsure but I have always used dedicated. For higher performance, jumbo frames are helpful for the interface carrying pfsync traffic, so apart from anything else if you didn't want jumbos on that linknet that's probably a good enough reason in itself to split it. > It defaults to multicast over unicast. Is there a performance benefit > to either? > > Are there any benefits to multicast over the ability to have more than > 2 hosts and not needing to specify the peer? Unsure but I don't think so. > I assume ipsec is only needed/recommended if it's a public network. If > it's done over a private network with RFC1918, then there is no need/ > benefit to tunnelling it, and in fact that would just make it slower? Right. > It looks like there is no facility for specifying multiple networks, so > it will keep working in the event of a single link failure. Would it > cause a problem to run two separate pfsync interfaces between the same > hosts concurrently, over two separate links? I don't believe that's possible so link resilience would need to be done at a lower level. If pfsync traffic is carried on physical interfaces with usable link state, trunk or aggr interfaces would work, but it doesn't seem like this will be a good fit for your use case. OpenBSD has a wide range of tunnel interfaces (etherip, vxlan, eoip, egre etc) - I haven't tried using them to carry pfsync traffic but they *might* work if you wanted to use an IP-based 'underlay' network. Some need to be configured by bridging to an ethernet-like interface; for cases where a physical interface doesn't make sense a vether(4) interface can be created and used instead. > Is there any way of seeing the status of pfsync, other than inspecting > the state tables or testing something which requires state? I guess you're after something like a "has received packets recently" flag or "last packet received XX seconds ago" counter which isn't available. The information from netstat -s -p pfsync might be useful to you though - it's also exported by OpenBSD's snmpd in enterprises.openBSD.pfMIBObjects.pfsyncStats (OPENBSD-PF-MIB). > The manual suggests: > pass quick on <if> proto pfsync > > but would it not be better to be specific on the source and > destination?: > pass quick on <if> proto pfsync from <if>:network to <if>:network I think the original makes sense as a standard example config; <if>:network wouldn't cover the multicast addresses if those are used, and it's usually expected to be on an interface only carrying trusted traffic. It can be restricted further of course though.
