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?
