> On 18 Oct 2014, at 11:42 pm, Stefan Sperling <[email protected]> wrote: > > On Fri, Oct 17, 2014 at 10:51:54AM +1000, David Gwynne wrote: >> as discussed, a fix for this has been committed in src/sys/net/if_pfsync.c >> r1.210 >> >> thank you for the good bug report. your recipe was easy to follow. >> > > There is still another problem with pfsync and IPsec. > > Using the previously described setup, the pfsync peers don't properly > keep their pf states in sync while IPsec is in use. The reason seems > to be that once local TDBs used for protecting pfsync traffic are synced > to the peer then IPsec replay checks trigger on the peer's side when > future pfsync updates are sent: > > # netstat -p esp -s | grep replay > 304 possibly replayed packets received > > In this state, pfsync updates are being dropped by the peer's IPsec stack. > Running tcpdump on enc0 shows that there is no bi-directional pfsync traffic. > The peers are sending pfsync updates out but neither is receiving them. > > To test my theory I've verified that turning pfsync_update_tdb() into a > stub that returns immediately allows both peers to keep pf states in sync > and tcpdump on enc0 now shows bi-directional pfsync traffic. > > I'm not sure what the best fix is. Perhaps making pfsync prevent particular > TDBs from being synced would do. However, this problem might affect any > SAs negotiated between the peers. In case the peers have multiple > IPsec-protected links between them we might have to prevent syncing IPsec > state not directly related to pfsync. The question then becomes which > TDB's can actually be synced without breaking communication between the > peers, in general, without knowing what addresses the remote peer is using > besides the syncpeer address. > > I don't know enough about IPsec to come up with an answer I feel confident > about. The best answer I could come up with so far was "any TDB that uses > a source address from any local interface should be exempt from syncing". > Is that acceptable? Other ideas?
pfsync implicitely adds NO_SYNC on pf states for pfsync traffic. state update messages never occur on the wire for pfsync protocol traffic. id argue something that gives the same result is necessary here. the problem is the flow you set up to protect pfsync traffic also protects all traffic between the hosts, not just pfsync. on my big boxes at work i try to have something along the lines of "pass !received-on any keep state (no-sync)" to avoid creating states for connections that are locally terminated. i dont know if there was a "no-sync" flag added for ipsec flows that pfsync could work with, but that would be necessary in this situation. dlg
